[filesystem] Heads up; filesystem in trunk unstable while V2 removed
To ensure that history is preserved, the removal of version 2 will be done as three commits. Filesystem in trunk will be unstable during until all three commits are completed. Hopefully this will take less than an hour. I'll post a notice when complete. --Beman
On Mon, Mar 26, 2012 at 8:25 AM, Beman Dawes <bdawes@acm.org> wrote:
To ensure that history is preserved, the removal of version 2 will be done as three commits. Filesystem in trunk will be unstable during until all three commits are completed. Hopefully this will take less than an hour.
I'll post a notice when complete.
Completed. Tests passing on Windows. Linux being checked now. --Beman
On Mon, Mar 26, 2012 at 9:18 AM, Beman Dawes <bdawes@acm.org> wrote:
On Mon, Mar 26, 2012 at 8:25 AM, Beman Dawes <bdawes@acm.org> wrote:
To ensure that history is preserved, the removal of version 2 will be done as three commits. Filesystem in trunk will be unstable during until all three commits are completed. Hopefully this will take less than an hour.
I'll post a notice when complete.
Completed. Tests passing on Windows. Linux being checked now.
Linux tests passing. --Beman
On 26.03.2012 15:18, Beman Dawes wrote:
On Mon, Mar 26, 2012 at 8:25 AM, Beman Dawes<bdawes@acm.org> wrote:
To ensure that history is preserved, the removal of version 2 will be done as three commits. Filesystem in trunk will be unstable during until all three commits are completed. Hopefully this will take less than an hour.
I'll post a notice when complete. Completed. Tests passing on Windows. Linux being checked now.
This prompted me to port my project to v3, and I promptly ran into this bug: https://svn.boost.org/trac/boost/ticket/5118 Silently changing the behavior of foo.replace_extension("bar") is not good at all. Sebastian
On Mon, Mar 26, 2012 at 10:16 AM, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
On 26.03.2012 15:18, Beman Dawes wrote:
On Mon, Mar 26, 2012 at 8:25 AM, Beman Dawes<bdawes@acm.org> wrote:
To ensure that history is preserved, the removal of version 2 will be done as three commits. Filesystem in trunk will be unstable during until all three commits are completed. Hopefully this will take less than an hour.
I'll post a notice when complete.
Completed. Tests passing on Windows. Linux being checked now.
This prompted me to port my project to v3, and I promptly ran into this bug: https://svn.boost.org/trac/boost/ticket/5118
Grrr... I should have fixed that a long time ago... I kept trying to specify the function in terms of Postcondition, and kept getting myself tied up in knots. Here is a new spec rewritten as an Effects clause: Effects: * Any existing extension() is removed from the stored path, then * iff new_extension is not empty and does not begin with a dot character, a dot character is appended to the stored path, then * new_extension is appended to the stored path. That seem clearer to me than the previous wording, and corrects the missing removal of any existing extension(). Does it look OK to you? I'm working on test cases now, and will commit as soon as they are done and passing. Thanks, --Beman
On 26.03.2012, at 22:18, Beman Dawes wrote:
On Mon, Mar 26, 2012 at 10:16 AM, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
On 26.03.2012 15:18, Beman Dawes wrote:
On Mon, Mar 26, 2012 at 8:25 AM, Beman Dawes<bdawes@acm.org> wrote:
To ensure that history is preserved, the removal of version 2 will be done as three commits. Filesystem in trunk will be unstable during until all three commits are completed. Hopefully this will take less than an hour.
I'll post a notice when complete.
Completed. Tests passing on Windows. Linux being checked now.
This prompted me to port my project to v3, and I promptly ran into this bug: https://svn.boost.org/trac/boost/ticket/5118
Grrr... I should have fixed that a long time ago...
I kept trying to specify the function in terms of Postcondition, and kept getting myself tied up in knots.
Here is a new spec rewritten as an Effects clause:
Effects: * Any existing extension() is removed from the stored path, then * iff new_extension is not empty and does not begin with a dot character, a dot character is appended to the stored path, then * new_extension is appended to the stored path.
That seem clearer to me than the previous wording, and corrects the missing removal of any existing extension(). Does it look OK to you?
I'm working on test cases now, and will commit as soon as they are done and passing.
Sounds ok. Does this mean that if I do path("a/b.c").replace_extension("d/e"), the result will be "a/b.d/e"? Sebastian
On Mon, Mar 26, 2012 at 4:51 PM, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
On 26.03.2012, at 22:18, Beman Dawes wrote:
...
Here is a new spec rewritten as an Effects clause:
Effects: * Any existing extension() is removed from the stored path, then * iff new_extension is not empty and does not begin with a dot character, a dot character is appended to the stored path, then * new_extension is appended to the stored path.
That seem clearer to me than the previous wording, and corrects the missing removal of any existing extension(). Does it look OK to you?
I'm working on test cases now, and will commit as soon as they are done and passing.
Sounds ok. Does this mean that if I do path("a/b.c").replace_extension("d/e"), the result will be "a/b.d/e"?
Yes. Should there be a precondition that new_extension not include a directory specifier? I can't think of any valid use cases off the top of my head. The use cases I can think of are misuses. --Beman
participants (3)
-
Beman Dawes -
Peter Dimov -
Sebastian Redl