Switch from XML to S-Expressions file format #193

ubruhin · 2017-10-22T13:04:43Z

Example files:

Fixes #192

dbrgn · 2017-10-22T13:19:50Z

Shouldn't dates be quoted? E.g. see here

dbrgn · 2017-10-22T13:28:17Z

Some other remarks:

(name (locale "") "R-US")
(description (locale "") "Resistor American (IEEE 315)")
(keywords (locale "") "resistor,resistance")

I don't quite get that. Shouldn't that be (keywords "" "resistor,resistance")? Or if you want to make the locale optional, (keywords "resistor,resistance")?

I also wonder whether in some cases more newlines would be better:

(signal 6d776f4d-2a7c-4128-a98a-dbb1dd861411 (name "2") (role passive)
  (required true) (negated false) (clock false) (forced_net "")
)

Maybe this would be better like this:

(signal 6d776f4d-2a7c-4128-a98a-dbb1dd861411
  (name "2")
  (role passive)
  (required true)
  (negated false)
  (clock false)
  (forced_net "")
)

It would also help when doing diffs.

Regarding this one:

(disp none)

none is an enum variant, not null, right?

What about flags?

(signal 1c1c7abc-7b40-4f92-b533-f65604644db7 (name "1") (role passive)
  (required true) (negated false) (clock false) (forced_net "")
)

Maybe required could become a flag?

(signal 1c1c7abc-7b40-4f92-b533-f65604644db7 required (name "1") (role passive)
  (negated false) (clock false) (forced_net "")
)

On the other hand it might make the format less generic and harder to parse.

And a general comment, I'd use two spaces for indentation, one is a bit hard to see when dealing with larger structures.

ubruhin · 2017-10-22T13:29:32Z

Shouldn't dates be quoted?

I saw no reason to quote them because the format of dates is well known (contains only letters, digits, :, - and +) and thus is always a valid S-Expression token.

ubruhin · 2017-10-22T14:02:36Z

I don't quite get that. Shouldn't that be (keywords "" "resistor,resistance")? Or if you want to make the locale optional, (keywords "resistor,resistance")?

I expected that question 😃 I already spent some time to improve the format of localized strings (name, description, keywords), but unfortunately I didn't found a good solution.

Actually the main question is: How should the localizing of these attributes work? My current idea is that for each library element there are fields for "name", "description" and "keywords" without a specific locale. So if you create libraries only for yourself, you can for example fill these fields with German words. In addition, translated strings can optionally be added, e.g. for your libraries someone could add English translations.

For that system, the most reasonable file format would probably look like this:

(name "Hallo Welt")
(name (locale "en_US") "Hello World")

But this is really ugly to parse, because the text is not always at the same index of the node (index 0 without locale, index 1 with locale). Of course it would be possible to either take the count of child nodes, or the type of each child node into account, but it feels like a workaround to do that.

If the order of the child nodes is swapped, parsing gets easier, but IMO the file looks less intuitive:

(name "Hallo Welt")
(name "Hello World" (locale "en_US"))

Another solution is to always write down the locale, but without an extra child node, but this also looks strange:

(name "" "Hallo Welt")
(name "en_US" "Hello World")

Maybe it would make sense to make the locale mandatory, so every string has a locale defined?

(name (locale de_CH) "Hallo Welt")
(name (locale en_US) "Hello World")

But this would bring up a new question: Which locale should be used if the user's locale is not found? So if you have set your default locale to "cs_CZ", which of the two available locales "de_CH" and "en_US" should be displayed? When having default/fallback name/description/keywords, these will be used in such cases.

Do you have a good answer for these questions? :)

I also wonder whether in some cases more newlines would be better:
It would also help when doing diffs

It helps doing diffs on short files. But when adding more newlines, many files get much longer (e.g. >1000 lines), which is also not nice. I think creating nice looking files is a trade-off between length of lines and count of lines.

And a general comment, I'd use two spaces for indentation

Of course this would improve readability, but here I also see a trade-off between file size and readability. Optimal for file size would be zero indentation (and even no newlines), optimal for readability ~2-4 spaces. So for me, 1 space seems to be a good compromise (keep in mind that you will probably never write such files by hand, and even reading such files should not be daily business).

none is an enum variant, not null, right?

Right.

What about flags?

Looks interesting, need to think about it... ;)

EDIT: Thought about it ~10seconds 😄 and my answer is: It makes files less self-documented. If a flag is missing, it's not visible that there could be such a flag. A boolean value (e.g. (required false)) is much more expressive and also easier to parse.

ubruhin · 2017-10-24T21:07:00Z

Ok now I updated the format of localized strings by making the "locale" node optional:

(name "Hallo Welt")
(name (locale "en_US") "Hello World")

IMO the files look much better this way, but of course parsing feels a bit crappy now...

What do you think @dbrgn?

Btw, the links from the first post above always point to the latest file format, just check out these files again to see the difference.

dbrgn · 2017-10-25T07:18:55Z

Don't you initially parse the S-Expression into a generic nested key-value tree? In that case parsing would not make a difference.

In general I like the approach with the optional locale node.

ubruhin · 2017-10-25T17:45:47Z

Don't you initially parse the S-Expression into a generic nested key-value tree?

Yes, I do.

