map repo

[Fred]

I spent some time over the last day working w/JSON - it's so simple how can major changes to the spec even effect anything ? I tried to find anything I could on how the spec is unstable, but all of my googling came up with nothing. The entire spec fits on a webpage complete w/diagrams :lol2: .. In the implementations I browsed through there is a small token based parser. You don't get all the fancy parsers that come along w/xml based stuff, but in this case I see it as a plus.

OK, for a start, which of the, at least two, specs are we discussing here? ;-)
Secondly, join the JSON mailing list to see the instability.
Thirdly, NO COMMENTS! This I have a seriously hard time with! This is my main issue with it.

If you are going to use a standard, it needs to be a standard and the standard excludes comments, that is to say that comments are NOT valid JSON and parsers do NOT need to handle them and can throw a parse error for them. This is different to not including comments in the standard, comments are excluded :-(

I want comments! (I think that is a reasonable requirement) and if we have to modify JSON to achieve that, then we effectively have a custom data format. Maybe a custom format with a JSON flavour is the right approach anyway? For me it leaves a bad taste in my mouth that I have trouble forgetting.

Fred.

[EssEss]

hmm. I did notice that there were no comments ... but a lot of parsers (not all) accept a simple '//' (to eol) and skip over it. I never intended on making a data file from scratch, which is where I would most likely insert comments. It was nice to find something that was more readable, and xml isn't that bad to read .. I guess I should revise my original request to anything but binary or .ini

[sry_not4sale]

That's right, we were talking about a possible compiler to remove the comments weren't we...

The thing is (to me at least) JSON is just a portable subset of Javascript - so it should handle javascript comments.

Then again, JSON was originally designed to be machine generated, and for communicating between server and client so I can see why the spec might lack comments.

I guess we just find libraries in python, C and Java? that have a common comment syntax and wait for the spec to catch up to us?

[Fred]

That is the point though, it *had* comments, the head honcho arrogantly removed them and listens to no one who thinks it could have been a bad idea. Sad really, I do like it other than that. I'll split this thread up soon. Keep posting in here for now, but keep stumble and json posts seperate (post twice if you have to)

Fred.

[sry_not4sale]

That is the point though, it *had* comments, the head honcho arrogantly removed them and listens to no one who thinks it could have been a bad idea. Sad really, I do like it other than that.

What had comments? A library? Libraries are replaceable...

[EssEss]

the spec.

[Fred]

the spec.

Yup, sadly this is what I meant.

[jbelanger]

This is so unbelievably shortsighted. I find it hard to see any possible justification for doing such a thing. So according to the specs, everything has to be parsed?

Jean

[jbelanger]

If it is possible to run from a flash block while erasing/programming another one, then it is a sloppy software architecture/design.

Disagreed. Do not forget that there are many other reasons to distribute data into different flash blocks too. If it makes sense for other functional reasons to divide things up in a way that causes burn stumble then chances are I will have burn stumble rather than skew the design in significant ways to prevent something that at the end of the day simply does not matter.

I may have been a bit shortsighted in my comment. I can see that there would be some reasons. However, you'd have to weigh those against the code taking a nap for a while. The stumble while tuning is one thing that could be ignored but that doesn't mean that there wouldn't be legitimate reasons to not want to pause the code while writing to the flash that are yet to even be thought about. So having the code designed for that at this time would save some time later when re-designing a full featured and evolved working code would be much more of pain.

You don't have a wait loop when you're reading an ADC, why would you do that for flash programming? A bit extreme for a comparison but still a similar idea.

Sure, understood, but that does not mean that while designing the structure of the software you are sloppy if you choose to have that happen rather than N other compromises that you may have to make to achieve not doing that.

Anyway, we WILL look into it, but I really don't think it's intelligent to compromise functional design for that unimportant inconsequential niggle.

Fred.

Agreed that some compromises may have to be done. As long as it's done after considering all the facts and not because it was done like that somewhere else or it was easier that way (which might actually be a good reason under some circumstances), then you're right that it's not being sloppy. If the only reason is that the stumble is not important anyway then it is sloppy.

Having said all that, I've probably overemphasized the importance of this. There are plenty of things with more importance at the stage of the project. It should just be on the TODO list (as you say it is). And just to be clear, my concern is NOT the stumble but the fact that the code is suspended for an indeterminate amount of time while the engine is running.

Jean

[Fred]

This is so unbelievably shortsighted. I find it hard to see any possible justification for doing such a thing. So according to the specs, everything has to be parsed?

Yup, my jaw dropped when I read his responses to this issue. Moron. Now, do you wanna be at the mercy of such a person and their whims? I don't :-(

On the other topic, thanks, I think we agree entirely, as usual :-)

Fred.