bugGnash - The GNU Flash player - Bugs: bug #21756, Potlatch OpenStreetMap editor...

 
 

bug #21756: Potlatch OpenStreetMap editor issues

Submitter:  None
Submitted:  Sat 08 Dec 2007 11:12:11 PM UTC
Votes: 60
 
Category:  None Severity:  3 - Normal
Release:  trunk Status:  Fixed
Privacy:  Public Assigned to:  strk
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 20 May 2009 12:57:49 PM UTC, comment #49: 

Seems fine now. Blocking while loading images is the major problem at the moment, but that's a different bug.

Benjamin Wolsey <bwy>
Group Member
Sun 14 Dec 2008 01:12:56 PM UTC, comment #48: 

Ready for test again. We now encode "strict" array as STRICT_ARRAY
for remoting and not for SharedObject.

please test test test.

Sandro Santilli <strk>
Group Member
Sat 13 Dec 2008 10:37:18 PM UTC, comment #47: 

I tried producing STRICT_ARRAY encoding with SharedObject
(as we have an automated test for it) but had no success.

Richard filed a "bug" for potlatch to remember to
try the remoting encoding looking for the heuristic
that triggers STRICT vs. ECMA :
http://trac.openstreetmap.org/ticket/1404

Sandro Santilli <strk>
Group Member
Sat 13 Dec 2008 09:29:24 PM UTC, comment #46: 

We may try that optimization thing, but would also
be worth trying to trigger the optimization with
the SharedObjectTest.as file in misc-ming.all as
I'm not sure if thre's a difference between remoting
and SharedObject for this specific case.

Specularly,trying to trigger encoding of an ECMAArray
for remoting would be interesting (just adding holes
or custom members should do).

Sandro Santilli <strk>
Group Member
Sat 13 Dec 2008 05:27:36 PM UTC, comment #45: 

I think I have found the cause of the "node with id 0" problem:

AMF has a type called STRICT_ARRAY which can be used as an optomization/simplification of objects who's keys are 0, 1, 2, 3 etc (starting at zero and going up without holes)

gnash currently does not use this optomization for encoding outgoing NetConnection.calls

the osm AMF parser parses STRICT_ARRAY and OBJECT types differently. It parses STRICT_ARRAY into a ruby array (with numeric keys) and OBJECT into a ruby hash with string keys.

In ruby, the hash and array are both accessed with the [] operator, but numerical arguments to [] do not match string keys.

Specifically what's happening, is that gnash is sending an object with the key "2" (string) and osm server is checking for [2] (numeric key).

We could fix this by adding the optomization to encode as STRICT_ARRAY when all keys are 0..n.

Jason Woofenden <jasonwoof>
Sat 13 Dec 2008 08:59:45 AM UTC, comment #44: 

Alright, so:

- GUI blockage is due to loading the images of the background.
  To fix that we'll need to implement incremental loading
  of bitmaps or load all in a cache file before passing the
  IOChannel to the constructor functions. Need some work with
  the BitmapMovieDef for this to work

- Connection lost to openstreetmap.org http server was fixed
  (bug in lighthttp not accepting Expect: 100-Continue)

- NetConnection.call reply handling fixed so replies bigger
  then 200Kb are supported.

- "Server error - node with id 0 found in way -2."  is still
  an issue. Would be useful to use a customized potlatch version
  to trace the node ids.

Sandro Santilli <strk>
Group Member
Fri 05 Dec 2008 05:35:15 PM UTC, comment #43: 

Jason, I confirm your same experience.
The blocked GUI is also very annoying, what can be blocking ?
The POST operation only I guess ?

Sandro Santilli <strk>
Group Member
Fri 05 Dec 2008 04:14:19 AM UTC, comment #42: 

wow, totally awesome to see yahoo imagery!

Editing is not reliable yet though. For example at this location:

http://openstreetmap.org/?lat=42.371706&lon=-71.103381&zoom=18&layers=B000FTF

It loads only the POI near the bottom of the school, but the streets never load. The error triangle goes off, and hitting retry goes nowhere.

