On Thu, Mar 22, 2012 at 3:27 AM, Andy Allan wrote:
> Finally, in other projects I follow the convention of "don't code
> defensively", as described at
> http://www.erlang.se/doc/programming_rules.shtml#HDR11 and elsewhere.
Quote:
"The function will crash if Option neither normal nor all, and it
s
On 21 March 2012 16:34, Richard Fairhurst wrote:
> I've corresponded with Thomas B and found some, ahem, fairly easy steps to
> reproduce:
>
> 1. Click on map (_once_) to start new way
> 2. With elastic band still engaged, click 'Save'
> 3. Whatever the opposite of PROFIT is
>
> Will look at it t
Andy wrote:
> Anyway, mumble grumble unit testing. When we find out what's the
> trigger, for the love of god someone should help me write the unit
> test so that when it's fixed, it stays fixed.
I've corresponded with Thomas B and found some, ahem, fairly easy steps to
reproduce:
1. Click on map
On 21 March 2012 12:56, Steve Bennett wrote:
> 1) We can fix this, but it's hard to prevent it coming back when new
> features are built. I've probably written such bugs.
Mumble grumble unit testing.
> 3) I still think we should do this. We have a responsibility to not
> mess up the database. S
On Wed, Mar 21, 2012 at 10:14 PM, Richard Fairhurst
wrote:
> 1. In the UI (i.e. don't let the user create them in the first place)
> 2. In the entity model and actions (i.e. don't let them get into P2's
> internal data)
> 3. In the upload code (i.e. don't let them be transmitted to the server)
>
>
[copied to potlatch-dev, followups probably better there]
Steve Bennett wrote:
> One thing we could add (in addition to trying to fix bugs in the
> various places 1-length ways could be created) would be a
> general filter at save time that prevents any 1-length ways
> being sent back to the datab
