| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Include an example showing that the end function must be called on both
code paths (success and failure) if the reader object is to be used
afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=744100
|
| |
|
|
|
|
| |
The two are fairly different, and JsonObject does not behave this way.
https://bugzilla.gnome.org/show_bug.cgi?id=730803
|
| | |
|
| | |
|
| |
|
|
|
| |
GSimpleAsyncResult is deprecated in GLib 2.46, so we should drop its
use, and simplify the code in the process.
|
| | |
|
| | |
|
| |
|
|
|
| |
Wrap JsonParser and JsonGenerator in simple, easy to call functions that
manage the objects for you.
|
| |
|
|
| |
New development cycle, for new API.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We need to remove the path specification inside the sources listing, and
modify the enumeration type and marshallers generation rules to cope
with it (by adding the $(srcdir) when needed). This is similar to the
changes there were made to Clutter.
|
| | |
|
| |
|
|
|
| |
We can verify that the documentation is correct and up to date every
time we distcheck by turning on the gtk-doc check tool.
|
| |
|
|
|
|
|
|
| |
We need to ensure that gtk-doc looks into both the srcdir and the
builddir in order to find all annotations.
We also don't need to have the .types file under revision control:
gtk-doc is perfectly capable of rebuilding it by itself.
|
| | |
|
| | |
|
| |
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=711600
https://bugzilla.gnome.org/show_bug.cgi?id=746143
|
| | |
|
| |
|
|
|
|
| |
Rename the install projects as json-glib-install, so that it would be
easier for one to integrate the project set in a grand solution that can be
used to build the entire stack, such as for Clutter.
|
| |
|
|
|
|
| |
"Install" the .pdb files for the json-glib DLL and the tools to ease
debugging people developing or using json-glib, as the .pdb files are
already generated for all builds.
|
| |
|
|
|
| |
The empty lines in the property sheets are not really needed, so remove
them.
|
| |
|
|
|
|
|
|
|
| |
Use the multiprocessor compilation (/MP) option, which can cut down release
build times by quite a bit. This will emit a brief warning on debug
builds, but otherwise the build will proceed as normal.
Also use the /d2Zi+ option for MSVC 2010 (and later) builds so that more
useful information can be logged to the .pdb files for the release builds.
|
| |
|
|
|
|
|
|
|
| |
The json gvariant serializer encodes whole number doubles without
a dot. The deserializer needs to be able to parse these as well.
Fix problem, and add test cases.
https://bugzilla.gnome.org/show_bug.cgi?id=724319
|
| |
|
|
|
|
|
| |
Document and annotate the fact that json_builder_add_value() takes
ownership of the JsonNode passed in to it.
https://bugzilla.gnome.org/show_bug.cgi?id=743475
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the case where, with nested objects, we call:
json_reader_read_member (reader, "outer");
// json_reader_get_member_name (reader) == "outer"
json_reader_read_member (reader, "inner");
// json_reader_get_member_name (reader) == "inner"
// do something useful
json_reader_end_member (reader);
but at the end, the following assertion no longer holds:
// json_reader_get_member_name (reader) == "outer"
even though the JsonReader state should have been reset after ending the
inner node.
Fix it by maintaining a stack of member names. This works with both
json_reader_read_member() and json_reader_read_element(). Updates to the
unit tests are included.
https://bugzilla.gnome.org/show_bug.cgi?id=741824
|
| |
|
|
|
|
|
|
| |
Long and unsigned long was properly serialized but not deserialized, guint64
handling is not ideal as the type is cast into a gint64, however this is
better than not handling the fundamental type at all.
https://bugzilla.gnome.org/show_bug.cgi?id=725972
|
| |
|
|
|
| |
It's not public API anyway, and we use annotations instead of the '_'
prefix.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Expands the symbol annotation correctly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, due to the way that Visual Studio 2010+ projects are handled,
the "install" project does not re-build upon changes to the sources, as it
does not believe that its dependencies have changed, although the changed
sources are automatically recompiled. This means that if a part or more
of the solution does not build, or if the sources need some other fixes
or enhancements, the up-to-date build is not copied automatically, which
can be misleading.
Improve on the situation by forcing the "install" project to trigger its
rebuild, so that the updated binaries can be copied. This does trigger an
MSBuild warning, but having that warning is way better than not having an
up-to-date build, especially during testing and development.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Otherwise g-ir-scanner won't pick the types up, and will not notice that
the error enumerations have an associated error domain.
https://bugzilla.gnome.org/show_bug.cgi?id=730917
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=730425
|
| |
|
|
|
|
|
| |
Escaping these as octals is out of the JSON spec completely,
so roll our own string encoder.
https://bugzilla.gnome.org/show_bug.cgi?id=730425
|
| |
|
|
|
|
| |
Also fix empty keys, which are now encoded properly.
https://bugzilla.gnome.org/show_bug.cgi?id=727593
|
| | |
|
| | |
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=727755
|
| | |
|
| |
|
|
|
|
|
| |
The ByteArray we use to buffer the contents of a stream in order to
pass them to the parser may have a bigger length. We should use the
cursor position that we use to put a '\0' in the buffer instead. We
could also use -1, but this saves us a strlen() later on.
|