Same thing here:

http://openstreetmap.org/?lat=45.566147&lon=-73.568599&zoom=18&layers=B000FTF

(All that loads for me is the bus stop)


This place loads fine though:

http://openstreetmap.org/edit?lat=43.62126&lon=2.28367&zoom=15

but when I draw a new way, and click to deselect and save, I get the error message: "Server error - node with id 0 found in way -2."

Do you all get the same results?

Jason Woofenden <jasonwoof>
Wed 03 Dec 2008 11:59:06 AM UTC, comment #41: 

Yahoo background imagery works for me now. I also get information about points I click on, which I don't remember working before, and generally editing seems to work as expected.

Gnash is unresponsive while it's waiting for things to load, so it takes a bit (well, quite a lot) of patience before things start working.

Benjamin Wolsey <bwy>
Group Member
Tue 09 Sep 2008 10:05:08 AM UTC, comment #40: 

Potlatch 0.10c (currently in progress) will have a couple of performance improvements anyway - 0.10b is pretty slow even on an Adobe player. --Richard

Anonymous
Tue 09 Sep 2008 09:57:46 AM UTC, comment #39: 

Saving streets now (rev 9706) works, play around here:

http://www.openstreetmap.org/?lat=42.3153&lon=12.1823&zoom=14

Next issue to be it really usable seems to be performance
(sometimes gets to high CPU usage while drawing)

Sandro Santilli <strk>
Group Member
Tue 26 Aug 2008 01:23:35 PM UTC, comment #38: 

the matrix bug is fixed. Ready to test potlatch again.
News about yahoo background image is that it relies on
a malformed XML (out of OSM control) so it'd take our
own XML parser to use.

Sandro Santilli <strk>
Group Member
Fri 15 Aug 2008 10:14:23 AM UTC, comment #37: 

It was my matrix changes. Revision 9593 works, 9594 doesn't.

Sandro Santilli <strk>
Group Member
Fri 15 Aug 2008 09:45:37 AM UTC, comment #36: 

Update: png loading is fine now.
Unfortunately, dunno which commit broke the roads showup.
Could be matrix-related or dunno what else.
And dunno which revno was working yet.
But it seems trunk revno 9595 fails in showing the roads.

Sandro Santilli <strk>
Group Member
Tue 12 Aug 2008 07:49:29 PM UTC, comment #35: 

There's another problem with the XML used for specifying tile backgrounds (try to enable the yahoo imaginery) and another with Png loader (OSM mapnick imaginery).

