Ticket #4066 (closed enhancement: fixed)

Opened 6 years ago

Last modified 6 years ago

dprepro patch to allow literal braces

Reported by: briadam Owned by: briadam
Priority: normal Milestone: 5.2
Component: Software Requirements - User Version: VOTD
Severity: minor Keywords:
Cc: roystgnr@…, lpswile, mseldre Due Date:
Parent Tickets: Blocked By:
Blocking: Requestor:
Sensitive: no

Description

Roy writes on 20110811:

Roy,
Thank you for submitting the patch. I have entered it into our
tracking system and when it gets formally reviewed by our team it will
become part of the DAKOTA repository.
We appreciate your help,
Laura

Did that dprepro revision I made two years ago ever get formally rejected, or just stuck in limbo? It doesn't appear to have made it into Dakota 5.0 or 5.1, despite some new dprepro changes in the latter.

I've got a new dprepro patch, which I'll attach here along with the previous patch, in case there's still any interest. Whereas the previous patch was a bug fix, this one merely adds one new feature:
backslash-escaping of brace (and backslash) characters allows dprepro to support output file formats which use braces as syntax.

I.e.
{dakota_use_this = 1.0} \{dakota_ignore_this\} in the input template

gets replaced by
1.0 {dakota_ignore_this}
in the output file.

These patch files apply cleanly to the 5.1 dprepro, but so far I've only tested them as applied to the 4.2/5.0 dprepro. I've run into a separate bug with Dakota 5.0 and 5.1, which I'll post to the users'
list as a separate message.
---
Roy

Subtickets

Attachments

dprepro_50_to_roy.patch Download (2.0 KB) - added by briadam 6 years ago.
dprepro_roy1_to_roy2.patch Download (1.6 KB) - added by briadam 6 years ago.

Change History

comment:1 Changed 6 years ago by briadam

Short answer is we dropped the ball.

Roy's original patch is tracked in our internal bugs as 2984. When fixing, let's coordinate with internal 3016 (dprepro handling of integers), 3105 (allow arbitrary dprepro delimiter), and my local patch which permits user control of output formatting for fixed format codes.

Changed 6 years ago by briadam

Changed 6 years ago by briadam

comment:2 Changed 6 years ago by briadam

Referenced in changeset [678]:

Fix bug in dprepro (Ticket #4066 and internal 2984) where default-valued parameters like p1 in

sim1 = {p1 = 1.4}

were not overridden by those provided in the parameters file. When encountering an assignment in curly braces {tag = value} or {tag = expression}, we first check whether tag exists in the parameters file hash and if so, use that value instead of the default one in the template file.

Thanks to Roy Stogner for detecting and offering a patch for this bug.

comment:3 Changed 6 years ago by briadam

  • Status changed from new to assigned
  • Milestone set to 5.2

comment:4 Changed 6 years ago by briadam

Referenced in changeset [762]:

Add suite of tests for dprepro, covering the various bugs/enhancements currently in Trac.

Partially addresses Ticket #4066.

comment:5 Changed 6 years ago by briadam

Referenced in changeset [763]:

Updates to dprepro integrating Roy's suggested patch in Ticket #4066. Required resolving new features for delimiter selection and formatting with patch to allow escaping with backslash. Passess all tests in test/dprepro.

comment:6 Changed 6 years ago by briadam

This issue has been fixed.

Roy -- could you please verify whether the updated version of dprepro meets your requirements and passes your test cases? You can grab from:  https://software.sandia.gov/trac/dakota/export/763/core/trunk/examples/script_interfaces/generic/dprepro

We will credit you in our release notes -- thanks again!

comment:7 Changed 6 years ago by briadam

  • Status changed from assigned to closed
  • Resolution set to fixed

Considering this closed. Reopen if we get feedback.

Note: See TracTickets for help on using tickets.