Re: [josm-dev] JOSM Ticket #263, cancelling an upload
Dirk Stöcker wrote: On Sat, 9 Aug 2008, Frederik Ramm wrote: Dirk's suggestion sounds not too bad. If we manage to educate our users a bit (after a failed/cancelled upload, make sure to re-download the area from the server before re-attempting the upload) then the problem When reuploading: Warning. There is a upload in unknown state. Redownload area to verify. :-) Watch out with this one, to make sure that you can download an appropriate area, rather than the whole bounding box that is loaded into JOSM. Most of the time that I'm editing I have to download in small chunks otherwise the osm server rejects the download based on too many nodes. Shaun ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
Dirk Stöcker napsal(a): On Mon, 11 Aug 2008, Frederik Ramm wrote: Gerv also hinted at the fact that JOSM is written in a way that is somewhat untypical for Java, and whenever a newcomer to JOSM programming said this is all bullshit let's refactor it wholesale I told them to please find another project to refactor wholesale. I always thought that the peculiar way in which JOSM is done has a lot going for it and makes it easy to work with the code. When we're at it, I'm not sure the way josm is written makes it any easier to work with the code. Using accessors is the standard way every java programmer understands and the code clutter is not much of an argument. Moreover, josm uses unusual L10N way (I must admit that for a reason this time, though not a strong one) and unusual (and harder for anybody writing DataSet modification actions, easier to break) undo system. I would put it this way: josm-ng currently is mostly an experimental platform* trying whatever is posible to do regarding memory usage, editing/rendering speed, and currently rendering accuracy (my current, uncommited code has a provision for defining rendering of relations and can even render holes in multipolygons, not taking about different rendering available for different zoom levels, all this real-time up to the dataset of size of germany.osm). Some of my ideas can be backported to JOSM directly (Storage class, which is a kind of HashMap with much smaller footprint), some with much more effort, thanks to the way josm is written (keeping a bbox of ways, having all the primitives stored in a QTree - the QTree approach needs the position writes to be intercepted, public fields is a big no-no for this). *) Well there are only about two unimplemented things preventing josm-ng to be used as a real editor - server I/O (reader part is there, of course) and tagging UI. BTW: I never would suggest or accept major changes. Every major change can be cut in pieces and introduced as smaller changes. This means you always have a stable working software compared to a large refactoring period. You have to write some intermediary code, but that also means half finished reworks (when the author no longer has time or interest) are better than nothing :-) Well, I can write a List implementation that would notify me about all the content changes, so I can keep the Way's bbox consistent even w/o disabling direct access to the Way.nodes field (and thus preventing patching next to every josm source file for this step just to start optimizations), but for other things (again thanks to the josm openness), such a large change might still be the very minimal prerequisite :-( When thinking of it now, I don't think starting josm-ng was a bad idea. It allowed me to prototype my ideas quickly and some of the ideas can still be taken from josm-ng and ported to josm. I'd like to write a summary wiki page, but haven't had much time for it yet. (writing documentation is much harder for us, programmers, than writing code ;-)) I'll try as soon as I return from vacation. It might at least remove confusion and maybe help somebody porting useful things from -ng or the other way around ;-) -- Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Difference between JOSM and JOSM-NG
Why are you using ant instead of maven in JOSM-NG? -- Best regards, Evgeny Mandrikov aka Godin mailto:mandrikov at gmail.com homepage http://godin.net.ru ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
On Mon, 11 Aug 2008, [EMAIL PROTECTED] wrote: the main benefit of encapsulation is to make code more flexible for refactoring, internal changes, performance optimization through implementation hiding That is true for new developments. For existing code other rules apply. The main rule here is: Changes should improve the software. Changes for the main benefit of cleaner style will be rejected. This is based on the fact that every change has side effects and very likely introduces new bugs. And please do not assume that encapsulation is always good. It also has negative effects and the right balance is important. in case of modular software like josm with plugins is encapsulation a must for development and has not only something to do with clean style of code Nothing is a must. As you see it works fine also without. refactoring and cleanups in an early phase of project are not so expensive and time-consuming like in a big grown old project. sometime it is to late to make big changes... It is never to late. This is always possible. BTW: Your shift and return keys are defective. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
Frederik Ramm wrote: I think if someone came along with a real good performance optimization for JOSM that, as an aside, requires more encapsulation than JOSM currently has, that would be a very good reason to add said encapsulation. Trouble is, until now we have had a lot of textbook lectures on how everything would be much better if only we had proper encapsulation, but never anything tangible. (Much like on the talk list, where every few weeks someone comes around and says what, you n00bs not using PostGIS?, to which the much-iterated reply is: show results.) The trouble with this logic is that it doesn't reveal or account for the hidden costs. For example, how can I evaluate how much more likely it would have been that I would currently be a JOSM contributor if I hadn't taken one look at the code and said Ick? I can't, but it's a non-zero effect. And how many more people are there like me? By its very nature, it's impossible to tell how many more contributors there would be, and how much better the code would be, if it was written more in line with standard Java best practice. But Petr and I are at least two data points. There's a great book called Economics in One Lesson by Henry Hazlitt. Even though it was written 50 years ago, the one lesson is still relevant. It is: The art of economics consists in looking not merely at the immediate but at the longer effects of any act or policy; it consists in tracing the consequences of that policy not merely for one group but for all groups. http://en.wikipedia.org/wiki/Economics_in_One_Lesson The effects on some groups are particularly hard to measure if they consist of someone not doing something they would otherwise do, such as contributing to JOSM. It's like governments putting up taxes. The visible benefit they claim is that they can spend more money on improving the lives of their citizens. The hidden cost is that each citizen has less money, and so they don't buy things they otherwise would and there's less economic activity. What things? Impossible to tell. But it's a cost nevertheless. Currently, JOSM doesn't care for plugins; everything is more or less wide open, and a plugin can do almost anything that JOSM itself could. Sometimes when you work on JOSM, you break a plugin; but on the whole, JOSM development is not hindered by myriad plugin hooks that have to be maintained, and plugin development is not hindered by having only access to a small plugin API. This makes it easy for both plugin developers and JOSM developers - at the occasional expense of stability. This is an entirely reasonable plugin model IMO; but it makes it all the more important for JOSM objects to hide their internal state from plugins using accessor methods and protected member variables. That way, you can override something if you need to be doing a derived class, but it means that plugins can't accidentally mess with stuff they shouldn't be. Gerv ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
Petr Nejedly wrote: When thinking of it now, I don't think starting josm-ng was a bad idea. It allowed me to prototype my ideas quickly and some of the ideas can still be taken from josm-ng and ported to josm. Petr, just out of interest, why didn't you base josm-ng on the NetBeans platform, given your day job? -- Jonathan (Jonobennett) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
Hi, Gervase Markham wrote: By its very nature, it's impossible to tell how many more .. or less .. contributors there would be, and how much better .. or worse .. the code would be, if it was written more in line with standard Java best practice. But Petr and I are at least two data points. And Imi and myself are probably people who get scared by it. It is totally moot to discuss what if. We'd attract different people and it would be a different project. Some things would be better, some worse; some slower, some faster. Now JOSM really isn't that big. And everything is Open Source. And Petr has made quite a good start with JOSM-NG. I'd hazard the guess that, if you want a clean implementation of JOSM's features, it would probably be *less* work to sit down with the code and copy or re-implement for JOSM-NG than it would be to completely change JOSM. Why it hasn't been done yet, beats me. And this situation is not new; JOSM-NG has been around for quite a while now and, as far as I am aware, while we hear occasional whining about how JOSM is badly designed and how people would love to help but cannot, nobody has actually taken the time to give JOSM-NG the push it needs to become a full-featured JOSM replacement. I'm sticking to JOSM myself because I like its structure more and because I feel that we JOSM developers have a certain responsibility vis-a-vis the JOSM users to maintain the software, but as soon as there is something that looks and feels more or less like JOSM but is better designed and faster, I won't hesitate for a second to tell everybody to switch. I take the idea of changing code to be more attractive to potential programmers quite seriously. I have, for example, re-implemented the complete Osmarender XSLT code in Perl because I figured that this would attract more developers (anyone who has ever used trigonometry in XSLT will know why). But with JOSM-NG sitting around untouched by anyone but Petr himself, and this for the best part of a year, the argument that a properly designed JOSM would attract more programmers rings hollow. What JOSM currently needs most is a few people who share the responsibility, who make JOSM their project and who are willing to do more than submit the occasional patch. It seems to me that JOSM-NG, despite its clean architecture and technical superiority which I don't doubt for a second, has not managed to find these people either. Can we make it mandatory in the future for everyone whining about JOSM's programming model to explain why they're not working on JOSM-NG? Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] JOSM Ubunbtu debugger searched
Hello, ATM there are 7 reports related to an excpetion when calling preferences dialog on Ubuntu http://josm.openstreetmap.de/search?q=ToolbarPreferenceswiki=onchangeset=onticket=on None of the systems I have show that error, so I can't debug it. It seems GTK+ style usage is required for that. Anyone using Ubuntu, who can debug that? Minimum would be to find out, which value is causing that error (i.e. what is zero). Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Difference between JOSM and JOSM-NG
Frederik Ramm wrote: Hi, Gervase Markham wrote: By its very nature, it's impossible to tell how many more .. or less .. contributors there would be, and how much better .. or worse .. I think it's unlikely that moving code more towards standard Java-isms and industry best practice would discourage developers from working on it. I know you find this hard to accept :-) but best practice is best practice because a large proportion of Java programmers over time have discovered that it's the best thing to do for readability, maintainability, etc., not because some arbitrary cabal is handing down random decisions from on high. Take accessor methods, for example. Without them it's hard or impossible to use any of the Structural design patterns (Adapter, Bridge, Composite, Decorator, Facade, Flyweight and Proxy) because they require intercepting and controlling access to data. All of these patterns are used in extending a class to do something it couldn't otherwise do. When debugging, you can't easily find all the ocurrences where a particular class variable is modified, or add in debugging code to log the value every time it changes, or put a breakpoint on accesses. When maintaining, you can't easily see in what circumstances the variable is used (particularly if you have multiple variables of the same name which are members of different classes) and you can't add constraints e.g. to keep the variable's value in sync with another one, or prevent it being set to certain forbidden values. If working on performance, because the class used for internal storage is exposed to callers, you can't e.g. replace a linked list with a hash for efficiency reasons, or decide to lazily compute the value from other values. This and other considerations mean that any book you read on Java best practice (or any object-oriented language, for that matter) will recommend that you make your variables private and use accessor methods. Now here's the important point. You might say OK, so if someone did want to replace a linked list with a hash, they could implement accessor methods in the relevant places at that point. But that changes the task from a contained and testable performance optimisation in a single class to a tree-wide change, which will also break 3rd party plugins who used the interface of the public member variable. It's also harder to know if the change is safe, because you have to read and understand the code around every access to the variable to see if it's doing anything funny. You have a whole bunch of extra stuff to test, and have to deal with the breakage fallout. Multiply that up for each change of this sort you want to make, and you can see why people don't start down that rocky road. The stop energy barrier gets too great. You're right, I can't magically produce more developers if you agreed to let people refactor the code to match best practice better. But I can give you some reasons why the average Java programmer will find diving into the current JOSM codebase an unappealing prospect. But with JOSM-NG sitting around untouched by anyone but Petr himself, and this for the best part of a year, the argument that a properly designed JOSM would attract more programmers rings hollow. What JOSM currently needs most is a few people who share the responsibility, who make JOSM their project and who are willing to do more than submit the occasional patch. It seems to me that JOSM-NG, despite its clean architecture and technical superiority which I don't doubt for a second, has not managed to find these people either. One reason perhaps is that open source projects are successful in attracting developers when they already work (albeit imperfectly) for a task. JOSM-NG is not yet even a basic OSM editor, because (as I understand it) it can't return changes to the server. Gerv ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