Changed the summary as this became a generic bug about missing support for potlatch (we're getting there, slowly)

Sandro Santilli <strk>
Group Member
Tue 12 Aug 2008 06:33:09 PM UTC, comment #34: 

collision detection is fixed now.
Next problem seems to be with order of calls
to callbacks (move some around till you get the alert
sign, click on it and retry, the "loading ways" label won't go away).

Sandro Santilli <strk>
Group Member
Tue 12 Aug 2008 04:43:16 PM UTC, comment #33: 

Next problem is related with selecting the roads.
Most likely this one: bug #23098

Sandro Santilli <strk>
Group Member
Tue 12 Aug 2008 03:33:56 PM UTC, comment #32: 

bug in previous comment was due to premature end of tag while parsing PlaceObject tag (the matrix element in particular).
Fixed now.

Sandro Santilli <strk>
Group Member
Tue 12 Aug 2008 03:18:50 PM UTC, comment #31: 

So news: Jason's draft remoting implementation is in trunk now, with a some cleanups of my own.

I do can see roads loaded, not taking too much to load given
a small enough extent.

Here's the call I use:

gui/gtk-gnash -vv 'http://www.openstreetmap.org/potlatch/potlatch.swf?d=326' -F2 -U 'http://www.openstreetmap.org/edit?lat=42.21796&lon=12.15373&zoom=16'  -P flashvars='scale=16&token=M8UKlJyOYPlAXBYNWFilC8F8GBSTue&lat=42.21796&long=12.15373'

When requesting tracks, potlatch loads an dynamically created SWF6 which gnash fails to parse correctly. An example is attached.

(file #16283)

Sandro Santilli <strk>
Group Member
Mon 04 Aug 2008 08:45:46 AM UTC, comment #30: 

Alright, I realized Jason already made clear about network byte order in methods signatures so I committed the patch.
About returning void* from ::data() it turned out to be unfriendly
to user code, in that C++ complains about convertion from void* to char* (while doesn't complain for the inverse).

Looking forward for testing potlatch!

Sandro Santilli <strk>
Group Member
Sat 02 Aug 2008 04:49:46 PM UTC, comment #29: 

Alright guys, let's try to make this conversation productive
and fun.
What AMF is needed for we still don't know completely.
We have some examples and some intuitions.
For sure we know it's used for "remoting" (the potlatch case)
and we do know it's used as the payload of RTMP.
Chances are it's also used as the format for FLV "data" tags.
Others anyone ?

Now. For the "remoting" case we know we need to encode to/from as_value, be it a complex or simple (primitive) datatype.

For RTMP we likely need more (I've heard rob talking about video and audio types, which are not known by as_value). Do you confirm Rob ?

Refactoring code later is fine to me, being a reverse engeneering project. So I suggest we just try to make new code
as much flexible as we may thinkg about it, so it's hopefully easier to refactor later.

In the SimpleBuffer case, my only concern is about keeping the
"generality" characteristic of its interface, which is don't assume short and longs only needs to be stored in network order
(which sounds like amf-specific, or more generally "encoding" specific). The idea of a separate class class would be to avoid sticking the specificities to the NetConnection class, again to make further refactoring easier (move the specific code under the AMF namespace or similar).

module-static functions or private methods are also fine to me.
Just trying to avoid creating public interfaces other devs may rely on w/out being well tought.

Sandro Santilli <strk>
Group Member
Sat 02 Aug 2008 01:06:17 AM UTC, comment #28: 

Rob:

Alright Mr. "I did answer all your questions." Please answer both of my questions. Here's the one you missed: "Element is harder to work with (and much slower at runtime) than raw AMF data. So then why should I use Element?"

Thanks for pointing out clearly the code in SharedObject.cpp. I see that it is pulling key/value pairs from a vector of Elements and constructing an as_object. I want to convert from AMF to as_value. I'm afraid I said "as_object" before. My mistake. This code is not usable for me because:

1) it is buried deep in a function that does all kinds of other stuff.

2) it is far from complete (eg it doesn't support arrays or nested structures)

3) Seems to assume that the contents of the AMF is a single object (which is not the case for me.)

If it were factored out, and completed, and the API set right, I see how it could be useful. You pass in an element, or vector of them or something, and you get back an as_value.

Then I could call AMF::extractAMF(ptr, end) to make Element(s) and pass them to the above function. This would be problematic in that:

1) it's slow

2) it's confusing (should be named extractElements()) and has comments that aren't remotely true, and confusing terminology.

3) I don't understand why it needs an instance of AMF to run, except that's where it sticks the number of bytes parsed

4) it's incomplete (I need at least the array type)

5) it's buggy. eg only once in the entire function do you check the available size in the buffer before reading from it.

6) it doesn't allow long strings. This is absurd. You should just check if the string is inside the buffer.


There are bits and pieces of code here and there throughout your code that together could convert AMF to as_object and possibly as_value. This code is scattered, porely documented, buggy and in some cases (like SharedObject.cpp:400-427 that you mentioned) completely inaccessible in it's present form.

If you are truly interested in brainstorming, you will need to seriously step up your level of communication with me. You ignore most of what I have to say, and when you do actually reply directly to my questions you're usually not actually giving me the information I asked for, just something related.

I have asked you many times why you have created the Element class. You have ignored me every time. If I could pry loose a little information from you about what you're trying to do with this class. If you had provided me with this information, I would have been able to work towards an AMF parser that could fulfill both our needs. But since you wouldn't talk about this with me I ended up just writing code to meet my needs.

