Closed clsource closed 3 years ago
It was stripped from the FileSystem coupling. Just encode and decode strings.
Wait, why wouldn't it just use the IO stuff from Wren Console for loading/saving files?
I couldn't make this work with wren-console.
What issue did you run into? If this builds on it's own you should just be able to build wren-console against the new version (maybe are re-running it's own pre-make?)
Wait, why wouldn't it just use the IO stuff from Wren Console for loading/saving files?
Is best that this only uses strings as IO. So it does not violate Single Responsability Principle from Solid.
What issue did you run into? If this builds on it's own you should just be able to build wren-console against the new version (maybe are re-running it's own pre-make?)
It builds, but I could not import it in wren-console for testing it.
import "json" for Json
Is best that this only uses strings as IO. So it does not violate Single Responsability Principle from Solid.
I don't believe that's a violation. Every good JSON library I know has a convenience load
and save
method... or perhaps it is a violation AND a useful exception that proves the rule... either way, one thing at a time. :-)
but I could not import it in wren-console for testing it.
You probably need just a bit more glue. I'll try it now.
Bump #define MAX_CLASSES_PER_MODULE
to 10
in binary_libs.h
... it's 6 now (which I'm still confused why is not sufficient)... mirror
only has 5 classes + the sentinel, which makes 6... which should work exactly... but instead for some reason it fails always.
// We have to use C functions for escaping chars
// because a bug in compiler throws error when using \ in strings
// inside Wren files.
Is this desirable? Because I'm pretty sure this is no longer true... (at least for wren-console, etc)... Wren and Wren CLI have fixed that bug in their upstreams also IIRC.
Is best that this only uses strings as IO. So it does not violate Single Responsability Principle from Solid.
I don't believe that's a violation. Every good JSON library I know has a convenience
load
andsave
method... or perhaps it is a violation AND a useful exception that proves the rule... either way, one thing at a time. :-)but I could not import it in wren-console for testing it.
You probably need just a bit more glue. I'll try it now.
I think a separate class for FileIO can be created. so Json is just strings encoding/decoding and JsonFile can be coupled with the FileSystem
Thanks, now the json module is operative
Bump
#define MAX_CLASSES_PER_MODULE
to10
inbinary_libs.h
... it's 6 now (which I'm still confused why is not sufficient)...mirror
only has 5 classes + the sentinel, which makes 6... which should work exactly... but instead for some reason it fails always.
Json module exports 8 classes at minimum (counting the aliases at the end)
var JSON = Json
var JSONOptions = JsonOptions
var JSONError = JsonError
Json module exports 8 classes at minimum (counting the aliases at the end)
True, but I thought those constants just referred to the size of the data tables... which do not include all the classes... shrugs
Json module exports 8 classes at minimum (counting the aliases at the end)
True, but I thought those constants just referred to the size of the data tables... which do not include all the classes... shrugs
Is there a reason to not use 255 as max?
Is there a reason to not use 255 as max?
Other than wasting space for no reason? I like that Wren is conservative... but I think we could probably consider doubling them all in a sep PR or some such without any real harm. I might try building in debug mode with the number lower and see if it blows up...
Since the data tables are static there is no reason they need limits at all save to make the compiler happy - all the tables are NULL terminated... so I guess these constants must be used elsewhere in the runtime as well.
Is your branch locked (on Github) so I can't push to it or is gh
just being silly? Typically I can push into PRs easily enough but I get an error.
I don´t know how to tell if GH is locked or not 🌵 first time that I heard someone needs to do something like that :octocat:
At least in the repo is not protected 👍
For some strange reason I could not see the "Allow edits from maintainers button"
I wonder if it has to do with your mixing the account camilowser
and clsource
? Only the "creator" of the PR should see that checkbox... I wonder if only one of those two own it?
I created that other account just to reserve the username. But since the email used in my cli differs from the one used in my main account, somehow made github wacky and mix them both. Maybe if I send the pr from the other account it would work. But it seems a bug in Gh
But since the email used in my cli differs from the one used in my main account, somehow made github wacky and mix them both.
That's easy to change if you'd like. :)
Related to #2
This is a sample JSON module based off the DOME one. It was stripped from the FileSystem coupling. Just encode and decode strings.
I couldn't make this work with wren-console.
Please test.
Thanks.