You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(101) |
Jun
(157) |
Jul
(89) |
Aug
(135) |
Sep
(17) |
Oct
(86) |
Nov
(410) |
Dec
(311) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(76) |
Feb
(100) |
Mar
(139) |
Apr
(138) |
May
(234) |
Jun
(178) |
Jul
(271) |
Aug
(286) |
Sep
(816) |
Oct
(50) |
Nov
(28) |
Dec
(137) |
2003 |
Jan
(62) |
Feb
(25) |
Mar
(97) |
Apr
(34) |
May
(35) |
Jun
(32) |
Jul
(32) |
Aug
(57) |
Sep
(67) |
Oct
(176) |
Nov
(36) |
Dec
(37) |
2004 |
Jan
(20) |
Feb
(93) |
Mar
(16) |
Apr
(36) |
May
(59) |
Jun
(48) |
Jul
(20) |
Aug
(154) |
Sep
(868) |
Oct
(41) |
Nov
(63) |
Dec
(60) |
2005 |
Jan
(59) |
Feb
(15) |
Mar
(16) |
Apr
(14) |
May
(19) |
Jun
(16) |
Jul
(25) |
Aug
(19) |
Sep
(7) |
Oct
(12) |
Nov
(18) |
Dec
(41) |
2006 |
Jan
(16) |
Feb
(65) |
Mar
(51) |
Apr
(75) |
May
(38) |
Jun
(25) |
Jul
(23) |
Aug
(16) |
Sep
(24) |
Oct
(3) |
Nov
(1) |
Dec
(10) |
2007 |
Jan
(4) |
Feb
(5) |
Mar
(7) |
Apr
(29) |
May
(38) |
Jun
(3) |
Jul
(1) |
Aug
(17) |
Sep
(1) |
Oct
|
Nov
(11) |
Dec
(16) |
2008 |
Jan
(11) |
Feb
(4) |
Mar
(7) |
Apr
(48) |
May
(17) |
Jun
(9) |
Jul
(6) |
Aug
(12) |
Sep
(5) |
Oct
(7) |
Nov
(4) |
Dec
(11) |
2009 |
Jan
(15) |
Feb
(28) |
Mar
(12) |
Apr
(44) |
May
(6) |
Jun
(16) |
Jul
(6) |
Aug
(37) |
Sep
(107) |
Oct
(24) |
Nov
(30) |
Dec
(22) |
2010 |
Jan
(8) |
Feb
(16) |
Mar
(11) |
Apr
(28) |
May
(9) |
Jun
(26) |
Jul
(7) |
Aug
(25) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(5) |
Feb
(6) |
Mar
(3) |
Apr
(2) |
May
(10) |
Jun
(44) |
Jul
(11) |
Aug
(8) |
Sep
(6) |
Oct
(42) |
Nov
(19) |
Dec
(5) |
2012 |
Jan
(23) |
Feb
(8) |
Mar
(9) |
Apr
(11) |
May
(2) |
Jun
(11) |
Jul
|
Aug
(18) |
Sep
(1) |
Oct
(15) |
Nov
(14) |
Dec
(8) |
2013 |
Jan
(5) |
Feb
(13) |
Mar
(2) |
Apr
(10) |
May
|
Jun
(6) |
Jul
(17) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(11) |
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
(10) |
Apr
(12) |
May
(1) |
Jun
(9) |
Jul
(27) |
Aug
(5) |
Sep
(13) |
Oct
(9) |
Nov
(9) |
Dec
|
2015 |
Jan
(8) |
Feb
(5) |
Mar
(1) |
Apr
(10) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(14) |
Nov
(1) |
Dec
(6) |
2016 |
Jan
(12) |
Feb
(12) |
Mar
(133) |
Apr
(7) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(3) |
Nov
(5) |
Dec
|
2017 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(8) |
Jul
(2) |
Aug
(2) |
Sep
(8) |
Oct
(2) |
Nov
(8) |
Dec
(1) |
2018 |
Jan
(1) |
Feb
(2) |
Mar
(6) |
Apr
|
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
(2) |
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(1) |
Dec
(2) |
2020 |
Jan
(5) |
Feb
|
Mar
(2) |
Apr
(6) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
(5) |
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
|
Aug
(5) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
(4) |
2022 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(1) |
2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ingy d. N. <in...@in...> - 2019-03-13 17:02:44
|
======================= Announcing PyYAML-5.1 ======================= A new MAJOR RELEASE of PyYAML is now available: https://pypi.org/project/PyYAML/ This is the first major release of PyYAML under the new maintenance team. Among the many changes listed below, this release specifically addresses the arbitrary code execution issue raised by: https://nvd.nist.gov/vuln/detail/CVE-2017-18342 <https://nvd.nist.gov/vuln/detail/CVE-2017-18342> (See https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation for complete details). The PyYAML project is now maintained by the YAML and Python communities. Planning happens on the #yaml-dev, #pyyaml and #libyaml IRC channels on irc.freenode.net. Changes ======= * https://github.com/yaml/pyyaml/pull/35 -- Some modernization of the test running * https://github.com/yaml/pyyaml/pull/42 -- Install tox in a virtualenv * https://github.com/yaml/pyyaml/pull/45 -- Allow colon in a plain scalar in a flow context * https://github.com/yaml/pyyaml/pull/48 -- Fix typos * https://github.com/yaml/pyyaml/pull/55 -- Improve RepresenterError creation * https://github.com/yaml/pyyaml/pull/59 -- Resolves #57, update readme issues link * https://github.com/yaml/pyyaml/pull/60 -- Document and test Python 3.6 support * https://github.com/yaml/pyyaml/pull/61 -- Use Travis CI built in pip cache support * https://github.com/yaml/pyyaml/pull/62 -- Remove tox workaround for Travis CI * https://github.com/yaml/pyyaml/pull/63 -- Adding support to Unicode characters over codepoint 0xffff * https://github.com/yaml/pyyaml/pull/65 -- Support unicode literals over codepoint 0xffff * https://github.com/yaml/pyyaml/pull/75 -- add 3.12 changelog * https://github.com/yaml/pyyaml/pull/76 -- Fallback to Pure Python if Compilation fails * https://github.com/yaml/pyyaml/pull/84 -- Drop unsupported Python 3.3 * https://github.com/yaml/pyyaml/pull/102 -- Include license file in the generated wheel package * https://github.com/yaml/pyyaml/pull/105 -- Removed Python 2.6 & 3.3 support * https://github.com/yaml/pyyaml/pull/111 -- Remove commented out Psyco code * https://github.com/yaml/pyyaml/pull/129 -- Remove call to `ord` in lib3 emitter code * https://github.com/yaml/pyyaml/pull/143 -- Allow to turn off sorting keys in Dumper * https://github.com/yaml/pyyaml/pull/149 -- Test on Python 3.7-dev * https://github.com/yaml/pyyaml/pull/158 -- Support escaped slash in double quotes "\/" * https://github.com/yaml/pyyaml/pull/181 -- Import Hashable from collections.abc * https://github.com/yaml/pyyaml/pull/256 -- Make default_flow_style=False * https://github.com/yaml/pyyaml/pull/257 -- Deprecate yaml.load and add FullLoader and UnsafeLoader classes * https://github.com/yaml/pyyaml/pull/263 -- Windows Appveyor build Resources ========= PyYAML IRC Channel: #pyyaml on irc.freenode.net PyYAML homepage: https://github.com/yaml/pyyaml PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation Source and binary installers: https://pypi.org/project/PyYAML/ GitHub repository: https://github.com/yaml/pyyaml/ Bug tracking: https://github.com/yaml/pyyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About PyYAML ============ YAML is a data serialization format designed for human readability and interaction with scripting languages. PyYAML is a YAML parser and emitter for Python. PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support, capable extension API, and sensible error messages. PyYAML supports standard YAML tags and provides Python-specific tags that allow to represent an arbitrary Python object. PyYAML is applicable for a broad range of tasks from complex configuration files to object serialization and persistence. Example ======= >>> import yaml >>> yaml.full_load(""" ... name: PyYAML ... description: YAML parser and emitter for Python ... homepage: https://github.com/yaml/pyyaml ... keywords: [YAML, serialization, configuration, persistence, pickle] ... """) {'keywords': ['YAML', 'serialization', 'configuration', 'persistence', 'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description': 'YAML parser and emitter for Python', 'name': 'PyYAML'} >>> print(yaml.dump(_)) name: PyYAML homepage: https://github.com/yaml/pyyaml description: YAML parser and emitter for Python keywords: [YAML, serialization, configuration, persistence, pickle] Maintainers =========== The following people are currently responsible for maintaining PyYAML: * Ingy döt Net * Tina Mueller * Matt Davis and many thanks to all who have contribributed! See: https://github.com/yaml/pyyaml/pulls Copyright ========= Copyright (c) 2017-2019 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The PyYAML module was written by Kirill Simonov <xi...@re...>. It is currently maintained by the YAML and Python communities. PyYAML is released under the MIT license. See the file LICENSE for more details. |
From: Ferger, M. <Max...@de...> - 2019-02-28 13:10:59
|
Hi! Reading https://yaml.org/spec/1.2/spec.html (3rd Edition, Patched at 2009-10-01), I stumbled across some minor typos: - Status of this Document: -- Please report errors in this document to the [yaml-core](https://yaml.org/spec/1.2/spec.html) mailing list. ++ Please report errors in this document to the [yaml-core](http://lists.sourceforge.net/lists/listinfo/yaml-core) mailing list. - 6.8.2.2 Tag Prefixes / Global Tag Prefix: -- it must to be a valid URI prefix ++ it must also be a valid URI prefix -- In particular, every documents in ++ In particular, every document in Thanks for the good work! Max FERGER Dipl.-Ing. Elektrotechnik und Informationstechnik Functional Safety Engineer (TÜV Rheinland) -- DEUTA-Werke GmbH Paffrather Str. 140 51465 Bergisch Gladbach Germany +49 2202 958 103 max...@de... www.deuta.de www.icontrust.com Registergericht Köln HRB 67107, Geschäftsführer: Thomas Blau, Dr. Rudolf Ganz --------------------------------------------------------------------------------------------------------------------------- Diese e-mail ist von rein informativem Charakter und beinhaltet keinerlei vertragliche Bindung seitens der DEUTA Werke GmbH solange sie nicht durch eine schriftliche und im Auftrag von Deuta gezeichnete Mitteilung bestätigt wird. --------------------------------------------------------------------------------------------------------------------------- Nothing in this e-mail may be construed as amounting to a contractual or other legal commitment on the part of DEUTA Werke GmbH unless confirmed by a letter, signed on behalf of the company. --------------------------------------------------------------------------------------------------------------------------- |
From: Ingy d. N. <in...@in...> - 2019-02-25 05:46:27
|
======================= Announcing PyYAML-5.1b1 (First beta release) ======================= The first beta release of PyYAML-5.1 has been uploaded to pypi.org. The final release is expected to land in the next 2 weeks. Normally we would only announce the final release, but this one has been a long time coming and has major changes, so we want people to know about the release process early on. A new MAJOR RELEASE of PyYAML is now available: https://pypi.org/project/PyYAML/ This is the first major release of PyYAML under the new maintenance team. Among the many changes listed below, this release specifically addresses the arbitrary code execution issue raised by: https://nvd.nist.gov/vuln/detail/CVE-2017-18342 (See https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation for complete details). The PyYAML project is now maintained by the YAML and Python communities. Planning happens on the #yaml-dev, #pyyaml and #libyaml IRC channels on irc.freenode.net. Changes ======= * https://github.com/yaml/pyyaml/pull/35 -- Some modernization of the test running * https://github.com/yaml/pyyaml/pull/42 -- Install tox in a virtualenv * https://github.com/yaml/pyyaml/pull/45 -- Allow colon in a plain scalar in a flow context * https://github.com/yaml/pyyaml/pull/48 -- Fix typos * https://github.com/yaml/pyyaml/pull/55 -- Improve RepresenterError creation * https://github.com/yaml/pyyaml/pull/59 -- Resolves #57, update readme issues link * https://github.com/yaml/pyyaml/pull/60 -- Document and test Python 3.6 support * https://github.com/yaml/pyyaml/pull/61 -- Use Travis CI built in pip cache support * https://github.com/yaml/pyyaml/pull/62 -- Remove tox workaround for Travis CI * https://github.com/yaml/pyyaml/pull/63 -- Adding support to Unicode characters over codepoint 0xffff * https://github.com/yaml/pyyaml/pull/65 -- Support unicode literals over codepoint 0xffff * https://github.com/yaml/pyyaml/pull/75 -- add 3.12 changelog * https://github.com/yaml/pyyaml/pull/76 -- Fallback to Pure Python if Compilation fails * https://github.com/yaml/pyyaml/pull/84 -- Drop unsupported Python 3.3 * https://github.com/yaml/pyyaml/pull/102 -- Include license file in the generated wheel package * https://github.com/yaml/pyyaml/pull/105 -- Removed Python 2.6 & 3.3 support * https://github.com/yaml/pyyaml/pull/111 -- Remove commented out Psyco code * https://github.com/yaml/pyyaml/pull/129 -- Remove call to `ord` in lib3 emitter code * https://github.com/yaml/pyyaml/pull/143 -- Allow to turn off sorting keys in Dumper * https://github.com/yaml/pyyaml/pull/149 -- Test on Python 3.7-dev * https://github.com/yaml/pyyaml/pull/158 -- Support escaped slash in double quotes "\/" * https://github.com/yaml/pyyaml/pull/256 -- Make default_flow_style=False * https://github.com/yaml/pyyaml/pull/257 -- Deprecate yaml.load and add FullLoader and UnsafeLoader classes Resources ========= PyYAML IRC Channel: #pyyaml on irc.freenode.net PyYAML homepage: https://github.com/yaml/pyyaml PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation Source and binary installers: https://pypi.org/project/PyYAML/ GitHub repository: https://github.com/yaml/pyyaml/ Bug tracking: https://github.com/yaml/pyyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About PyYAML ============ YAML is a data serialization format designed for human readability and interaction with scripting languages. PyYAML is a YAML parser and emitter for Python. PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support, capable extension API, and sensible error messages. PyYAML supports standard YAML tags and provides Python-specific tags that allow to represent an arbitrary Python object. PyYAML is applicable for a broad range of tasks from complex configuration files to object serialization and persistence. Example ======= >>> import yaml >>> yaml.load(""" ... name: PyYAML ... description: YAML parser and emitter for Python ... homepage: https://github.com/yaml/pyyaml ... keywords: [YAML, serialization, configuration, persistence, pickle] ... """) {'keywords': ['YAML', 'serialization', 'configuration', 'persistence', 'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description': 'YAML parser and emitter for Python', 'name': 'PyYAML'} >>> print yaml.dump(_) name: PyYAML homepage: https://github.com/yaml/pyyaml description: YAML parser and emitter for Python keywords: [YAML, serialization, configuration, persistence, pickle] Maintainers =========== The following people are currently responsible for maintaining PyYAML: * Ingy döt Net * Tina Mueller * Matt Davis and many thanks to all who have contribributed! See: https://github.com/yaml/pyyaml/pulls Copyright ========= Copyright (c) 2017-2019 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The PyYAML module was written by Kirill Simonov <xi...@re...>. It is currently maintained by the YAML and Python communities. PyYAML is released under the MIT license. See the file LICENSE for more details. |
From: Agnes M. <agn...@gm...> - 2019-01-21 09:27:23
|
From: Agnes M. <agn...@gm...> - 2019-01-21 09:06:34
|
From: Tina M. <po...@ti...> - 2018-09-21 20:56:36
|
Hi Eemeli, thanks for writing this library, and congratulations on that =) Also good to know that there is yet another project using the YAML Test Suite <https://github.com/yaml/yaml-test-suite>. Thanks to Ingy for starting that. cheers, tina On Thu, 20 Sep 2018, Eemeli Aro wrote: > Hi all! > > Given that it's getting to be (apparently!) bug-free, and now that > it's included in the matrix [1], I figured that it was time to release > my JavaScript yaml library's 1.0.0 version on npm [2]. There's an > extensive documentation site [3] with technical info and a blog post > [4] with some of the less-technical story behind the project, but the > key features are: > > * Supports all versions of the standard (1.0, 1.1, and 1.2) > * Passes all(*) of the yaml-test-suite tests > * Can accept any string as input without throwing, parsing as much > YAML out of it as it can > * Supports parsing, modifying, and writing YAML comments > * Released with and ISC open source license > > I would warmly welcome any and all comments and criticism on my little project. > > Eemeli Aro > > [1] http://matrix.yaml.io/ > [2] https://www.npmjs.com/package/yaml > [3] https://eemeli.org/yaml > [4] https://www.vincit.fi/blog/fixing-yaml-for-fun/ > > (*) The two reported errors are due to this PR not being merged yet: > https://github.com/yaml/yaml-test-suite/pull/40 > > > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > |
From: Eemeli A. <ee...@gm...> - 2018-09-20 10:46:02
|
Hi all! Given that it's getting to be (apparently!) bug-free, and now that it's included in the matrix [1], I figured that it was time to release my JavaScript yaml library's 1.0.0 version on npm [2]. There's an extensive documentation site [3] with technical info and a blog post [4] with some of the less-technical story behind the project, but the key features are: * Supports all versions of the standard (1.0, 1.1, and 1.2) * Passes all(*) of the yaml-test-suite tests * Can accept any string as input without throwing, parsing as much YAML out of it as it can * Supports parsing, modifying, and writing YAML comments * Released with and ISC open source license I would warmly welcome any and all comments and criticism on my little project. Eemeli Aro [1] http://matrix.yaml.io/ [2] https://www.npmjs.com/package/yaml [3] https://eemeli.org/yaml [4] https://www.vincit.fi/blog/fixing-yaml-for-fun/ (*) The two reported errors are due to this PR not being merged yet: https://github.com/yaml/yaml-test-suite/pull/40 |
From: Ingy d. N. <in...@in...> - 2018-07-05 22:27:49
|
======================== Announcing PyYAML-3.13 ======================== A new bug fix release of PyYAML is now available: http://pyyaml.org/wiki/PyYAML *** Important Note From Maintainers *** This is the first PyYAML release by the new maintainers. It was made critical because PyYAML-3.12 did not work with the recent Python 3.7 release. A more ambitious 4.1 release was attempted last week and needed to be retracted for many reasons. We apologize any pain caused by the 4.1 removal, but we remain confident that it was the best decision. There are over 60 pull requests in PyYAML and LibYAML that will be represented in the upcoming 4.2 release and we are working hard to get those to you as soon as the release is ready (but no sooner :). We are are excited that the PyYAML project is moving forward again. -- The PyYAML Maintenance Team Changes ======= * Rebuilt with the latest Cython to support the new Python 3.7 release. * No functionality is different from PyYAML 3.12 in this release. Resources ========= PyYAML IRC Channel: #pyyaml on irc.freenode.net YAML IRC Channel: #yaml-dev on irc.freenode.net LibYAML IRC Channel: #libyaml on irc.freenode.net PyYAML homepage: http://pyyaml.org/wiki/PyYAML PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation Source and binary installers: https://pypi.python.org/pypi/PyYAML/3.13 GitHub repository: https://github.com/yaml/pyyaml/ Bug tracking: https://github.com/yaml/pyyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About PyYAML ============ YAML is a data serialization format designed for human readability and interaction with scripting languages. PyYAML is a YAML parser and emitter for Python. PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support, capable extension API, and sensible error messages. PyYAML supports standard YAML tags and provides Python-specific tags that allow to represent an arbitrary Python object. PyYAML is applicable for a broad range of tasks from complex configuration files to object serialization and persistance. Example ======= >>> import yaml >>> yaml.load(""" ... name: PyYAML ... description: YAML parser and emitter for Python ... homepage: http://pyyaml.org/wiki/PyYAML ... keywords: [YAML, serialization, configuration, persistance, pickle] ... """) {'keywords': ['YAML', 'serialization', 'configuration', 'persistance', 'pickle'], 'homepage': 'http://pyyaml.org/wiki/PyYAML', 'description': 'YAML parser and emitter for Python', 'name': 'PyYAML'} >>> print yaml.dump(_) name: PyYAML homepage: http://pyyaml.org/wiki/PyYAML description: YAML parser and emitter for Python keywords: [YAML, serialization, configuration, persistance, pickle] Maintainers =========== The following people are currently responsible for maintaining PyYAML: * Ingy döt Net * Tina Mueller * Matt Davis and many thanks to all who have contribributed! See: https://github.com/yaml/pyyaml/pulls Copyright ========= Copyright (c) 2017-2018 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The PyYAML module was written by Kirill Simonov <xi...@re...>. It is currently maintained by the YAML and Python communities. PyYAML is released under the MIT license. See the file LICENSE for more details. |
From: Ingy d. N. <in...@in...> - 2018-06-28 21:50:28
|
I am sorry to report that the PyYAML-4.1 release from 48 hours ago has been removed from PyPI There were too many problems to make this a viable release. The biggest known issue with this retraction is that PyYAML will not work with the new Python 3.7 until PyYAML-4.2 is released. https://github.com/yaml/pyyaml/issues/126#issuecomment-401175258 We are starting work immediately on 4.2b1 prerelease series. I hope to see 4.2 released in the next few days. Work is being coordinated on #pyyaml on irc.freenode.net and issues can be reported and followed at https://github.com/yaml/pyyaml Thank you for your patience. |
From: Zenaan H. <ze...@fr...> - 2018-06-27 00:39:07
|
On Mon, Mar 05, 2018 at 05:06:32PM +0100, Tina Müller wrote: > On Mon, 5 Mar 2018, Andrey Somov wrote: > > > P.S. It is sad that communication happens in a place which is not indexed > > by search engines and it is available to a a handful participants only... > > Our plan is to invite a logging bot to the channel, so that the log > is available for everyone. > > Ingy, any progress on that? Perhaps a <time period> post of said log to this list? That would make it easy for some to batch-read for a catch up… |
From: Ingy d. N. <in...@in...> - 2018-06-26 22:50:19
|
========================= Announcing LibYAML-0.2.1 ========================= A new MAJOR RELEASE of LibYAML is now available: https://github.com/yaml/libyaml/tree/0.2.1 This is the first release of LibYAML under a new maintenance team. In August 2016, maintenance of LibYAML and PyYAML was turned over from the original author, Kirill Simonov, to Ian Cordasco and Ingy döt Net. The canonical source repo moved: from: https://bitbucket.org/xi/libyaml/ to: https://github.com/yaml/libyaml The LibYAML project is now maintained by the YAML community. Planning happens on the #yaml-dev and #libyaml IRC channels on irc.freenode.net. Changes ======= * https://github.com/yaml/libyaml/pull/7 -- Fixed most compiler warnings -Wall -Wextra * https://github.com/yaml/libyaml/pull/10 -- Support static and dynamic libraries * https://github.com/yaml/libyaml/pull/12 -- Use .gitignore instead of .hgignore * https://github.com/yaml/libyaml/pull/13 -- Add support for `make test` and travis * https://github.com/yaml/libyaml/pull/14 -- Dockerfile for testing * https://github.com/yaml/libyaml/pull/15 -- Apply old fix for `\/` that is not in master. * https://github.com/yaml/libyaml/pull/17 -- Update license to include all years until now. * https://github.com/yaml/libyaml/pull/18 -- Port bug fix from Perl binding * https://github.com/yaml/libyaml/pull/22 -- Fix misspell: preceed * https://github.com/yaml/libyaml/pull/23 -- Removed trailing-whitespaces * https://github.com/yaml/libyaml/pull/24 -- Fix typo * https://github.com/yaml/libyaml/pull/25 -- added an examples directory with a few yaml examples * https://github.com/yaml/libyaml/pull/26 -- Added missing Cflags path in pkg-config file * https://github.com/yaml/libyaml/pull/31 -- add unit tests to cmake configuration * https://github.com/yaml/libyaml/pull/32 -- Include an example of a custom tag from Python * https://github.com/yaml/libyaml/pull/33 -- Include an example of a %YAML tag * https://github.com/yaml/libyaml/pull/34 -- Added an example of using a global tag * https://github.com/yaml/libyaml/pull/36 -- Fix -Wformat compilation errors in tests * https://github.com/yaml/libyaml/pull/37 -- Update bug report URL in LibYAML * https://github.com/yaml/libyaml/pull/38 -- Use AM_CPPFLAGS since autotools deprecated INCLUDE * https://github.com/yaml/libyaml/pull/39 -- Update bug report URL in README * https://github.com/yaml/libyaml/pull/41 -- Add travis and Makefile support for libyaml-test * https://github.com/yaml/libyaml/pull/43 -- Add Dockerfile for Fedora 25 * https://github.com/yaml/libyaml/pull/44 -- WIP: Enable all warnings (-Wall) in libyaml and tests * https://github.com/yaml/libyaml/pull/45 -- Fix typo * https://github.com/yaml/libyaml/pull/47 -- Move travis script guts to separate file * https://github.com/yaml/libyaml/pull/48 -- `yaml/libyaml-test` should become part of `yaml/libyaml` * https://github.com/yaml/libyaml/pull/50 -- Add a GNUMakefile for immediate make targets * https://github.com/yaml/libyaml/pull/53 -- Switch from test blacklist to whitelist * https://github.com/yaml/libyaml/pull/55 -- Update defs for MingGW support on Windows * https://github.com/yaml/libyaml/pull/58 -- Improve CMakeLists * https://github.com/yaml/libyaml/pull/64 -- README: Update libyaml link * https://github.com/yaml/libyaml/pull/69 -- Skip 5 tests in libyaml-emitter.list * https://github.com/yaml/libyaml/pull/74 -- Forbid escaped singlequote in doublequotes * https://github.com/yaml/libyaml/pull/77 -- Undefined PTRDIFF_MAX on HP-UX * https://github.com/yaml/libyaml/pull/78 -- Fixed most compiler warnings -Wall -Wextra * https://github.com/yaml/libyaml/pull/86 -- Fix problems in CI failures (travis and semaphore) * https://github.com/yaml/libyaml/pull/87 -- appveyor.yml: add mingw-w64 builds * https://github.com/yaml/libyaml/pull/88 -- add -no-undefined to src/Makefile.am * https://github.com/yaml/libyaml/pull/89 -- Added alpine linux testing to dockerfiles * https://github.com/yaml/libyaml/pull/93 -- remove need for PTRDIFF_MAX * https://github.com/yaml/libyaml/pull/94 -- .gitignore: major cleanup Resources ========= LibYAML IRC Channel: #libyaml on irc.freenode.net LibYAML homepage: https://github.com/yaml/libyaml Source download: https://github.com/yaml/libyaml/archive/dist-0.2.1.zip GitHub repository: https://github.com/yaml/libyaml Bug tracking: https://github.com/yaml/libyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About LibYAML ============= YAML is a data serialization format designed for human readability and interaction with scripting languages. LibYAML is a C library for parsing and emitting YAML. LibYAML is the underlying parser/emitter code for YAML frameworks in many programming languages. Maintainers =========== The following people are responsible for maintaining LibYAML: * Ingy döt Net * Ian Cordasco * Tina Mueller and many thanks to all who have contribributed! See: https://github.com/yaml/libyaml/pulls Copyright ========= Copyright (c) 2017-2018 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The LibYAML module was written by Kirill Simonov <xi...@re...>. It is currently maintained by the YAML community. LibYAML is released under the MIT license. See the file LICENSE for more details. |
From: Ingy d. N. <in...@in...> - 2018-06-26 22:49:28
|
======================= Announcing PyYAML-4.1 ======================= A new MAJOR RELEASE of PyYAML is now available: https://pypi.org/project/PyYAML/ This is the first release of PyYAML under a new maintenance team. In August 2016, maintenance of PyYAML and LibYAML was turned over from the original author, Kirill Simonov, to Ian Cordasco and Ingy döt Net. The canonical source repo moved: from: https://bitbucket.org/xi/pyyaml/ to: https://github.com/yaml/pyyaml The PyYAML project is now maintained by the YAML and Python communities. Planning happens on the #yaml-dev, #pyyaml and #libyaml IRC channels on irc.freenode.net. Changes ======= * https://github.com/yaml/pyyaml/pull/35 -- Some modernization of the test running * https://github.com/yaml/pyyaml/pull/42 -- Install tox in a virtualenv * https://github.com/yaml/pyyaml/pull/45 -- Allow colon in a plain scalar in a flow context * https://github.com/yaml/pyyaml/pull/48 -- Fix typos * https://github.com/yaml/pyyaml/pull/55 -- Improve RepresenterError creation * https://github.com/yaml/pyyaml/pull/59 -- Resolves #57, update readme issues link * https://github.com/yaml/pyyaml/pull/60 -- Document and test Python 3.6 support * https://github.com/yaml/pyyaml/pull/61 -- Use Travis CI built in pip cache support * https://github.com/yaml/pyyaml/pull/62 -- Remove tox workaround for Travis CI * https://github.com/yaml/pyyaml/pull/63 -- Adding support to Unicode characters over codepoint 0xffff * https://github.com/yaml/pyyaml/pull/65 -- Support unicode literals over codepoint 0xffff * https://github.com/yaml/pyyaml/pull/74 -- Make pyyaml safe by default. * https://github.com/yaml/pyyaml/pull/75 -- add 3.12 changelog * https://github.com/yaml/pyyaml/pull/76 -- Fallback to Pure Python if Compilation fails * https://github.com/yaml/pyyaml/pull/84 -- Drop unsupported Python 3.3 * https://github.com/yaml/pyyaml/pull/111 -- Remove commented out Psyco code * https://github.com/yaml/pyyaml/pull/149 -- Test on Python 3.7-dev * https://github.com/yaml/pyyaml/pull/158 -- Support escaped slash in double quotes "\/" Resources ========= PyYAML IRC Channel: #pyyaml on irc.freenode.net PyYAML homepage: https://github.com/yaml/pyyaml PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation Source and binary installers: https://pypi.org/project/PyYAML/ GitHub repository: https://github.com/yaml/pyyaml/ Bug tracking: https://github.com/yaml/pyyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About PyYAML ============ YAML is a data serialization format designed for human readability and interaction with scripting languages. PyYAML is a YAML parser and emitter for Python. PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support, capable extension API, and sensible error messages. PyYAML supports standard YAML tags and provides Python-specific tags that allow to represent an arbitrary Python object. PyYAML is applicable for a broad range of tasks from complex configuration files to object serialization and persistence. Example ======= >>> import yaml >>> yaml.load(""" ... name: PyYAML ... description: YAML parser and emitter for Python ... homepage: https://github.com/yaml/pyyaml ... keywords: [YAML, serialization, configuration, persistence, pickle] ... """) {'keywords': ['YAML', 'serialization', 'configuration', 'persistence', 'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description': 'YAML parser and emitter for Python', 'name': 'PyYAML'} >>> print yaml.dump(_) name: PyYAML homepage: https://github.com/yaml/pyyaml description: YAML parser and emitter for Python keywords: [YAML, serialization, configuration, persistence, pickle] Maintainers =========== The following people are responsible for maintaining PyYAML: * Ingy döt Net * Ian Cordasco * Tina Mueller * Alex Gaynor * Donald Stufft * Matt Davis and many thanks to all who have contribributed! See: https://github.com/yaml/pyyaml/pulls Copyright ========= Copyright (c) 2017-2018 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The PyYAML module was written by Kirill Simonov <xi...@re...>. It is currently maintained by the YAML and Python communities. PyYAML is released under the MIT license. See the file LICENSE for more details. |
From: Joachim W. <j.w...@fz...> - 2018-05-04 14:54:22
|
We consider YAML as a candidate for combining metadata with 256x256 or 1024x1204 images (actually physical detector counts, mostly small integers, which makes ASCII storage quite efficient). Unfortunately, yamlcpp and libyaml are both too slow for our purpose; they perform 1-2 orders of magnitude slower than JSON or purpose-written ASCII parsers. In plain YAML, our image data reside in a sequence of sequences, like - image: - [ 0 3 2 0 8 ... ] - [ 1 0 7 3 2 ... ] - ... This is inefficient because the parser has no knowledge about this peculiar data structure, and therefore spends lots of time with unnecessary actions. Is this right? What do you think of the following concept: Define a tag !!array, to be used as follows: - image: !!array 2 uint8 256 256 | 0 3 2 0 8 ... 1 0 7 3 2 ... The number immediately after the tag (here 2) indicates the rank D; the next word (here uint8) is the data type; the next D numbers (here 256 and 256) indicate the size of the multidimenional array. This then is followed by the image data themselves. In our read-in routine, upon encountering the tag '!!array', we would switch from the parser of libyaml to a parser of our own that takes full advantage of our knowledge of what entries must follow an '!!array' tag. Does this make sense? Is it consistent with letter and intent of the YAML specs? Or what else should we do to reconcile YAML with our need for speed? - Joachim |
From: Tina M. <po...@ti...> - 2018-03-05 16:06:43
|
On Mon, 5 Mar 2018, Andrey Somov wrote: > P.S. It is sad that communication happens in a place which is not indexed > by search engines and it is available to a a handful participants only... Our plan is to invite a logging bot to the channel, so that the log is available for everyone. Ingy, any progress on that? |
From: Andrey S. <pub...@gm...> - 2018-03-05 15:58:54
|
Hi all, >There are categories of change for the above: Syntax and Schema. Syntax is an obvious concept. Schema (especially for YAML) is more >complex and nuanced. Well, syntax is an obvious concept. But it has non-obvious implementation. The syntax is changed with every version. It will keep to change with every version if every version is adding new features. Where is the limit ? What I want to say is that already now the syntax is overloaded. Users (the ones which contact me) do not understand it. That is why I vote for the radical simplification. If we do not want to simplify the syntax then: 1. The %YAML <VERSION >directive must become mandatory 2. SCHEMA definition should not be a part of a YAML document. The context must not be defined in the document. P.S. It is sad that communication happens in a place which is not indexed by search engines and it is available to a a handful participants only... Cheers, Andrey On Mon, Mar 5, 2018 at 11:46 AM, Tina Müller <po...@ti...> wrote: > On Sun, 4 Mar 2018, Ingy dot Net wrote: > > An interesting thing is that all the current implementations do have >> “schemas” but not in any concise doc. The schema for a given >> implementation >> is encoded in programming source code. >> > > My YAML::PP project (perl) is schema aware, and you can already > choose between Failsafe, JSON and Core, for loading. > It's work in progress, though, but I wanted to mention that > there is something going on regarding that. > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Tina M. <po...@ti...> - 2018-03-05 10:46:17
|
On Sun, 4 Mar 2018, Ingy dot Net wrote: > An interesting thing is that all the current implementations do have > “schemas” but not in any concise doc. The schema for a given implementation > is encoded in programming source code. My YAML::PP project (perl) is schema aware, and you can already choose between Failsafe, JSON and Core, for loading. It's work in progress, though, but I wanted to mention that there is something going on regarding that. |
From: Ingy d. N. <in...@in...> - 2018-03-04 23:34:34
|
Andrey/Peter, Thanks for bringing this up. I’ll try to state my vision and what we are aiming for in YAML 1.3. There are categories of change for the above: Syntax and Schema. Syntax is an obvious concept. Schema (especially for YAML) is more complex and nuanced. There is a non-obvious concept to truly understanding YAML: any given YAML document (by itself) has no known precise meaning. Put another way, any YAML document can *mean* anything. What is needed to give meaning to a YAML document is the concept of “Schema”. At present, Schema is a very grey area. At the time that we put out the 1.2 spec, we agreed amongst ourselves, that the preferred default schema is the same (as much as applicable) to JSON. i.e. all plain, non-numeric scalars are loaded as strings except for the values [true, false, null]. Unfortunately we never retired the YAML type repository which suggests many other implicits. It is no wonder that there is so much variance between implementations. The concept of YAML schema has not been yet been defined. I started working on a project called “SchemaType <http://www.schematype.org/>” a couple years ago, but it is still a WIP. The future of YAML, imho, lies primarily in schema-aware implementations. Here is some pseudo-code to demonstrate: schema-object = YAML.Schema.load(‘something-awesome.schema’) data-object = YAML.load-file(‘something-awesome.yaml’, schema=schema-object) yaml-text = YAML.dump(data-object, schema=schema-object) Where the default schema is something as simple as possible. Personally I imagine that *all* non-numeric scalars load as strings and we use [!true, !false, !null] for those values. As you can see, this idea of Schema goes beyond validation. It also contains formatting info on how data should be dumped/emitted. An interesting thing is that all the current implementations do have “schemas” but not in any concise doc. The schema for a given implementation is encoded in programming source code. The result is that most implementations are consistent with themselves but not with other implementations. This makes YAML useful in a contained environment but less so between heterogenous environments. The cool thing is that we could, right now, write up schema docs for all the existing implementations. Of course they wouldn’t *do* anything besides be a quick reference on what to expect a particular implementation to do. But once we move towards having schema aware implementations, then we can move forward to what we *want* while still supporting the old schemas for legacy code. Note: the above is the solution for schema related things, not syntax. For syntax, a group of us are working on YAML 1.3. See: - YAML Test Suite <https://github.com/yaml/yaml-test-suite> - YAML Spec RFCs <https://github.com/yaml/yaml-spec/wiki/YAML-RFC-Index> The focus of 1.3 is to tighten up al the edge cases of the 1.2 spec, such that everything “important” still works, but everything unintended or truly undesirable is removed. Instead of working on a new spec to drive this (yes a spec will be needed) we focus on an empirical test suite. We also are making RFCs for each change, though several will be rejected, or will need to wait past 1.3. The bigger focus is that we do things in such a way, as that we end up with all the implementations doing things in a consistent way. This will require a Developer’s Guide, with clear advice on what should be considered and done. Andrey, I’ll let you know where I fall on your 6 points now. Let me preface that although the world sees YAML as a better config language, YAML will remain bigger than that. YAML is a human friendly serialization language. It just happens that the features we used to make YAML, ended up being a reasonable choice for config. :) 1) Absolutely. The default schema should be JSON or simpler (as noted above). But schema-aware implementations can easily use legacy schemas. 2) Complex keys will stay, but in block form we will require an explicit indicator ‘?’. YAML will stick to its serialization language guns. 3) I used to agree with getting rid of folded scalars, but now it is widely used and to good effect. Without it, a stray ‘:’ or ‘#’ can mess up a multiline. > stays for 1.3. 4/5) To be able to encode any printable value as a block literal, these are needed. They are certainly edge cases, but they aren’t hard to implement. Keeping them in 1.3. 6) %YAML and %TAG are the only directives. This topic deserves it’s own email. I want to get rid of them. %TAG takes a ton of effort to implement for little value imho. If you have schema, the need evaporates. %YAML is not really useful, because there is no clear/precise/concise meaning to 1.0/1/1/1.2. The spec is just not precise enough to be the final say on what a YAML doc means, sadly. Also nobody uses %YAML now, and I don’t want to force people to start using this. Soooo for #6, not sure about %TAG for 1.3. %YAML will stay for 1.3. It’s easy to implement. Note: I really think if %YAML is needed (i.e. we can’t get the info any other way), then it might turn into: %YAML http://ingy.net/awesome.schema i.e., you associate the doc to a schema, not a version. The schema can define what the spec version is and a whole lot more. This is a lot more compelling for people to add into their YAML files, because people can follow the link to read for themselves exactly what is intended. If it’s only a version #, there are very few people in the world (if anybody at all) who knows exactly what a version means. Eventually the *test suite* will have tests for every case in every version, but nobody could be expected to have the entire scope of the test suite in their head. re: https://github.com/yaml/yaml-spec/wiki which was mostly written in 2011, we’ll need to look over those ideas again and move them over to the RFCs. Development discussion is active on FreeNode IRC in #yaml-dev and most discussion of things happens in GItHub issues on projects under https://github.com/yaml/ Andrey I know you aren’t a fan of IRC, but this email list is pretty much retired. IRC is still used on many Major projects. Everyone: YAML development resources are greatly needed. Don’t hesitate to get involved. Peter, I think my answers to Andrey should answer your stances. With schema-awareness the default is trivial and interoperable but any other behavior only requires a new schema. FYI SchemaType is designed to be very Object Oriented, which is to say, new complex schemas can “inherit” from existing ones (if they exist of course) and just override a few properties. Getting exactly what you want/need should be easy. Cheers, Ingy On Sun, Mar 4, 2018 at 4:33 AM, Andrey Somov <pub...@gm...> wrote: > Hi all, > I see 2 major directions for YAML evolution: > > 1. radical simplification > 2. more features > > The advantages of the first: > a) easy adoption > b) rock solid spec - because there is nothing to change like in JSON > c) no need to mention version (1.1, 1.2. 1.3, 2.0 etc) > d) we can drop %YAML directive because all the versions are supposed to be > the same > > I do not claim that simplification does not have disadvantages but does > make YAML more user friendly. > > (who complains that boolean has 2 values instead of 18 ? ) > > I would like to vote to the features which can and should be dropped: > > 1. all the implicit types except the ones from JSON (users should be able > to define custom implicit types) Recommended Schema_s_ should become > Schem_a_ > 2. Complex keys (let us allow JavaScript to implement the spec). No need > to discuss the 1024 limit > 3. Folded scalar > 4. Chomping indicators > 5. Indentation indicators (who is using it and why?) > 6. Directives > > > Feel free to add your vision here. > > Cheers, > Andrey > SnakeYAML developer > > P.S. I fully support proposals (https://github.com/yaml/yaml-spec/wiki) > which make YAML stricter. > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Peter M. <pet...@gm...> - 2018-03-04 21:31:39
|
Andrey (and all): While I don't have any objection to dropping 3 to 6, I object to dropping 1 and 2. 1: JSON has one numerical type, because JavaScript doesn't support any distinction between floats and integers. Other languages support this distinction. I think preserving implicit types for floats and integers (and datetimes as well) is useful. 2: Some languages like Python allow tuples and immutable sets as keys for mappings. One of the strengths of YAML is that it doesn't put limitations on what data it can handle. Let's keep this strength. Best regards, Peter On Sun, Mar 4, 2018 at 10:33 PM, Andrey Somov <pub...@gm...> wrote: > Hi all, > I see 2 major directions for YAML evolution: > > 1. radical simplification > 2. more features > > The advantages of the first: > a) easy adoption > b) rock solid spec - because there is nothing to change like in JSON > c) no need to mention version (1.1, 1.2. 1.3, 2.0 etc) > d) we can drop %YAML directive because all the versions are supposed to be > the same > > I do not claim that simplification does not have disadvantages but does make > YAML more user friendly. > > (who complains that boolean has 2 values instead of 18 ? ) > > I would like to vote to the features which can and should be dropped: > > 1. all the implicit types except the ones from JSON (users should be able to > define custom implicit types) Recommended Schema_s_ should become Schem_a_ > 2. Complex keys (let us allow JavaScript to implement the spec). No need to > discuss the 1024 limit > 3. Folded scalar > 4. Chomping indicators > 5. Indentation indicators (who is using it and why?) > 6. Directives > > > Feel free to add your vision here. > > Cheers, > Andrey > SnakeYAML developer > > P.S. I fully support proposals (https://github.com/yaml/yaml-spec/wiki) > which make YAML stricter. > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > -- Email: pet...@gm... WWW: http://www.pkmurphy.com.au/ |
From: Andrey S. <pub...@gm...> - 2018-03-04 15:49:13
|
Hi all, I see 2 major directions for YAML evolution: 1. radical simplification 2. more features The advantages of the first: a) easy adoption b) rock solid spec - because there is nothing to change like in JSON c) no need to mention version (1.1, 1.2. 1.3, 2.0 etc) d) we can drop %YAML directive because all the versions are supposed to be the same I do not claim that simplification does not have disadvantages but does make YAML more user friendly. (who complains that boolean has 2 values instead of 18 ? ) I would like to vote to the features which can and should be dropped: 1. all the implicit types except the ones from JSON (users should be able to define custom implicit types) Recommended Schema_s_ should become Schem_a_ 2. Complex keys (let us allow JavaScript to implement the spec). No need to discuss the 1024 limit 3. Folded scalar 4. Chomping indicators 5. Indentation indicators (who is using it and why?) 6. Directives Feel free to add your vision here. Cheers, Andrey SnakeYAML developer P.S. I fully support proposals (https://github.com/yaml/yaml-spec/wiki) which make YAML stricter. |
From: Ingy d. N. <in...@in...> - 2018-02-05 02:54:55
|
Hi Eemeli, You might be interested in these repositories: - https://github.com/yaml/yaml-spec - https://github.com/yaml/yaml-test-suite I mention these primarily because that is a better place to bring these concerns up as issues (and possibly pull requests). I look forward to discussing these as github issues. Cheers, Ingy On Wed, Jan 31, 2018 at 6:19 PM, Eemeli Aro <ee...@gm...> wrote: > I think there's also a mistake in example 8.2, where the last folded > value is parsed to be "\t·detected\n", while it should be > "\t\ndetected\n" -- the tab prefix means that the line is more folded, > i.e. an s-nb-spaced-text(n) production, and therefore its subsequent > newline should not be folded into a space. Admittedly it's a bit weird > to have a first line in a block be "more folded", but I'm pretty sure > that's what the spec maps it to. > > On 31 January 2018 at 21:53, Eemeli Aro <ee...@gm...> wrote: > > Hi all, > > > > I'm working on a new JavaScript YAML 1.2 library, and while testing my > > code against the examples given in the spec, I've come across a couple > > of inconsistencies. I trust this might be a good place to ask about > > them? > > > > When a non-strip block scalar appears as the last entry in a file that > > is not terminated by a newline, should the value of that scalar still > > include a terminating newline? In the spec, example 6.4 appears to do > > so, while example 8.21 does not. My own preference here would be to > > always include a newline, as otherwise it's very easy to alter the > > value while processing, especially when reordering documents in a > > stream. > > > > Is there a mistake in the parsing of the "keep" value of example 8.5? > > Specifically, should its value be "# text\n\n" rather than "# text\n"? > > It's followed by dedented comment lines, and the second newline is > > highlighted in the source as being a part of the l-keep-empty(n) > > production. The following example 8.6 similarly highlights the (only) > > line of its "keep" value with the same production, but shows that > > newline to be a part of the resulting value. > > > > On a different note, would anyone have good pointers for > > implementations of marshalling YAML scalars? For instance, when a map > > includes multiple different numerical values, and some of them are (or > > should be) stored as hexadecimal while others as decimal, how do other > > implementations control this and/or guarantee that a load/modify/dump > > cycle won't normalise all of these numbers to a single style of > > representation? > > > > My code so far is at https://github.com/eemeli/yaml and > > https://github.com/eemeli/raw-yaml; only the latter lower-level > > interface is published so far on npm. > > > > eemeli > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > |
From: Eemeli A. <ee...@gm...> - 2018-02-01 01:19:51
|
I think there's also a mistake in example 8.2, where the last folded value is parsed to be "\t·detected\n", while it should be "\t\ndetected\n" -- the tab prefix means that the line is more folded, i.e. an s-nb-spaced-text(n) production, and therefore its subsequent newline should not be folded into a space. Admittedly it's a bit weird to have a first line in a block be "more folded", but I'm pretty sure that's what the spec maps it to. On 31 January 2018 at 21:53, Eemeli Aro <ee...@gm...> wrote: > Hi all, > > I'm working on a new JavaScript YAML 1.2 library, and while testing my > code against the examples given in the spec, I've come across a couple > of inconsistencies. I trust this might be a good place to ask about > them? > > When a non-strip block scalar appears as the last entry in a file that > is not terminated by a newline, should the value of that scalar still > include a terminating newline? In the spec, example 6.4 appears to do > so, while example 8.21 does not. My own preference here would be to > always include a newline, as otherwise it's very easy to alter the > value while processing, especially when reordering documents in a > stream. > > Is there a mistake in the parsing of the "keep" value of example 8.5? > Specifically, should its value be "# text\n\n" rather than "# text\n"? > It's followed by dedented comment lines, and the second newline is > highlighted in the source as being a part of the l-keep-empty(n) > production. The following example 8.6 similarly highlights the (only) > line of its "keep" value with the same production, but shows that > newline to be a part of the resulting value. > > On a different note, would anyone have good pointers for > implementations of marshalling YAML scalars? For instance, when a map > includes multiple different numerical values, and some of them are (or > should be) stored as hexadecimal while others as decimal, how do other > implementations control this and/or guarantee that a load/modify/dump > cycle won't normalise all of these numbers to a single style of > representation? > > My code so far is at https://github.com/eemeli/yaml and > https://github.com/eemeli/raw-yaml; only the latter lower-level > interface is published so far on npm. > > eemeli |
From: Eemeli A. <ee...@gm...> - 2018-01-31 19:54:03
|
Hi all, I'm working on a new JavaScript YAML 1.2 library, and while testing my code against the examples given in the spec, I've come across a couple of inconsistencies. I trust this might be a good place to ask about them? When a non-strip block scalar appears as the last entry in a file that is not terminated by a newline, should the value of that scalar still include a terminating newline? In the spec, example 6.4 appears to do so, while example 8.21 does not. My own preference here would be to always include a newline, as otherwise it's very easy to alter the value while processing, especially when reordering documents in a stream. Is there a mistake in the parsing of the "keep" value of example 8.5? Specifically, should its value be "# text\n\n" rather than "# text\n"? It's followed by dedented comment lines, and the second newline is highlighted in the source as being a part of the l-keep-empty(n) production. The following example 8.6 similarly highlights the (only) line of its "keep" value with the same production, but shows that newline to be a part of the resulting value. On a different note, would anyone have good pointers for implementations of marshalling YAML scalars? For instance, when a map includes multiple different numerical values, and some of them are (or should be) stored as hexadecimal while others as decimal, how do other implementations control this and/or guarantee that a load/modify/dump cycle won't normalise all of these numbers to a single style of representation? My code so far is at https://github.com/eemeli/yaml and https://github.com/eemeli/raw-yaml; only the latter lower-level interface is published so far on npm. eemeli |
From: Andrey S. <pub...@gm...> - 2017-12-25 22:27:11
|
Hi all, there is work progress to "fix" colon in the flow context (libyaml, PyYAML, SnakeYAML). What happens in PyYAML is the code which was preventing to use the colon is removed. The consequences: 1. The example 8.13 Completely Empty Flow Nodes ( http://yaml.org/spec/1.1/current.html#id902919) becomes broken. The ':' becomes added to the "foo" key. 2. Counter intuitive YAML documents will bring a lot of complains and misunderstanding {a:1} is "a:1" -> null {a:} is "a:" -> null {a :} is "a :" -> null I see 3 possible ways to continue: 1. Revert it to how it was (the 1.1 spec is inconsistent and there was a good reason for Kirill to prohibit colon) 2. Allow colon but fix the 1.1 and 1.2 specs, add tests, communicate the change 3. Address the issue in future 1.3 and let the current implementation stay My personal preference is either 1 or 3. Cheers, Andrey (SnakeYAML developer) |
From: Thomas C. <dr...@gm...> - 2017-11-22 05:31:38
|
Thank you for that analysis. The YAML spec is somewhat different to other specifications that I've worked with in the past, since it is, as you point out, reticent about constraining behaviour. On 22 November 2017 at 13:10, flyx <ya...@fl...> wrote: > My answer is based on the fact that both SnakeYaml and PyYaml are YAML > 1.1. However, the answer would not be substantially different for YAML 1.2 > since implicit tag resolutions introduced in YAML 1.2 are only suggestions > and not required to be supported by a conforming implementation. > > On 20. Nov 2017, at 02:10, Thomas Conway <dr...@gm...> wrote: > >> >> [snip] >> >> Note in particular that the string value for the key 'sampleName' is a >> sequence of digits with a leading zero, and is not quoted. >> > > When we read it in to our java system (using snakeyaml), the unquoted >> sequence of digits is turned into an integer, which means that subsequent >> steps drop the leading zero. >> >> I've tried reading the specification, but I can't see that it defines the >> conversion. >> > > Nor does it disallow it. Unquoted scalars get the non-specific „?“ whose > resolution is not defined by the specification. This means that an > implementation has complete freedom over how it interprets a scalar like > „08063075“. Some regexes have been given in the type registry for YAML 1.1, > including the !!int tag [1]; however, supporting them is not required and > implicitly resolving them based on the given regexes is not either and > actually never even suggested anywhere (although it is commonly implemented > in YAML 1.1 implementations). > > Is the serialisation valid? >> >> Is the conversion of the string of digits to an integer valid? >> > > Let’s look up the definition of validity in the YAML 1.1 spec: > > To be valid, a node must have a tag which is recognized by the YAML >> processor and its content must satisfy the constraints imposed by this tag. >> > > Note that the YAML specification nowhere gives any details about how > native types must be (de)serialised to/from YAML tags – with good reason. > Therefore, it is hard to tell what to base an answer to your question on. I > would say that serialising the string to an unquoted scalar is definitely > valid, since a YAML !!str tag allows its content. Note that concerning the > serialisation, rendering a string as unquoted scalar is *always* valid > since the definition of validity only concerns the relation between a > node’s content and its tag, and if we assume that the implementation knows > the !!str tag and chooses to render all nodes that have been given the > !!str tag when creating them from the native object as unquoted scalars if > possible. The choice of giving the !!str tag to a native string object > „08063075“ (or even „42“ or „false“) is not covered by the specification > and therefore cannot be invalid. > > On the loading side, things are a bit different. If, for example, we > assume that the scalar „08063075“ is given the !!int tag based on the > knowledge that it is afterwards transformed into a Java Integer, this is > invalid since the scalar’s content does not satisfy the constraints imposed > by the !!int tag [1] (i.e. the regex). However, since !!int is mentioned, > but not defined, in the YAML 1.1 specification, you could also say that > even in doing this, SnakeYaml does conform to the specification since > conforming to the !!int regex is not required by the spec. > > On the practical side, it is a bad thing for SnakeYaml not to comply to > the !!int regex since this harms interoperability. But you asked for > specification conformance, and as I said, one can argue that this behavior > *is* conformant. > > A word of advice: SnakeYaml does allow you to specify the target type you > want to deserialise to. If you define a POJO that contains all the fields > which are properly typed, you can just tell SnakeYaml to load the YAML into > that POJO, and chances are that when it sees that the target type is a > String, it will load the scalar as String no matter how its content looks. > I do not know SnakeYaml internals, so I cannot guarantee that it will work, > but I've never seen it fail. > > Regards, > Felix > > > [1]: http://yaml.org/type/int.html > > -- Thomas Conway dr...@gm... My friends, love is better than anger. Hope is better than fear. Optimism is better than despair. So let us be loving, hopeful and optimistic. And we'll change the world. - Jack Layton |
From: flyx <ya...@fl...> - 2017-11-22 02:08:13
|
My answer is based on the fact that both SnakeYaml and PyYaml are YAML 1.1. However, the answer would not be substantially different for YAML 1.2 since implicit tag resolutions introduced in YAML 1.2 are only suggestions and not required to be supported by a conforming implementation. On 20. Nov 2017, at 02:10, Thomas Conway <dr...@gm...> wrote: > > [snip] > > Note in particular that the string value for the key 'sampleName' is a > sequence of digits with a leading zero, and is not quoted. > When we read it in to our java system (using snakeyaml), the unquoted > sequence of digits is turned into an integer, which means that > subsequent steps drop the leading zero. > > I've tried reading the specification, but I can't see that it defines > the conversion. Nor does it disallow it. Unquoted scalars get the non-specific „?“ whose resolution is not defined by the specification. This means that an implementation has complete freedom over how it interprets a scalar like „08063075“. Some regexes have been given in the type registry for YAML 1.1, including the !!int tag [1]; however, supporting them is not required and implicitly resolving them based on the given regexes is not either and actually never even suggested anywhere (although it is commonly implemented in YAML 1.1 implementations). > Is the serialisation valid? > > Is the conversion of the string of digits to an integer valid? Let’s look up the definition of validity in the YAML 1.1 spec: > To be valid, a node must have a tag which is recognized by the YAML > processor and its content must satisfy the constraints imposed by this > tag. Note that the YAML specification nowhere gives any details about how native types must be (de)serialised to/from YAML tags – with good reason. Therefore, it is hard to tell what to base an answer to your question on. I would say that serialising the string to an unquoted scalar is definitely valid, since a YAML !!str tag allows its content. Note that concerning the serialisation, rendering a string as unquoted scalar is *always* valid since the definition of validity only concerns the relation between a node’s content and its tag, and if we assume that the implementation knows the !!str tag and chooses to render all nodes that have been given the !!str tag when creating them from the native object as unquoted scalars if possible. The choice of giving the !!str tag to a native string object „08063075“ (or even „42“ or „false“) is not covered by the specification and therefore cannot be invalid. On the loading side, things are a bit different. If, for example, we assume that the scalar „08063075“ is given the !!int tag based on the knowledge that it is afterwards transformed into a Java Integer, this is invalid since the scalar’s content does not satisfy the constraints imposed by the !!int tag [1] (i.e. the regex). However, since !!int is mentioned, but not defined, in the YAML 1.1 specification, you could also say that even in doing this, SnakeYaml does conform to the specification since conforming to the !!int regex is not required by the spec. On the practical side, it is a bad thing for SnakeYaml not to comply to the !!int regex since this harms interoperability. But you asked for specification conformance, and as I said, one can argue that this behavior *is* conformant. A word of advice: SnakeYaml does allow you to specify the target type you want to deserialise to. If you define a POJO that contains all the fields which are properly typed, you can just tell SnakeYaml to load the YAML into that POJO, and chances are that when it sees that the target type is a String, it will load the scalar as String no matter how its content looks. I do not know SnakeYaml internals, so I cannot guarantee that it will work, but I've never seen it fail. Regards, Felix [1]: http://yaml.org/type/int.html |