Jason Woofenden <jasonwoof>
Fri 01 Aug 2008 11:10:33 PM UTC, comment #27: 

Try lines 400-427 in SharedObject.cpp. It creates new as_objects from Elements. It's reads AMF objects from a Local Shared Object file, and converts them to as_objects, so they're accessible (complete with all properties) to a swf program. You must have just missed this when looking at the code. Yes, your particular purpose is much more limited than what libamf is designed to handle, so I can see why you decided to "just make something that works".

I have no problem with substantial changes to libamf, but would prefer folks brainstorm with me first about those changes. I've spent many months researching RTMP and writing an implementation of RTMP and AMF, and to change libamf properly requires some knowledge about how the whole thing has to work.

Rob Savoye <rsavoye>
Group administrator
Fri 01 Aug 2008 07:05:56 PM UTC, comment #26: 

Rob:

You have certainly not answered all my questions. You have responded to most of them, usually giving me related information, or telling me to read source files but not actually answering them. Here's the question I've been asking you over and over again that still has not been answered correctly:

Where is there existing code that converts from AMF to/from as_object?

The most specific answer I've gotten from you was to read some source file. However upon reading that file, I discovered that it did not in fact convert to (or from) as_object.

I've asked you about this many times, and searched extensively through the code, and I don't think it exists.

And here's the point I've brought up to you many times, which you have yet to respond to directly enough that I get your point:

Element is harder to work with (and much slower at runtime) than raw AMF data. So then why should I use Element?


I understand your concern about duplicated effort and worse duplicated code. My AMF code doesn't do the same thing as yours, mine creates as_objects and converts as_objects to AMF.

I think that AMF is simple enough that it needs no intermediate format for conversion. I need AMF converted to/from as_object, and I think this should be done directly.

If you need AMF converted to/from some other type, then there should be code to do this conversion. Maybe (though I doubt it) Element is that other type that you need your data in. If so, great, that code exists!


I am tempted to make lots of changes to limamf, but as a newcomer to this project, I don't feel it's my place to reorganize existing code that much. Also to do this sort of change well, and have my changes actually stick, I'd have to work closely with you. Currently I don't think I communicate with you well enough to do this successfully/amicably.

So I've just gone about my task, using what I can find that looks good, avoiding code that I think should be removed or rewritten. I'm sorry that this may cause you more maintenance time in the future, and I appreciate your willingness to do this if necessary.

Jason Woofenden <jasonwoof>
Fri 01 Aug 2008 06:32:33 PM UTC, comment #25: 

Don't blame this on me, I did answer all your questions. You just seemed to dislike having to figure out how the existing code worked. As your code for NetConnection::call() works, and I am also glad that openstreetmap.org works with Gnash, I don't have a problem with your patch.

I do want to discourage future Gnash hacking with AMF from ignoring libamf, and continuing to implement alternate versions of code that also already works. I'll have to throw out most of what you are doing in a few months, to replace it with code that uses libamf and libnet, when I add full RTMP support to Gnash. I'm trying to avoid a duplication of effort as a waste of time, which has nothing to do with being on a payroll or not. As the person that started the Gnash project, I'm just trying to keep our development focused.

The headache with these single-purpose patches is they don't really care about the rest of Gnash. If libamf isn't suitable for what others are trying to accomplish, then it should be evolved, instead of ignored.

Rob Savoye <rsavoye>
Group administrator
Fri 01 Aug 2008 05:30:42 PM UTC, comment #24: 

While it's true that there is existing code that parses AMF, it does not convert the data into a useful format. The Element class is harder to work with than the raw AMF data.

Rob: I asked you probably 10 times to explain Element, or to show me where there was conversion between AMF and as_object, and you have failed to do either.

If there is actually code to convert between AMF and as_object then I have wasted some time. But I don't think this is the case.

Also wasting time is a moot point, since you're not paying me and I've already done it.


