orange
orange copied to clipboard
jacob-carlborg
Dub support or help you with getting orange into Phobos
I'm one of the maintainers of https://github.com/BlackEdder/painlessjson. Orange is more feature complete as a general serialization library so it would be beneficial to move our efforts to orange instead. I (and I think @BlackEdder too) would want to add a JSON archive to orange, but we also want to strive for simplicity of the end users. make is OK, but not optimal, and it turns me as a user away when I'm "shopping" for a library. DSSS and orbit seem to have been overtaken by dub, so to make it easy to use orange (and thereby the JSON archive I want to add) I would want orange to either be in the standard library or in dub. Do you want me to help you with dub (it's giving me some errors currently) or could I help you with making orange ready for Phobos?
make is OK, but not optimal, and it turns me as a user away when I'm "shopping" for a library
Make is horrible. The makefile is only in the repository because I got a pull request for it. I basically doesn't use Orange myself. I've also copied Orange in to one of my other libraries mambo where it uses the Tango XML package instead. Mambo is available through Dub, but it's not really intended as a public library yet. I'm using it in some of my other projects.
I intend to get Orange into Phobos, I've already tried twice. But now it has been a while since I've prioritized Orange. Let me go back and have a look at the code I worked on to see what the status is.
Making it available through Dub should be simple. Something we could as a "quick fix" before it's added to Phobos. What errors are you seeing?
A JSON archiver would be really nice to have. I would also work as a test for the serializer and archiver interface if they're as generic as I'm hoping they are.
Great! I created a dub.json that links without the test files:
{
"name": "orange",
"description": "The serialization library for D.",
"authors": ["Jacob Carlborg"],
"homepage": "https://github.com/jacob-carlborg/orange",
"targetType": "library",
"dependencies": {
},
"sourcePaths": ["orange"],
"importPaths": ["orange"],
"buildRequirements": ["allowWarnings"]
}
Trying to add the test folder so I can run the unit tests is where I'm stuck.
Error: module tests.Object from file tests\object.d must be imported with 'import tests.Object;'
FAIL .dub\build\__test__library__-unittest-windows-x86-dmd_2068-538D5F531AB007B4534D16EA80382A55\ __test__library__ executable
The error message isn't very nice and I'm failing to find where in the source code the import is missing.
Removing module tests.Object; from the top of tests/Object.d reveals some new errors:
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(170): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(174): Error: template instance std.traits.Demangle!uint error instantiating
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(174): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(210): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(475): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(475): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(476): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(478): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(479): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(481): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(482): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(494): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(501): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(1922): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(1997): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(3279): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(3681): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(6361): Error: undefined identifier 'string'
C:\tools\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d(6361): Error: undefined identifier 'string'
About the inclusion into Phobos, this is how far I've come and the branch I've been working on serialization_struct. It's over a year old but it's quite a lot of changes.
serialization_struct and orange seem to be quite equal (that's why I approached you about getting orange into phobos). It will be easier for me to help if I don't have to use a fork of phobos so let's start by making orange usable with dub and then migrate the code to fit the phobos style. Moving the library when it gets green light should be a piece of cake then. Or would it be better to move things (I don't know what) from orange into that phobos fork?
Or would it be better to move things (I don't know what) from orange into that phobos fork?
In that fork I have moved Orange into Phobos :smiley:. It also contains some rewrites that were requested in the reviews and that I've made as well, like:
- Separate serialization and deserialization in two separate parts
- Support for ranges
- Range interface
- Use structs instead of classes
- A way to configure the serialization process. This allows both users and archiver implementors to customize the serialization process. For example, an archiver can choose not to support slices. This will make the archivers more flexible and may choose not to support a feature that doesn't make sense or will significantly impact the performance
Oh, great! So it's better to continue the work in that fork than on orange? Would you mind moving the code out to its own repository? Doing so would avoid being 4k commits behind phobos. I guess it would make the setup for those that want to help simpler as well.
So it's better to continue the work in that fork than on orange?
Yeah, I think so.
Would you mind moving the code out to its own repository? Doing so would avoid being 4k commits behind phobos. I guess it would make the setup for those that want to help simpler as well.
The whole point was to move it into Phobos :wink:. If I move it out, it needs to be moved back at some point. Any conflicts that one would get now if updating to latest Phobos would be need to solved later anyway. So I don't see the point.
On the other hand. Most people will require a Dub package when this comes up for review again. I'll see what I can do.
My idea is that all work would target the latest phobos, but the commit log would be a little cleaner since there would be no "merged origin/master into master" commits. The layout of the source could still be to have it in the std folder so conflicts would be seen. I guess the approach doesn't work if we need to modify any existing files though. My main concern is ease of development and collaboration. Forks can't have issues of their own so we would need another way to communicate if it stays in a fork.
My idea is that all work would target the latest phobos, but the commit log would be a little cleaner since there would be no "merged origin/master into master" commits
Not sure what the issue is with the commit log. We can just squash the commits as we see fit when it's ready for inclusion.
I guess the approach doesn't work if we need to modify any existing files though
No, that might be a problem.
My main concern is ease of development and collaboration. Forks can't have issues of their own so we would need another way to communicate if it stays in a fork.
They can :smiley: https://github.com/jacob-carlborg/phobos/issues
They can :smiley: https://github.com/jacob-carlborg/phobos/issues
Oh great! Had no idea they added that to the settings.
Then I guess I see no problems keeping it in your fork. Using rdmd it will be possible to run just the tests we care about as well. I'll see if it compiles for me and will open issues over there if it don't. After that I'll get started on implementing the interface for a JSON archive.
After that I'll get started on implementing the interface for a JSON archive.
@Zalastax did you ever get to this?
No. Sorry for not updating the issue. I had problems with getting it all running and little time for D development. No significant progress was made.
CC @lodo1995 - maybe you can help to push the efforts here (creating a unified serialization framework)?
BTW, Orange is now available on Dub: http://code.dlang.org/packages/orange
@wilzbach Having a unified serialization framework is not in my agenda. Writing the XML library is taking up all my time. I could maybe spend some time on this starting from late September, if the broader community is really interested in having this thing. If that's the case, I would really love to collaborate with anyone interested (you, @jacob-carlborg or anyone else).
@wilzbach Having a unified serialization framework is not in my agenda. Writing the XML library is taking up all my time.
Oh I just wanted you to make aware of this discussion ;-)
I could maybe spend some time on this starting from late September, if the broader community is really interested in having this thing. If that's the case, I would really love to collaborate with anyone interested (you, @jacob-carlborg or anyone else).
There's also @s-ludwig's proposed std.data.json.
There's also s-ludwig's proposed std.data.json
@wilzbach not sure of how a much of a serialization library std.data.json is. At least it doesn't support multiple backends like Orange does.
If that's the case, I would really love to collaborate with anyone interested (you, jacob-carlborg or anyone else).
I absolutely interested. Unfortunately this has pretty low priority for me right now. I can absolutely take part in any discussions but not so much coding.