Request: Allow python style block comments as a function keyword argument option about sjson HOT 20 CLOSED

Do you have a full example file I can try? This shouldn't be too hard to add.

from sjson.

Can you please try the speculative fix and see if that works? If so, I will prepare a new release with it.

from sjson.

Apologies, I was in transit trying to escape getting locked in by covid so I couldn't respond

from sjson.

We have a local version of your module to fix these issues
SGG-Modding/SGG-Mod-Format@ae60616
SGG-Modding/SGG-Mod-Format@0c75320
Can use them to see working examples

from sjson.

It looks like from the comparing code your speculative fix would work for the standard tripple quote case but not for the implicit quadruple quote case, don't blame you as I didn't mention that at all.

from sjson.

I tested the speculative fix, it doesn't crash but the output isn't kosher for the game, it crashes pretty violently (while the output from the local version does not crash the game)
Not exactly sure why.

from sjson.

What is the quadruple quoted case? Looking at your changes, I don't see test cases (I'm sure they're somewhere in the repo, just don't know where :) ). If you could point me at a sample file then I can make it work, without it I'm stabbing in the dark here.

from sjson.

Please try: 5e0c0b6 -- that comes with unit tests for quadruple (and while we're at it, quintuple) quoted strings.

from sjson.

This is what Paradigmsort/parasHadesMods said about it when I asked

"yeah, iirc the upstream only supports block quotes in the input, but it doesn't remember what was a block quote for the output
so it outputs strings with escape characters etc. in them that the game didn't understand
there were just too many differences i think for upstreaming the changes to make sense"

from sjson.

The tests we use are the actual game files from Hades, I don't want to distribute them wholesale

from sjson.

If the differences are too big, then I don't really see a point in trying to support Hades specific files to be honest. Please give the commit I referenced a try, if it works, great, if not, I guess I'll revert it as I'm not willing to support something I can't test (given I don't own the game!)

from sjson.

I think the issue is that the multiline strings in the input become regular strings containing escape characters in the ouput

from sjson.

So the object in memory needs to change to remember that it's block quoted

from sjson.

Failing that, yeah I guess you could revert and we'll try making a PR later which you can test still meets the rest of the features of the module

from sjson.

I'm not following: With the latest commit, a multi-line, triple-quoted string remains multi-line. If that's not helping anyone, I'd rather remove triple-quoted strings, but I don't follow your statement about multi-line -- I've even checked in a test case for it:

from sjson.

Alright, I'll test it

from sjson.

So again, program runs, but the game errors on reading data.
It might have something to do with encoding

from sjson.

Oh I see, the output doesn't place the (usually implicit) { and } over it
But fixing that manually does not make it readable still.

from sjson.

Since the issues seem to lie with the game, it's our responsibility to fix that (and we can with wrappers or using our current local version)
But I think adding support for tripple quotes is still gonna be useful for other applications. And you've tested that your output is fine subject to all the normal assumptions you can make.

Is there any reason why [=[ was chosen for block quotes originally?
That the devs of this game decided to use tripple quotes implies to me that sjson has no standard for block quotes (at least not established prior to 2018)

from sjson.

Yes, the main reason to choose [=[ was to match Lua and have an easier time parsing it than """ :) The advantage is that it only requires finding ]=] to terminate the search, while """ is "harder" in the sense that it requires more lookahead (and given SJSON doesn't use a tokenizing parser ...)

SJSON is not specified at all, so everything goes, when I added raw strings back in the day I picked the easiest variant. In any case, I'm going to keep the triple-quotes as-is now and prepare a new release with it.

from sjson.