The alternative to encoding/decoding directly, would be to encode/to Element, and then from that to the format I actually want. This would be at least as difficult as what I have done, and would be much much less efficient.

The AMF format is trivial. All it takes to encode/decode is a few functions to pull/push the multi-byte values out in the propper endian. We need to have those functions anyway, to deal with other headers used by NetConnection::call() and others.

My code that handles AMF is clean, efficient, easy to read, and easy to maintain.

You can rearrange it if you like. I really don't care if those functions are methods of SimpleBuffer, or some other class or global functions. My inclination is to just make functions in the file I'm working in, and you guys can decide if they are useful to other parts of the project, and if so package them up in whatever way you think is most useful. But... If you can agree on a particular method I'm willing to spend some time arranging it that way.

When I finish aggregating NetConnection::call()s so they send a bunch over one connection and do proper multitasking (except for DNS lookups) I'm going to submit some code that will work well enough for Potlatch. I really really just want you to accept this new feature into gnash. openstreetmap.org is very very cool community project and it drives me nuts that I can't be part of that community without Adobe's buggy proprietary plugin.

Jason Woofenden <jasonwoof>
Fri 01 Aug 2008 01:56:57 PM UTC, comment #23: 

Gnash already has an entire series of AMF encoding and decoding support in libamf. Your problem is that you're writing all new code to do something that there is already existing code for, so it's a huge waste of time. Any of the Element class can encode itself into an AMF object, so this is already been done.

Rob Savoye <rsavoye>
Group administrator
Fri 01 Aug 2008 08:42:08 AM UTC, comment #22: 

I think it would make more sense to have an AMFEncoder class (and probably an AMFDecoder class too) to take care of byte swapping and amf-specific issues like versioning (that would call for instance, not class methods).

Dunno much about AMF to tell how much those would be reusable,
but I do know we have different uses for AMF (not just NetConnection).

Sandro Santilli <strk>
Group Member
Thu 31 Jul 2008 07:22:12 AM UTC, comment #21: 

encoding AMF0 is so trivial that it seems easiest to me to append directly to a buffer.

All that's needed to keep things simple is something that will append multi-byte values correctly. Also it's great having the type in the method/function name because then it's trivial to get enums and literals to encode to the right number of bytes.

I don't understand the harm in having long-winded members of SimpleBuffer. No meaningful namespace pollution, and there shouldn't be any confusion about what they do.

Whatever your reason, if you really don't want them in there, I'll make them private/static functions in NetConnection.cpp. I just put them into SimpleBuffer for convenience, and I thought someone else might be able to use them.

Jason Woofenden <jasonwoof>
Thu 31 Jul 2008 06:50:05 AM UTC, comment #20: 

Sounds indeed fair to take void* for append, but then, should data() return void as well ?

As for byte swapping I don't like the forced network byte order.
SimpleBuffer should just be a memory buffer, not a serializer.
I suggest you use some sort of serializer class, possibly filling
a user-provided SimpleBuffer. The serializer would be specific
to the format you intend to use...

Sandro Santilli <strk>
Group Member
Thu 31 Jul 2008 05:41:58 AM UTC, comment #19: 

Potlatch needs NetworkConnection::call() for networking. Which I have about half written.

When I first started writing my code to encode and decode AMF (serialization used by NetConnection::call()) I needed lots of silly casts and unnessesary variables to be able to use SimpleBuffer::append(). I'm attaching a patch for SimpleBuffer that does 2 things:

1) append() takes a void *. seemed unfair that NetStream took a void pointer and not SimpleBuffer::append(). This allowed my code to be a lot cleaner, not needing to cast all pointers passed to append().

2) Added methods for appending bytes, shorts and longs without needing to do byteswapping or creating L-values.

If these additional methods are undesirable/unacceptable then I can recode them as static functions or some such.

