Re: [JPP-Devel] A new ThreadQueue ...
Hi Larry,
Larry Becker schrieb:
> Hi Sascha,
>
> Only potentially, but practically speaking my code is blocking the
> GUI thread, and there is nothing running to put more jobs on the
> queue. The while loop in processQueue will keep maxRunningThreads
> running untill the queue begins to empty. When is empty, there are no
> more render jobs to process.
This is wrong. Say you have enqueued three jobs.
The defaultRendering ThreadQueue is limited to one Thread running
so all threads are working one after each other. After the first
job has endend, the one and only Thread brings the counter to zero
because this if the only thread working on the jobs. But there are
two more in the queue. It is not important if the GUI thread is
blocked. There are two jobs more to do. And more problems arrive
if you have jobs that are _not_ in the default rendering ThreadQueue
like WMS. They are rendered in truly parallel way with a second
thread. Your 'while (default queue has running threads) sleep(time)'
loop don't test this second queue.
BTW: Didn't you mention that you place a
try { ... } catch (ArrayIndexOutOfBoundsException ex) { ...}
workaround in your SkyJUMP code? Have you ever thought about
the reasons? Looking at the code of OJ I didn't find this
'improvement' ...
> This has been an interesting discussion, but we could go back and
> forth like this forever. I admit that you know Threads very well, and
> that your design appears to be better. I'm simply saying that JUMP
> ThreadQueue is not as bad as you are making it out to be, and that it
> has been working perfectly fine for years now. Could it be improved?
> Of course, Jon's comments show he was constantly seeking improvements
> to it. I am just cautious about replacing a critical section of code
> without adequate testing. Give me a well tested "bad" design over an
> untested good design any day.
I totally agree with you. Never touch a running system. But the system
is not running very well here. Nobody wrote code in the past that needs
precise reliability in this thread issues. This has changed.
And as you say: It's a critical portion of the code. For this kinds
of code I demand 'nearly' (*) mathematical correctness. And talking
about business: I have a customer here how stumbled into this concrete
thread trap. Now I can show him my analysis and my enhancements and how
the issue is able to be fixed. I can send him a patch set against OJ to
make his private copy work. But I prefer to fix the problem at the root
and discuss it with the OJ team.
> Don't get me wrong, I do appreciate your hard work and contribution.
> I just need a little more time to test.
This why are talking about and I'm willing to give you this time. :-)
> regards,
> Larry
(*) Having in mind Knuth's famous quotation about correctness proves and
tests.
Regards,
Sascha
>
> On 5/30/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
>> Hi Larry,
>>
>> the magic word here is 'critical region'
>> Have a look a the finally block.
>> Assume the setRunningThreads(getRunningThreads() - 1) call
>> was executed and the counter went to zero. This is done in Thread A.
>> And now directly comes a context switch to your code
>> in Thread B. Your if statement thinks that there are no
>> jobs any more -> Your loop ends. Context switch back to Thread A.
>> Now the processQueue() call is executed and potentially a
>> new thread is started because the queue is not empty.
>> Counter is zero but queue not empty.
>> Thread programming is delicate, isn't it?
>>
>> - Sascha
>>
>>
>> Larry Becker schrieb:
>>> Hi Sascha,
>>>
>>> I do not see the difference. It seems to me that when a task is
>>> finished, the runningThreads count is decremented as in:
>>>
>>> try {
>>> runnable.run();
>>> } finally {
>>> setRunningThreads(getRunningThreads() - 1);
>>> processQueue();
>>> }
>>>
>>> So it would seem to me that when the count reaches zero that there are
>>> no more jobs.
>>>
>>> regards,
>>> Larry
>>>
>>> On 5/30/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
Hi Larry,
The method is named runningThreads(). This was my
mistake. I will add add get getRunningThreads() to
reestablish compatibility. Thanks for this hint.
BTW: You're code:
while (threadQueue.getRunningThreads() > 0) Thread.sleep(200);
tests if there are running _threads_ left. This do not tell
you if there are _jobs_ to to! What you really want to know
is when the last job is done. See the difference?
The new RenderingManager will have a new method to archive
this. It will switch the thread queue to single threaded mode
and enqueues a special Runnable at the end. Then the calling
thread is lock with a monitor. If the special Runnable is
executed the monitor is unlocked and the calling thread continues.
This is what you want
Re: [JPP-Devel] A new ThreadQueue ...
Hi Sascha,
Only potentially, but practically speaking my code is blocking the
GUI thread, and there is nothing running to put more jobs on the
queue. The while loop in processQueue will keep maxRunningThreads
running untill the queue begins to empty. When is empty, there are no
more render jobs to process.
This has been an interesting discussion, but we could go back and
forth like this forever. I admit that you know Threads very well, and
that your design appears to be better. I'm simply saying that JUMP
ThreadQueue is not as bad as you are making it out to be, and that it
has been working perfectly fine for years now. Could it be improved?
Of course, Jon's comments show he was constantly seeking improvements
to it. I am just cautious about replacing a critical section of code
without adequate testing. Give me a well tested "bad" design over an
untested good design any day.
Don't get me wrong, I do appreciate your hard work and contribution.
I just need a little more time to test.
regards,
Larry
On 5/30/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> Hi Larry,
>
> the magic word here is 'critical region'
> Have a look a the finally block.
> Assume the setRunningThreads(getRunningThreads() - 1) call
> was executed and the counter went to zero. This is done in Thread A.
> And now directly comes a context switch to your code
> in Thread B. Your if statement thinks that there are no
> jobs any more -> Your loop ends. Context switch back to Thread A.
> Now the processQueue() call is executed and potentially a
> new thread is started because the queue is not empty.
> Counter is zero but queue not empty.
> Thread programming is delicate, isn't it?
>
> - Sascha
>
>
> Larry Becker schrieb:
> > Hi Sascha,
> >
> > I do not see the difference. It seems to me that when a task is
> > finished, the runningThreads count is decremented as in:
> >
> > try {
> > runnable.run();
> > } finally {
> > setRunningThreads(getRunningThreads() - 1);
> > processQueue();
> > }
> >
> > So it would seem to me that when the count reaches zero that there are
> > no more jobs.
> >
> > regards,
> > Larry
> >
> > On 5/30/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> >> Hi Larry,
> >>
> >> The method is named runningThreads(). This was my
> >> mistake. I will add add get getRunningThreads() to
> >> reestablish compatibility. Thanks for this hint.
> >>
> >> BTW: You're code:
> >>
> >> while (threadQueue.getRunningThreads() > 0) Thread.sleep(200);
> >>
> >> tests if there are running _threads_ left. This do not tell
> >> you if there are _jobs_ to to! What you really want to know
> >> is when the last job is done. See the difference?
> >>
> >> The new RenderingManager will have a new method to archive
> >> this. It will switch the thread queue to single threaded mode
> >> and enqueues a special Runnable at the end. Then the calling
> >> thread is lock with a monitor. If the special Runnable is
> >> executed the monitor is unlocked and the calling thread continues.
> >> This is what you want.
> >>
> >> Switching to single thread mode has the advantage to keep
> >> the correct z order of the layers. This is essential for
> >> printing because you don't want to have any internal repaint()
> >> operations. This causes overdraw. If you render to bitmap this
> >> might be okay, but if you want to send the vector information
> >> to the Graphics2D of the output driver this is not a good idea.
> >>
> >> Kind regards,
> >> Sascha
> >>
> >>
> >> Larry Becker schrieb:
> >>> It doesn't look like I'm going to have time to test the new
> >>> ThreadQueue anytime soon. I did plug it in long enough to determine
> >>> that it broke my code that called getRunningThreads() since that
> >>> method is no longer present. I didn't have time to look for the new
> >>> method that I should use instead. I should be able to get back to it
> >>> in a couple of weeks (I'm instructing a class in our software next
> >>> week).
> >>>
> >>> regards,
> >>> Larry
> >>>
> >>> On 5/30/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> > Hei Saschachaël
> >
> > i got positive feedback from my colleaque on the changes of the
> > threading stuff.
> > If Michael aggrees too, you can commit
> >
> >
> As far as I'm concerned, I am really pleased to see Sascha's
> contribution to the core.
> OJ really needs contributions from skilled programmers :-) .
>
> Michaël
>
> > stefan
> >
> > Sascha L. Teichmann schrieb:
> >
> >
> >> Hi!
> >>
> >> Stefan Steiniger schrieb:
> >>
> >>
> >>> Similar to Landon I have never touched threading nor heared any
> >>> lectures
> >>> or read books on it. Thus .. i dont know if it turns out to be good
> >>> or bad.
> >>> But i know that making things more clean is good objective. Thus, i
> >>> suppo
Re: [JPP-Devel] A new ThreadQueue ...
Hi Larry,
the magic word here is 'critical region'
Have a look a the finally block.
Assume the setRunningThreads(getRunningThreads() - 1) call
was executed and the counter went to zero. This is done in Thread A.
And now directly comes a context switch to your code
in Thread B. Your if statement thinks that there are no
jobs any more -> Your loop ends. Context switch back to Thread A.
Now the processQueue() call is executed and potentially a
new thread is started because the queue is not empty.
Counter is zero but queue not empty.
Thread programming is delicate, isn't it?
- Sascha
Larry Becker schrieb:
> Hi Sascha,
>
> I do not see the difference. It seems to me that when a task is
> finished, the runningThreads count is decremented as in:
>
> try {
> runnable.run();
> } finally {
> setRunningThreads(getRunningThreads() - 1);
> processQueue();
> }
>
> So it would seem to me that when the count reaches zero that there are
> no more jobs.
>
> regards,
> Larry
>
> On 5/30/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
>> Hi Larry,
>>
>> The method is named runningThreads(). This was my
>> mistake. I will add add get getRunningThreads() to
>> reestablish compatibility. Thanks for this hint.
>>
>> BTW: You're code:
>>
>> while (threadQueue.getRunningThreads() > 0) Thread.sleep(200);
>>
>> tests if there are running _threads_ left. This do not tell
>> you if there are _jobs_ to to! What you really want to know
>> is when the last job is done. See the difference?
>>
>> The new RenderingManager will have a new method to archive
>> this. It will switch the thread queue to single threaded mode
>> and enqueues a special Runnable at the end. Then the calling
>> thread is lock with a monitor. If the special Runnable is
>> executed the monitor is unlocked and the calling thread continues.
>> This is what you want.
>>
>> Switching to single thread mode has the advantage to keep
>> the correct z order of the layers. This is essential for
>> printing because you don't want to have any internal repaint()
>> operations. This causes overdraw. If you render to bitmap this
>> might be okay, but if you want to send the vector information
>> to the Graphics2D of the output driver this is not a good idea.
>>
>> Kind regards,
>> Sascha
>>
>>
>> Larry Becker schrieb:
>>> It doesn't look like I'm going to have time to test the new
>>> ThreadQueue anytime soon. I did plug it in long enough to determine
>>> that it broke my code that called getRunningThreads() since that
>>> method is no longer present. I didn't have time to look for the new
>>> method that I should use instead. I should be able to get back to it
>>> in a couple of weeks (I'm instructing a class in our software next
>>> week).
>>>
>>> regards,
>>> Larry
>>>
>>> On 5/30/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> Hei Saschachaël
>
> i got positive feedback from my colleaque on the changes of the
> threading stuff.
> If Michael aggrees too, you can commit
>
>
As far as I'm concerned, I am really pleased to see Sascha's
contribution to the core.
OJ really needs contributions from skilled programmers :-) .
Michaël
> stefan
>
> Sascha L. Teichmann schrieb:
>
>
>> Hi!
>>
>> Stefan Steiniger schrieb:
>>
>>
>>> Similar to Landon I have never touched threading nor heared any lectures
>>> or read books on it. Thus .. i dont know if it turns out to be good or
>>> bad.
>>> But i know that making things more clean is good objective. Thus, i
>>> support the changes. It would be good when we finally change the code,
>>> that you also put into the code some docs or references where you
>>> outline why somethings has changed. (actually I currently would opt to
>>> leave the old code as comment and not to remove entirely)
>>>
>>>
>> The ThreadQueue is JavaDoc'ed but I can add some
>> design notes as well. Keeping old things as comments negates
>> the existence of version control systems.
>> CVS is exactly the time machine you for this.
>> As I pointed out earlier having a ChangeLog would
>> be nice to document motivations and backgrounds for a change. Simply
>> generating a ChangeLog out of the commit messages is convenient but
>> it does not uncover the true potential of such a 'log' file.
>>
>>
>>
>>> Due to my lack of knowledge i forwarded your email to a colleague who
>>> developed a web-service based on JUMP (which runs on a server, see [1]),
>>> an ajax client and recently did some multiprocessor experiments for the
>>> web-services processing.
>>>
>>>
>> I look forward to his comments.
>>
>>
>>
>>> I hope 1) he will look on your proposal and 2) you can wait some days
>>> until he, Larry and Michael got an opinion.
>>>
Re: [JPP-Devel] A new ThreadQueue ...
Hi Sascha,
I do not see the difference. It seems to me that when a task is
finished, the runningThreads count is decremented as in:
try {
runnable.run();
} finally {
setRunningThreads(getRunningThreads() - 1);
processQueue();
}
So it would seem to me that when the count reaches zero that there are
no more jobs.
regards,
Larry
On 5/30/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> Hi Larry,
>
> The method is named runningThreads(). This was my
> mistake. I will add add get getRunningThreads() to
> reestablish compatibility. Thanks for this hint.
>
> BTW: You're code:
>
> while (threadQueue.getRunningThreads() > 0) Thread.sleep(200);
>
> tests if there are running _threads_ left. This do not tell
> you if there are _jobs_ to to! What you really want to know
> is when the last job is done. See the difference?
>
> The new RenderingManager will have a new method to archive
> this. It will switch the thread queue to single threaded mode
> and enqueues a special Runnable at the end. Then the calling
> thread is lock with a monitor. If the special Runnable is
> executed the monitor is unlocked and the calling thread continues.
> This is what you want.
>
> Switching to single thread mode has the advantage to keep
> the correct z order of the layers. This is essential for
> printing because you don't want to have any internal repaint()
> operations. This causes overdraw. If you render to bitmap this
> might be okay, but if you want to send the vector information
> to the Graphics2D of the output driver this is not a good idea.
>
> Kind regards,
> Sascha
>
>
> Larry Becker schrieb:
> > It doesn't look like I'm going to have time to test the new
> > ThreadQueue anytime soon. I did plug it in long enough to determine
> > that it broke my code that called getRunningThreads() since that
> > method is no longer present. I didn't have time to look for the new
> > method that I should use instead. I should be able to get back to it
> > in a couple of weeks (I'm instructing a class in our software next
> > week).
> >
> > regards,
> > Larry
> >
> > On 5/30/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> >>> Hei Saschachaël
> >>>
> >>> i got positive feedback from my colleaque on the changes of the
> >>> threading stuff.
> >>> If Michael aggrees too, you can commit
> >>>
> >>>
> >> As far as I'm concerned, I am really pleased to see Sascha's
> >> contribution to the core.
> >> OJ really needs contributions from skilled programmers :-) .
> >>
> >> Michaël
> >>
> >>> stefan
> >>>
> >>> Sascha L. Teichmann schrieb:
> >>>
> >>>
> Hi!
>
> Stefan Steiniger schrieb:
>
>
> > Similar to Landon I have never touched threading nor heared any lectures
> > or read books on it. Thus .. i dont know if it turns out to be good or
> > bad.
> > But i know that making things more clean is good objective. Thus, i
> > support the changes. It would be good when we finally change the code,
> > that you also put into the code some docs or references where you
> > outline why somethings has changed. (actually I currently would opt to
> > leave the old code as comment and not to remove entirely)
> >
> >
> The ThreadQueue is JavaDoc'ed but I can add some
> design notes as well. Keeping old things as comments negates
> the existence of version control systems.
> CVS is exactly the time machine you for this.
> As I pointed out earlier having a ChangeLog would
> be nice to document motivations and backgrounds for a change. Simply
> generating a ChangeLog out of the commit messages is convenient but
> it does not uncover the true potential of such a 'log' file.
>
>
>
> > Due to my lack of knowledge i forwarded your email to a colleague who
> > developed a web-service based on JUMP (which runs on a server, see [1]),
> > an ajax client and recently did some multiprocessor experiments for the
> > web-services processing.
> >
> >
> I look forward to his comments.
>
>
>
> > I hope 1) he will look on your proposal and 2) you can wait some days
> > until he, Larry and Michael got an opinion.
> >
> >
> @Michael: You ask what to change. For the moment just replace
> ThreadQueue.java with one I've sent last. The first patches
> are addressing the problem with ThreadQueue limited to one
> Thread at a time (defaultRenderingThreadQueue in RenderingManger).
> You can apply these patches too, but they are not needed any
> longer. With next patch I'll send the this second thread queue
> will be removed from RenderingManager entirely.
>
> What to test? Doing your day-to-day is the best thing
> you can do. The most important thing is that the new one
> behaves exactly like the old one. The magic word is compatibility.
Re: [JPP-Devel] A new ThreadQueue ...
Hi Larry, The method is named runningThreads(). This was my mistake. I will add add get getRunningThreads() to reestablish compatibility. Thanks for this hint. BTW: You're code: while (threadQueue.getRunningThreads() > 0) Thread.sleep(200); tests if there are running _threads_ left. This do not tell you if there are _jobs_ to to! What you really want to know is when the last job is done. See the difference? The new RenderingManager will have a new method to archive this. It will switch the thread queue to single threaded mode and enqueues a special Runnable at the end. Then the calling thread is lock with a monitor. If the special Runnable is executed the monitor is unlocked and the calling thread continues. This is what you want. Switching to single thread mode has the advantage to keep the correct z order of the layers. This is essential for printing because you don't want to have any internal repaint() operations. This causes overdraw. If you render to bitmap this might be okay, but if you want to send the vector information to the Graphics2D of the output driver this is not a good idea. Kind regards, Sascha Larry Becker schrieb: > It doesn't look like I'm going to have time to test the new > ThreadQueue anytime soon. I did plug it in long enough to determine > that it broke my code that called getRunningThreads() since that > method is no longer present. I didn't have time to look for the new > method that I should use instead. I should be able to get back to it > in a couple of weeks (I'm instructing a class in our software next > week). > > regards, > Larry > > On 5/30/07, Michaël Michaud <[EMAIL PROTECTED]> wrote: >>> Hei Saschachaël >>> >>> i got positive feedback from my colleaque on the changes of the >>> threading stuff. >>> If Michael aggrees too, you can commit >>> >>> >> As far as I'm concerned, I am really pleased to see Sascha's >> contribution to the core. >> OJ really needs contributions from skilled programmers :-) . >> >> Michaël >> >>> stefan >>> >>> Sascha L. Teichmann schrieb: >>> >>> Hi! Stefan Steiniger schrieb: > Similar to Landon I have never touched threading nor heared any lectures > or read books on it. Thus .. i dont know if it turns out to be good or > bad. > But i know that making things more clean is good objective. Thus, i > support the changes. It would be good when we finally change the code, > that you also put into the code some docs or references where you > outline why somethings has changed. (actually I currently would opt to > leave the old code as comment and not to remove entirely) > > The ThreadQueue is JavaDoc'ed but I can add some design notes as well. Keeping old things as comments negates the existence of version control systems. CVS is exactly the time machine you for this. As I pointed out earlier having a ChangeLog would be nice to document motivations and backgrounds for a change. Simply generating a ChangeLog out of the commit messages is convenient but it does not uncover the true potential of such a 'log' file. > Due to my lack of knowledge i forwarded your email to a colleague who > developed a web-service based on JUMP (which runs on a server, see [1]), > an ajax client and recently did some multiprocessor experiments for the > web-services processing. > > I look forward to his comments. > I hope 1) he will look on your proposal and 2) you can wait some days > until he, Larry and Michael got an opinion. > > @Michael: You ask what to change. For the moment just replace ThreadQueue.java with one I've sent last. The first patches are addressing the problem with ThreadQueue limited to one Thread at a time (defaultRenderingThreadQueue in RenderingManger). You can apply these patches too, but they are not needed any longer. With next patch I'll send the this second thread queue will be removed from RenderingManager entirely. What to test? Doing your day-to-day is the best thing you can do. The most important thing is that the new one behaves exactly like the old one. The magic word is compatibility. I don't want to break the show. Use plug-ins, use many layers, use less layer, use db and WMS layers. Do all the fancy stuff you like to do. If the OJ freezes or something other looks odd just tell me. :-) - Sascha > Michaël Michaud schrieb: > > >> Sascha L. Teichmann a écrit : >> >> >> >>> Really back to topic: >>> >>> Find attached a replacement for ThreadQueue [1]. >>> To use it just overwrite the original one. >>> >>> >>> >>> >> Hi Sascha : >> >> I think that trying to have a cleaner and more simple code is an >> excellent goal, and I'd like to help, but I'm not sure I can understand
Re: [JPP-Devel] A new ThreadQueue ...
It doesn't look like I'm going to have time to test the new ThreadQueue anytime soon. I did plug it in long enough to determine that it broke my code that called getRunningThreads() since that method is no longer present. I didn't have time to look for the new method that I should use instead. I should be able to get back to it in a couple of weeks (I'm instructing a class in our software next week). regards, Larry On 5/30/07, Michaël Michaud <[EMAIL PROTECTED]> wrote: > > >Hei Saschachaël > > > >i got positive feedback from my colleaque on the changes of the > >threading stuff. > >If Michael aggrees too, you can commit > > > > > As far as I'm concerned, I am really pleased to see Sascha's > contribution to the core. > OJ really needs contributions from skilled programmers :-) . > > Michaël > > >stefan > > > >Sascha L. Teichmann schrieb: > > > > > >>Hi! > >> > >>Stefan Steiniger schrieb: > >> > >> > >>>Similar to Landon I have never touched threading nor heared any lectures > >>>or read books on it. Thus .. i dont know if it turns out to be good or bad. > >>>But i know that making things more clean is good objective. Thus, i > >>>support the changes. It would be good when we finally change the code, > >>>that you also put into the code some docs or references where you > >>>outline why somethings has changed. (actually I currently would opt to > >>>leave the old code as comment and not to remove entirely) > >>> > >>> > >>The ThreadQueue is JavaDoc'ed but I can add some > >>design notes as well. Keeping old things as comments negates > >>the existence of version control systems. > >>CVS is exactly the time machine you for this. > >>As I pointed out earlier having a ChangeLog would > >>be nice to document motivations and backgrounds for a change. Simply > >>generating a ChangeLog out of the commit messages is convenient but > >>it does not uncover the true potential of such a 'log' file. > >> > >> > >> > >>>Due to my lack of knowledge i forwarded your email to a colleague who > >>>developed a web-service based on JUMP (which runs on a server, see [1]), > >>>an ajax client and recently did some multiprocessor experiments for the > >>>web-services processing. > >>> > >>> > >>I look forward to his comments. > >> > >> > >> > >>>I hope 1) he will look on your proposal and 2) you can wait some days > >>>until he, Larry and Michael got an opinion. > >>> > >>> > >>@Michael: You ask what to change. For the moment just replace > >>ThreadQueue.java with one I've sent last. The first patches > >>are addressing the problem with ThreadQueue limited to one > >>Thread at a time (defaultRenderingThreadQueue in RenderingManger). > >>You can apply these patches too, but they are not needed any > >>longer. With next patch I'll send the this second thread queue > >>will be removed from RenderingManager entirely. > >> > >>What to test? Doing your day-to-day is the best thing > >>you can do. The most important thing is that the new one > >>behaves exactly like the old one. The magic word is compatibility. > >>I don't want to break the show. Use plug-ins, use many layers, > >>use less layer, use db and WMS layers. Do all the fancy stuff > >>you like to do. If the OJ freezes or something other looks odd > >>just tell me. :-) > >> > >>- Sascha > >> > >> > >> > >>>Michaël Michaud schrieb: > >>> > >>> > Sascha L. Teichmann a écrit : > > > > >Really back to topic: > > > >Find attached a replacement for ThreadQueue [1]. > >To use it just overwrite the original one. > > > > > > > > > Hi Sascha : > > I think that trying to have a cleaner and more simple code is an > excellent goal, and I'd like to help, but I'm not sure I can understand > all these thread issues. > If you tell me exactly which classes I must replace (on ly ThreadQueue > or also the pieces of code from your previous mail) and what kind of > tests I should do (rendering different kind of layers ? mixing different > kind of layers), I'll try to make some more tests on my desktop. > > Thanks, for the hard work > > Michaël > > > > >This one works for the real parallel case of > >layer rendering too. Each time a thread finished > >executing its Runnable it looks into the queue > >if they are more jobs to do. This prevents unnecessary > >thread creations/shutdowns. If the queue is empty > >the worker thread is kept alive for 5 seconds waiting > >for new jobs. This results in a kind of thread pooling. > > > >@Larry: I've isolated my implementation and the OJ > >ThreadQueue and done a synthetic benchmark with a > >larger number of jobs (10,000+). My implementation > >works about two orders faster than the OJ one. > >But this is of little meaning because OJ only > >has to handle a number of jobs equal the number > >of layers. This will hardly hit 10,000+ ;-) > >But again: My mission is improve t
Re: [JPP-Devel] A new ThreadQueue ...
>Hei Saschachaël > >i got positive feedback from my colleaque on the changes of the >threading stuff. >If Michael aggrees too, you can commit > > As far as I'm concerned, I am really pleased to see Sascha's contribution to the core. OJ really needs contributions from skilled programmers :-) . Michaël >stefan > >Sascha L. Teichmann schrieb: > > >>Hi! >> >>Stefan Steiniger schrieb: >> >> >>>Similar to Landon I have never touched threading nor heared any lectures >>>or read books on it. Thus .. i dont know if it turns out to be good or bad. >>>But i know that making things more clean is good objective. Thus, i >>>support the changes. It would be good when we finally change the code, >>>that you also put into the code some docs or references where you >>>outline why somethings has changed. (actually I currently would opt to >>>leave the old code as comment and not to remove entirely) >>> >>> >>The ThreadQueue is JavaDoc'ed but I can add some >>design notes as well. Keeping old things as comments negates >>the existence of version control systems. >>CVS is exactly the time machine you for this. >>As I pointed out earlier having a ChangeLog would >>be nice to document motivations and backgrounds for a change. Simply >>generating a ChangeLog out of the commit messages is convenient but >>it does not uncover the true potential of such a 'log' file. >> >> >> >>>Due to my lack of knowledge i forwarded your email to a colleague who >>>developed a web-service based on JUMP (which runs on a server, see [1]), >>>an ajax client and recently did some multiprocessor experiments for the >>>web-services processing. >>> >>> >>I look forward to his comments. >> >> >> >>>I hope 1) he will look on your proposal and 2) you can wait some days >>>until he, Larry and Michael got an opinion. >>> >>> >>@Michael: You ask what to change. For the moment just replace >>ThreadQueue.java with one I've sent last. The first patches >>are addressing the problem with ThreadQueue limited to one >>Thread at a time (defaultRenderingThreadQueue in RenderingManger). >>You can apply these patches too, but they are not needed any >>longer. With next patch I'll send the this second thread queue >>will be removed from RenderingManager entirely. >> >>What to test? Doing your day-to-day is the best thing >>you can do. The most important thing is that the new one >>behaves exactly like the old one. The magic word is compatibility. >>I don't want to break the show. Use plug-ins, use many layers, >>use less layer, use db and WMS layers. Do all the fancy stuff >>you like to do. If the OJ freezes or something other looks odd >>just tell me. :-) >> >>- Sascha >> >> >> >>>Michaël Michaud schrieb: >>> >>> Sascha L. Teichmann a écrit : >Really back to topic: > >Find attached a replacement for ThreadQueue [1]. >To use it just overwrite the original one. > > > > Hi Sascha : I think that trying to have a cleaner and more simple code is an excellent goal, and I'd like to help, but I'm not sure I can understand all these thread issues. If you tell me exactly which classes I must replace (on ly ThreadQueue or also the pieces of code from your previous mail) and what kind of tests I should do (rendering different kind of layers ? mixing different kind of layers), I'll try to make some more tests on my desktop. Thanks, for the hard work Michaël >This one works for the real parallel case of >layer rendering too. Each time a thread finished >executing its Runnable it looks into the queue >if they are more jobs to do. This prevents unnecessary >thread creations/shutdowns. If the queue is empty >the worker thread is kept alive for 5 seconds waiting >for new jobs. This results in a kind of thread pooling. > >@Larry: I've isolated my implementation and the OJ >ThreadQueue and done a synthetic benchmark with a >larger number of jobs (10,000+). My implementation >works about two orders faster than the OJ one. >But this is of little meaning because OJ only >has to handle a number of jobs equal the number >of layers. This will hardly hit 10,000+ ;-) >But again: My mission is improve the structure not >primarily the speed. > >I've tested the new ThreadQueue to some extent but >I'am male(tm) after all ... potentially making mistakes. >It would be very kind if someone test it too. > >My next step will be some clean up in the RenderingManager [2]. >I'am not sure that it is really needed to have two ThreadQueues >there. The effect of the single tread one can be easily >simulated with a data structure like the RunnableArrayList which >I've posted already. > >Any comments? > >Yours, > Sascha > >[1] com.vividsolutions.jump.workbench.ui.renderer.Thre
Re: [JPP-Devel] A new ThreadQueue ...
Hei Sascha i got positive feedback from my colleaque on the changes of the threading stuff. If Michael aggrees too, you can commit stefan Sascha L. Teichmann schrieb: > Hi! > > Stefan Steiniger schrieb: >> Similar to Landon I have never touched threading nor heared any lectures >> or read books on it. Thus .. i dont know if it turns out to be good or bad. >> But i know that making things more clean is good objective. Thus, i >> support the changes. It would be good when we finally change the code, >> that you also put into the code some docs or references where you >> outline why somethings has changed. (actually I currently would opt to >> leave the old code as comment and not to remove entirely) > > The ThreadQueue is JavaDoc'ed but I can add some > design notes as well. Keeping old things as comments negates > the existence of version control systems. > CVS is exactly the time machine you for this. > As I pointed out earlier having a ChangeLog would > be nice to document motivations and backgrounds for a change. Simply > generating a ChangeLog out of the commit messages is convenient but > it does not uncover the true potential of such a 'log' file. > >> Due to my lack of knowledge i forwarded your email to a colleague who >> developed a web-service based on JUMP (which runs on a server, see [1]), >> an ajax client and recently did some multiprocessor experiments for the >> web-services processing. > > I look forward to his comments. > >> I hope 1) he will look on your proposal and 2) you can wait some days >> until he, Larry and Michael got an opinion. > > @Michael: You ask what to change. For the moment just replace > ThreadQueue.java with one I've sent last. The first patches > are addressing the problem with ThreadQueue limited to one > Thread at a time (defaultRenderingThreadQueue in RenderingManger). > You can apply these patches too, but they are not needed any > longer. With next patch I'll send the this second thread queue > will be removed from RenderingManager entirely. > > What to test? Doing your day-to-day is the best thing > you can do. The most important thing is that the new one > behaves exactly like the old one. The magic word is compatibility. > I don't want to break the show. Use plug-ins, use many layers, > use less layer, use db and WMS layers. Do all the fancy stuff > you like to do. If the OJ freezes or something other looks odd > just tell me. :-) > > - Sascha > >> Michaël Michaud schrieb: >>> Sascha L. Teichmann a écrit : >>> Really back to topic: Find attached a replacement for ThreadQueue [1]. To use it just overwrite the original one. >>> Hi Sascha : >>> >>> I think that trying to have a cleaner and more simple code is an >>> excellent goal, and I'd like to help, but I'm not sure I can understand >>> all these thread issues. >>> If you tell me exactly which classes I must replace (on ly ThreadQueue >>> or also the pieces of code from your previous mail) and what kind of >>> tests I should do (rendering different kind of layers ? mixing different >>> kind of layers), I'll try to make some more tests on my desktop. >>> >>> Thanks, for the hard work >>> >>> Michaël >>> This one works for the real parallel case of layer rendering too. Each time a thread finished executing its Runnable it looks into the queue if they are more jobs to do. This prevents unnecessary thread creations/shutdowns. If the queue is empty the worker thread is kept alive for 5 seconds waiting for new jobs. This results in a kind of thread pooling. @Larry: I've isolated my implementation and the OJ ThreadQueue and done a synthetic benchmark with a larger number of jobs (10,000+). My implementation works about two orders faster than the OJ one. But this is of little meaning because OJ only has to handle a number of jobs equal the number of layers. This will hardly hit 10,000+ ;-) But again: My mission is improve the structure not primarily the speed. I've tested the new ThreadQueue to some extent but I'am male(tm) after all ... potentially making mistakes. It would be very kind if someone test it too. My next step will be some clean up in the RenderingManager [2]. I'am not sure that it is really needed to have two ThreadQueues there. The effect of the single tread one can be easily simulated with a data structure like the RunnableArrayList which I've posted already. Any comments? Yours, Sascha [1] com.vividsolutions.jump.workbench.ui.renderer.ThreadQueue [2] com.vividsolutions.jump.workbench.ui.renderer.RenderingManager Sunburned Surveyor schrieb: > Sascha, > > Please accept my sincerest aopologies. I'm afriad my American > ignorance of other cultures is more than just a little obvious at > times. > > I believe I have made the s
Re: [JPP-Devel] R: Multiple Layers from the same database connection
We made the Datastore API cache connections and reuse them if a user requested a connection with the same connection params. So when you load layers from a project file they will reuse already-open connections whereever they can. At least, this is how it's *supposed* to work... it's been a while since I wrote that code, and I don't know if anything changed during the port to OJ. Can someone report on this? P.Rizzi Ag.Mobilità Ambiente wrote: > I can't completely understand what you're saying... > Using the Datastore API you can open several layers from > a single connection... > You can try my PostGIS/Oracle plugin from: > http://sourceforge.net/project/showfiles.php?group_id=118054&package_id=217237 > > But you pointed out something I never realized before, > that inside a project/task file each layer has it's connection > parameter repeated, does it mean that when a project/task is opened > the Datastore API opens a separate connection for each layer??? > I don't know that... > > But the connection dialog lists each connection only once, so there > may be some smart code that "put together" identical connection > opening them only once. > > I'll have to find the time to debug this... > > Anyway something able to "group" layers would be a great thing, > so you can operate on a "group" (or may we call it a theme???) > as a whole (hide/show, refresh, etc.). > > While I'm at it, even if it's not strictly related to this post, > it would be great to be able to save inside a project/task file > also a layer coming from Datastore query, otherwise you to manually > recreate and restyle it every time you run OJ anew. > > Bye > Paolo Rizzi > > > >> -Messaggio originale- >> Da: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] >> conto di Paul >> Austin >> Inviato: martedì 29 maggio 2007 22.16 >> A: jump-pilot-devel@lists.sourceforge.net >> Oggetto: [JPP-Devel] Multiple Layers from the same database connection >> >> >> All, >> >> I've been looking at the existing database and file plugins and the >> com.vividsolutions.jump.io.datasource.DataSource class and from what I >> can tell there is a one to one relationship between a layer and a data >> source. >> >> What I would like to do for some of the file and database based data >> sources is to have the concept of a DataSource that can contain many >> different layers. Within a project you would be able to select which >> layers you wanted to view from that data source. >> >> In the database world this concept would relate to having a connection >> to the data base using a java.sql.Connection. When adding the database >> connection to a project there would be a UI that would list the >> available layers (database tables) and the user could select which >> layers they wish to view. This compares to the current PostGIS plug-in >> where you have to manually enter the connection and table details for >> each layer. >> >> When the project is closed then the "connection" must also be closed. >> >> In the Jump project file the "connection" parameters would be stored >> once, then the data sources used for each layer would reference the >> "connection" and have a different query for each table. >> >> Now if we look at a file based example, I have a file format which is >> basically a zip file that contains one file for each layer along with >> some metadata files. I would like to be able to open the zip file and >> create a layer for each of the layers in the zip file. To do this I >> would extract the file to the temp directory and as required load the >> data from the individual files in the temp directory. Then when you >> close the project the "connection" is closed by deleting the temporary >> files. >> >> Another file based example would be to open a directory of files, >> loading each layer file in that directory, this is basically >> the same as >> the zip file idea but without the temporary files. >> >> In both the file cases once the file is loaded the first time the user >> can select which of the layers to view. >> >> So the question is, does any of the existing functionality in >> JUMP allow >> for multi-layer data sources? If not I'm going to do some prototyping >> for the file format I have and then share this with the group for >> comment to see if it would be useful elsewhere. >> >> After that I have an interest in Oracle connections so would >> need to do >> the same kind of thing there. >> >> One other question, where would I find the code for writing out the >> project .jmp XML files as I'd need to add the "connection" definitions >> to this. >> >> Cheers, >> Paul >> >> -- >> --- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> ___ >> Jump-pilot-d
Re: [JPP-Devel] Code Style Standards
I think a good set of standards to follow are the Sun Java Code Conventions. It's a fairly short (ish) standard and avoids all the variable prefix and class prefix stuff. http://java.sun.com/docs/codeconv/CodeConventions.pdf In terms of package imports I don't ever manually type imports any more, I either use Ctrl-Space to auto add the import when typing a class name and use the organize imports functionality in eclipse. Same for code formatting, I take the Eclipse Sun Code Conventions rule and have it auto format as I type or reformat after cut and paste. So here is my argument for following code conventions and import/code formatting guidelines. If two developers are making a set of changes to some files and they both auto format the code but using different conventions when they go to merge their changes with the other developer the diff tool will highlight a whole bunch of changes for them to review that are just due to the difference in formatting. So by following the same formatting rules merging changes should be easier. I would encourage (not enforce) developers to use Checkstyle http://checkstyle.sourceforge.net/ to flag as warnings where the code differs from coding practices that we as a group decide upon. We can create a config file for checkstyle containing that can be used by the checkstyle plugin for Eclipse, JBuilder, Netbeans, IntelliJ IDEA, Emacs JDE, Vim etc. Those are my thoughts, Paul Sunburned Surveyor wrote: > One of the topics discussed in an earlier thread today was code format > standards or code style standards.Using tools that will allow us to > automatically enforce a coding standard was suggested. Using these > tools to convert existing source code from other JUMP "brands" to our > style for OpenJUMP was also a suggestion. > > I'm really excited that others would be interested in this type of > consistency and quality for our source code of OpenJUMP. I don't want > us to loose that momentum! > However, I'm concerned about implementing such a code style standard > for a couple of reasons: > > [1] I don't think we want to get into a situation where we are > dictating what IDE, if any, our contributing developers use. I would > want to make sure that any tools and/or plug-ins that we use for > automatic code formatting were free from dependencies on a particular > IDE. > > [2] Do we really need to have our contributing developers worry about > where they put the curly brace in the code? As was mentioned in the > discussion, I think there are other more important things we can do to > improve the quality and usability of our code. I'm thinking of things > like Javadoc comments, other source code comments, change logs, unit > tests and the like. I'd much rather fight for a requirement that all > public methods have an intelligent Javadoc comment or something > similar to that, than push for a standard variable naming convention > or rules geverning the placement of parentheses and curly braces. > > [3] How on Earth would we ever get our developers to agree on a common > coding standard? I can just imagine the discussions: > "Should all interfaces and exceptions should share a common prefix in > their class name?" "Should we ever allow passing a method call as a > parameter to a method call?" > > I just don't think we could all agree on this stuff, do you? I don't > think it would be worth the bickering to me. Maybe we could just adopt > an existing standard, but then we would all have to read an learn it, > and it would probably be different from what we used at work, and > we're probably to lazy to do it, and… > > In summary, if the source code a developer contributes is functional, > and I can understand what it does when I read it, I am happy. > Everything else is gravy. I know a lot of open source projects have a > code style standard, but I think our community is too diverse and > lacks the strong central authority necessary to make this level of > control successful. > > I am still open to further discussion on this topic. :] If we can > address some of these basic concerns I am more than willing to learn a > new tool or coding style. When I say this I speak only for myself, not > for the other developers or for the project iteself. > > The Sunburned Surveyor > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data
[JPP-Devel] Joining tabular data to a layer's attribute.
Hello Guys, The application i am working on requires loading tabular data from different database systems e.g SQLServer, Oracle. This data changes very frequently and is mainly numeric. Reading a table from a database is easy but how can I join such data to a layer's attributes. This would have been easy if the data was in postgresql, in such a case, one can easily use an SQL join statement. My questions are: 1. How can I join tabular data read from a database system like sql server to a layer's attribute ? 2. Are they plans in the future to enable OPENJUMP read/write data to other database systems ? Roman - Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us.- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] R: Multiple Layers from the same database connection
I can't completely understand what you're saying... Using the Datastore API you can open several layers from a single connection... You can try my PostGIS/Oracle plugin from: http://sourceforge.net/project/showfiles.php?group_id=118054&package_id=217237 But you pointed out something I never realized before, that inside a project/task file each layer has it's connection parameter repeated, does it mean that when a project/task is opened the Datastore API opens a separate connection for each layer??? I don't know that... But the connection dialog lists each connection only once, so there may be some smart code that "put together" identical connection opening them only once. I'll have to find the time to debug this... Anyway something able to "group" layers would be a great thing, so you can operate on a "group" (or may we call it a theme???) as a whole (hide/show, refresh, etc.). While I'm at it, even if it's not strictly related to this post, it would be great to be able to save inside a project/task file also a layer coming from Datastore query, otherwise you to manually recreate and restyle it every time you run OJ anew. Bye Paolo Rizzi > -Messaggio originale- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > conto di Paul > Austin > Inviato: martedì 29 maggio 2007 22.16 > A: jump-pilot-devel@lists.sourceforge.net > Oggetto: [JPP-Devel] Multiple Layers from the same database connection > > > All, > > I've been looking at the existing database and file plugins and the > com.vividsolutions.jump.io.datasource.DataSource class and from what I > can tell there is a one to one relationship between a layer and a data > source. > > What I would like to do for some of the file and database based data > sources is to have the concept of a DataSource that can contain many > different layers. Within a project you would be able to select which > layers you wanted to view from that data source. > > In the database world this concept would relate to having a connection > to the data base using a java.sql.Connection. When adding the database > connection to a project there would be a UI that would list the > available layers (database tables) and the user could select which > layers they wish to view. This compares to the current PostGIS plug-in > where you have to manually enter the connection and table details for > each layer. > > When the project is closed then the "connection" must also be closed. > > In the Jump project file the "connection" parameters would be stored > once, then the data sources used for each layer would reference the > "connection" and have a different query for each table. > > Now if we look at a file based example, I have a file format which is > basically a zip file that contains one file for each layer along with > some metadata files. I would like to be able to open the zip file and > create a layer for each of the layers in the zip file. To do this I > would extract the file to the temp directory and as required load the > data from the individual files in the temp directory. Then when you > close the project the "connection" is closed by deleting the temporary > files. > > Another file based example would be to open a directory of files, > loading each layer file in that directory, this is basically > the same as > the zip file idea but without the temporary files. > > In both the file cases once the file is loaded the first time the user > can select which of the layers to view. > > So the question is, does any of the existing functionality in > JUMP allow > for multi-layer data sources? If not I'm going to do some prototyping > for the file format I have and then share this with the group for > comment to see if it would be useful elsewhere. > > After that I have an interest in Oracle connections so would > need to do > the same kind of thing there. > > One other question, where would I find the code for writing out the > project .jmp XML files as I'd need to add the "connection" definitions > to this. > > Cheers, > Paul > > -- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ju
[JPP-Devel] R: Code Style Standards
Please no... Writing software it's already a hard job, expecially working software... There's no way to adopt good coding standards without using tools that it enable it. If you work in a big organization they may have a corporate IDE using corporate standards and, in that case, following those standards may let you save time, because you don't have to think about how to name things and the like. But this is not the case when everyone works on its own using his own preferred tools. Recommendations about comments and package names may be useful, expecially package names. Also about tests, configurations, etc. But just recommendations, not anything more strict than that... Bye Paolo Rizzi Programming is a joy but, nonetheless, it's a job too and it may be a hard one at thatas such, it'It's already > -Messaggio originale- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] conto di > Sunburned Surveyor > Inviato: mercoledì 30 maggio 2007 5.59 > A: List for discussion of JPP development and use. > Oggetto: Re: [JPP-Devel] Code Style Standards > > > Martin, > > Please see my comments below. > > Martin wrote: "Well, now we're getting closer to the bone... As tools > have improved > I've found myself using name prefixes in fewer and fewer situations. > All the IDEs I've used in the last 6 yrs can easily tell you whether > something is a class or an interface, and what its parent > class is. So > I try and avoid embedding too much type metadata in names. I > think this > is the usual Java convention as well - I've never seen *any* types in > the Java APIs which use these conventions." > > I can understand the need to be cautious about embedding too much > metadata in a name. I worked with a guy that like to put all sorts of > information in a file name. Something like: > > 20070530-Created_By_Sunburned_Surveyor_Read_Only_Peters_Comput > er_Backup_Directions.txt > > This always drove me crazy. :] > > Martin wrote: " > I know MS popularized using I* names back in the old COM days, and I > think they've propagated this into the .Net world as well. > Another good > reason to avoid it, IMO. Might as well use that lovely m_* convention > for instance variables, not to mention prefxing every variable with a > secret code word that reveals its type to those who speak Hungarian... > 8^) (Luckily the inventor of this has exiled himself to far > earth orbit...) > " > > Yup. I guess I took my habit of prefixing interfaces with an the > letter "I" from my days programming in Visual Basic to my Java > programming. Old habits die hard... > > At any rate, I guess my idea of prefixing class names isn't that > popular. :] What did you have in mind when you said: "Naming of > methods, classes and packages is more visible (in increasing > importance) - articulating some policies here might be helpful." ? > > Thanks, > > The Sunburned Surveyor > > Naming of > methods, classes and packages is more visible (in increasing > importance) > - articulating some policies here might be helpful. > > On 5/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > Rant on Martin. > > > > LOL > > Larry > > > > On 5/29/07, Martin Davis <[EMAIL PROTECTED]> wrote: > > > > > > > > > Sunburned Surveyor wrote: > > > > Martin, > > > > > > > > See my comments below. > > > > > > > > Martin wrote: "Naming of > > > > methods, classes and packages is more visible (in > increasing importance) > > > > - articulating some policies here might be helpful." > > > > > > > > You make a good point here. I prefix all of my interfaces with a > > > > capital "I", all of my exceptions with the prefix > "Exc", and all of my > > > > JUnit tests with the capital letters "JU". I'm not > saying that we > > > > should use this particular convention. I'm just saying > that I have > > > > found it helpful to distinguish interfaces, exceptions, > and unit tests > > > > by their class name. Perhaps we could start our coding > standards with > > > > a discussion of how to make this distinction. > > > > > > > Well, now we're getting closer to the bone... As tools > have improved > > > I've found myself using name prefixes in fewer and fewer > situations. > > > All the IDEs I've used in the last 6 yrs can easily tell > you whether > > > something is a class or an interface
Re: [JPP-Devel] JoinTablePlugin in OPENJUMP 1.2 beta
aehmm.. sorry it was on the mouse menu now in beta 1.2 it is in tools\edit attributes stefan Stefan Steiniger schrieb: > > Roman Isitua schrieb: >> Hello Guys, >> >> 1. How can I bring tabular data from a database to >> openjump ? > in jump is a right-mouse-click-on-layer-name function which can be used > to add csv-txt file (table) data to a layer > >> 2. Can the JoinTablePlugIn be used to join tabular >> data from a database or dbase table ? > only csv > >> 3. Can tables be linked together instead of being >> joined ? I think this feature will be needed to handle >> one to many relationships e.g building occupancy > > yep.. could be a nice feature > you should add a feature request > >> 4. What is the structure of a .txt table. > > comma separated >> Thanks, >> >> Roman >> >> >> >> Looking >> for a deal? Find great prices on flights and hotels with Yahoo! FareChase. >> http://farechase.yahoo.com/ >> >> >> - >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] JoinTablePlugin in OPENJUMP 1.2 beta
Roman Isitua schrieb: > Hello Guys, > > 1. How can I bring tabular data from a database to > openjump ? in jump is a right-mouse-click-on-layer-name function which can be used to add csv-txt file (table) data to a layer > > 2. Can the JoinTablePlugIn be used to join tabular > data from a database or dbase table ? only csv > > 3. Can tables be linked together instead of being > joined ? I think this feature will be needed to handle > one to many relationships e.g building occupancy yep.. could be a nice feature you should add a feature request > > 4. What is the structure of a .txt table. comma separated > > Thanks, > > Roman > > > > Looking > for a deal? Find great prices on flights and hotels with Yahoo! FareChase. > http://farechase.yahoo.com/ > > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