In that case parsing would not make a difference.

"Low-level" parsing does not make a difference, but serializing and deserializing of objects is a bit ugly. See 3717032, this is the change needed to make the "locale" node optional.

dbrgn · 2017-10-25T18:53:50Z

libs/librepcb/common/fileio/sexpression.cpp

+    }
+}
+
+QList<SExpression> SExpression::getChilds(const QString& name) const noexcept


Shouldn't that be getChildren?

Oh, the plural form is not always the singular form with an 's' appended 😭 😄

Welcome to the brave world of stemming and pluralization 😆

dbrgn · 2017-10-25T18:55:43Z

this is the change needed to make the "locale" node optional

That isn't too bad though :)

ubruhin · 2017-10-27T22:59:52Z

I think this should be ready now! ✨

I have even added the new mime type application/x-librepcb-file and a language specification to enable syntax highlighting of *.lp files in GtkSourceView based editors.

@dbrgn @rnestler Someone interested in providing a syntax highlighting config for Vim? Or does Vim also support the GtkSourceView language specs?

All serialization core classes are changed to work with S-Expressions instead of XML. All other classes will follow soon.

Affected classes: - librepcb::Angle - librepcb::Length - librepcb::Ratio

This can be used to enable syntax highlighting for *.lp files in some text editors (e.g. Gedit on Ubuntu). Just execute the shell script to install the language specs.

Convert all XML files to S-Expressions

ubruhin added this to the 0.1 milestone Oct 22, 2017

ubruhin self-assigned this Oct 22, 2017

Add submodule "libs/sexpresso"

b3610b1

ubruhin force-pushed the switch_from_xml_to_sexpr branch from 377e094 to 0379c4e Compare October 24, 2017 21:00

dbrgn reviewed Oct 25, 2017

View reviewed changes

Add new common class SExpression

486f33c

ubruhin force-pushed the switch_from_xml_to_sexpr branch from 0379c4e to ff879eb Compare October 27, 2017 22:50

ubruhin changed the title ~~WIP: Switch from XML to S-Expressions file format~~ Switch from XML to S-Expressions file format Oct 27, 2017

ubruhin added 11 commits October 29, 2017 00:43

Switch core classes from XML to S-Expressions

3de6686

All serialization core classes are changed to work with S-Expressions instead of XML. All other classes will follow soon.

Switch remaining classes from XML to S-Expressions

2dd9d8b

Implement SerializableObject for Alignment class

b9cf72f

Implement SerializableObject for Point class

63f8c16

Workspace: Use S-Expressions for recent/favorite projects files

fc72153

Remove trailing zeros of numbers in all files

b22b979

Affected classes: - librepcb::Angle - librepcb::Length - librepcb::Ratio

BoardUserSettings: Ignore errors when loading from file

43733e8

Register new mimetype "application/x-librepcb-file"

9d160a7

Add "gtksourceview-3.0" language spec for *.lpp files

4a75934

This can be used to enable syntax highlighting for *.lp files in some text editors (e.g. Gedit on Ubuntu). Just execute the shell script to install the language specs.

Update Doxygen documentation to new file format

fdad7a0

Update submodule "demo-workspace"

8dea953

Convert all XML files to S-Expressions

ubruhin force-pushed the switch_from_xml_to_sexpr branch from ff879eb to 8dea953 Compare October 28, 2017 23:06

ubruhin mentioned this pull request Oct 29, 2017

Add blog post: LibrePCB has switched to S-Expressions LibrePCB/librepcb-website#11

Merged

ubruhin merged commit fb70549 into master Oct 30, 2017

ubruhin deleted the switch_from_xml_to_sexpr branch October 30, 2017 21:06

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Switch from XML to S-Expressions file format #193

Switch from XML to S-Expressions file format #193

ubruhin commented Oct 22, 2017

dbrgn commented Oct 22, 2017

dbrgn commented Oct 22, 2017

ubruhin commented Oct 22, 2017

ubruhin commented Oct 22, 2017 •

edited

Loading

ubruhin commented Oct 24, 2017

dbrgn commented Oct 25, 2017

ubruhin commented Oct 25, 2017 •

edited

Loading

dbrgn Oct 25, 2017

ubruhin Oct 25, 2017

dbrgn Oct 25, 2017

dbrgn commented Oct 25, 2017

ubruhin commented Oct 27, 2017

Switch from XML to S-Expressions file format #193

Switch from XML to S-Expressions file format #193

Conversation

ubruhin commented Oct 22, 2017

dbrgn commented Oct 22, 2017

dbrgn commented Oct 22, 2017

ubruhin commented Oct 22, 2017

ubruhin commented Oct 22, 2017 • edited Loading

ubruhin commented Oct 24, 2017

dbrgn commented Oct 25, 2017

ubruhin commented Oct 25, 2017 • edited Loading

dbrgn Oct 25, 2017

Choose a reason for hiding this comment

ubruhin Oct 25, 2017

Choose a reason for hiding this comment

dbrgn Oct 25, 2017

Choose a reason for hiding this comment

dbrgn commented Oct 25, 2017

ubruhin commented Oct 27, 2017

ubruhin commented Oct 22, 2017 •

edited

Loading

ubruhin commented Oct 25, 2017 •

edited

Loading