(file #16214)

Jason Woofenden <jasonwoof>
Fri 11 Jul 2008 12:17:14 PM UTC, comment #18: 

Since you got distracted by spam I'll give you a good news:
someone is working on support for remoting these days.
It should be the missing block for potlatch support.

Sandro Santilli <strk>
Group Member
  Spam posted by anonymous
  Spam posted by anonymous
  Spam posted by anonymous
  Spam posted by anonymous
Wed 30 Apr 2008 04:41:44 PM UTC, comment #13: 

Well, scissors tool is also fixed.
I guess next step will be NetConnection and the RTMP stream.
Changing severity to normal as that's a new feature anyway.

Sandro Santilli <strk>
Group Member
Wed 30 Apr 2008 03:55:53 PM UTC, comment #12: 

Fixed wordWrap/noScale of TextField (label near the 'play' button),
now tracking invisible scissor icon on startup.

Richard: you're doing dirty things with that 'function updateScissors(v)' function btw, you only call it with either no arg or 'false' as arg, while the function uses it as if it was a number (50+50*v).

Sandro Santilli <strk>
Group Member
Tue 29 Apr 2008 11:35:14 AM UTC, comment #11: 

I added non-scaled strokes support. Not deeply tested
as per collision detection, but AGG renderer seems to
be doing the right thing for potlatch now.

Sandro Santilli <strk>
Group Member
Mon 28 Apr 2008 11:05:34 AM UTC, comment #10: 

just a note, since Richard and Steve provided a testing server:
http://wiki.openstreetmap.org/index.php/Potlatch/Development_overview/Installing_and_compiling

I committed a couple of patches making potlatch back in pretty
shape.

There are probably multiple places that will fail,
NetConnection is likely important for things to work, as
it is used to connect to the OSM api.
SharedObject is likely optional.

I'm now tracking issues with size of the lines drawn.

Sandro Santilli <strk>
Group Member
Tue 08 Apr 2008 02:40:15 PM UTC, comment #9: 

It's a potential bug in the test case for SharedObject, not the libamf code. I get zero problems with ::setName() from any of the test cases, so I'd test your source tree. This should have been fixed two days ago.

Rob Savoye <rsavoye>
Group administrator
Tue 08 Apr 2008 09:51:04 AM UTC, comment #8: 

The SharedObject code still relies on uninitialized memory,
so better to fix that before attempting to debug real-world
movies (would be hard to figure out with arbitrary memory).
See Bug #22806 (comment 12)

Sandro Santilli <strk>
Group Member
Mon 07 Apr 2008 09:57:04 PM UTC, comment #7: 

This code also found a bug in our SharedObject class, which I think is the AMF part you referred to. The Preferences data written & read to preferences.sol contains an object that isn't correctly decoded. There have been a lot of recent changes to the low level part of how we handle AMF objects, so that bug may also effect this swf file.

Rob Savoye <rsavoye>
Group administrator
Mon 07 Apr 2008 09:41:19 PM UTC, comment #6: 

Awesome, I can ask the author direct questions. :-) Looking at the code, I see it uses Ming, so I guess I can go test it myself and use this as a test case for implementing ::call(). It looks like in this case NetConnection::call() is being used to set properties in the NetConnection class itself without needing to use LocalConnection or RTMP to do anything with the AMF object itself. I grabbed potlach.swf, and running in Gnash standalone, I get the error message too, so I assume now I can figure out exactly what it wants to do.

Would it be possible for you to extract the relevant lines of code and make a test case we can use ? Good test cases make it much easier to implement missing functionality, especially if they build with Ming. obviously the existing test case in Gnash for NetConnection is missing some tests.


Rob Savoye <rsavoye>
Group administrator
Mon 07 Apr 2008 09:18:25 PM UTC, comment #5: 

From: Richard Fairhurst (potlatch author)

> AMF yes, but not RTMP.

Sandro Santilli <strk>
Group Member
Mon 07 Apr 2008 08:05:56 PM UTC, comment #4: 

NetConnection::call() is a Remoting thing. We need a working implementation of Remoting to support this. Remoting requires solid AMF support, and I believe also RTMP for transferring the objects between the server and the client. More reasons to work on Cygnal... but I plan to be working on this shortly, as I am working on AMF and RTMP support for Gnash & Cygnal. Making Remoting work is complex, so I wouldn't expect this to start working any time soon.

Rob Savoye <rsavoye>
Group administrator
Mon 07 Apr 2008 05:37:21 PM UTC, comment #3: 

The only clue in the debug output:

47465713678512] 19:32:12: UNIMPLEMENTED: NetConnection.call()

That might explain why it never starts properly, though.

Benjamin Wolsey <bwy>
Group Member
Wed 06 Feb 2008 06:46:01 PM UTC, comment #2: 

I have checked with cvs, there is now nothing but a big white void.

(file #14975)

Anonymous
Tue 11 Dec 2007 03:41:11 PM UTC, comment #1: 

You may surely help by fetching gnash from CVS and trying again.
Then by trying to compile the actual application from source so to be able to add debugging calls here and there.

Sandro Santilli <strk>
Group Member
Sat 08 Dec 2007 11:12:11 PM UTC, original submission:  

This seems to be a known bug, but I couldn't find it in the bug tracker.

Using the online Potlatch OpenStreetMap editor (clicking Edit from http://www.openstreetmap.org ) works as expected when using Adobe's Flash Player on Ubuntu Hardy Heron Alpha 1. It does not work correctly using the latest update of Gnash (0.8.1-0ubuntu3). The SWF application displays heavily offset in the bottom right corner (so that only the top left of the application is visible).

I have attached a screenshot of the page using both Adobe's plugin and Gnash to show the comparison.

Potlatch's source code can be obtained here:
http://wiki.openstreetmap.org/index.php/Potlatch/Development_overview
Note that this page also says:
"# If you want to be really super helpful, how about helping to make Gnash compatible with Potlatch? :)"

If there are any logs or other help that I can offer, please ask.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #16283:  potlatch_data.swf added by strk (1KiB - application/x-shockwave-flash)
file #14975:  gnash-dbg.log added by None (4KiB - text/x-log)
file #14595:  Gnash_OSM.png added by None (77KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sward (Voted for)
  • -email is unavailable- added by davidfraser (Voted in favor of this item)
  • -email is unavailable- added by jasonwoof (Updated the item)
  • -email is unavailable- added by jasonwoof (hacking gnash so it supports potlatch)
  • -email is unavailable- added by strk
  • -email is unavailable- added by rsavoye (Posted a comment)
  • -email is unavailable- added by bwy (Posted a comment)
  • -email is unavailable- added by strk (Posted a comment)
  • -email is unavailable- added by aaronw (Updated the item)
  • -email is unavailable- added by aaronw
  •  

    There are 60 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-07-15 sward Carbon-Copy- Added sward
    2009-05-20 bwy StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2008-09-18 davidfraser Carbon-Copy- Added davidfraser
    2008-09-09 strk StatusIn Progress Ready For Test
    2008-08-12 strk CategoryRTMP and AMF None
        SummaryPotlatch OpenStreetMap editor displays heavily offset Potlatch OpenStreetMap editor issues
    2008-08-12 strk Attached File- Added potlatch_data.swf, #16283
        Assigned toNone strk
    2008-08-01 rsavoye ReleaseNone trunk
    2008-08-01 rsavoye Assigned torsavoye None
    2008-07-31 jasonwoof Attached File- Added simplebuffer_api_additions.diff, #16214
    2008-07-12 jasonwoof Carbon-Copy- Added -email is unavailable-
    2008-07-09 strk Attached File#16046 Removed
    2008-07-09 None Attached File- Added powered_apache_80x15.png, #16046
    2008-04-30 strk CategoryNone RTMP and AMF
        Severity4 - Important 3 - Normal
        Assigned tostrk rsavoye
    2008-04-28 strk Categorycygnal None
        StatusPostponed In Progress
        Assigned torsavoye strk
    2008-04-07 strk Carbon-Copy- Added -email is unavailable-
    2008-04-07 rsavoye CategoryNone cygnal
        Severity3 - Normal 4 - Important
        Item Group0.8.1 release None

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code