Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test java codegen with strange type / module names using daml-lf directly #2

Closed
2 of 3 tasks
francesco-da opened this issue Feb 25, 2019 · 3 comments
Closed
2 of 3 tasks
Labels
component/java-ecosystem Java development experience

Comments

@francesco-da
Copy link
Contributor

there are various edge cases in the java codegen that we cannot test easily or at all using a .daml file. for example i do not believe we can currently generate type names with dollars in them from .daml.

before it was very hard to write DAML-LF directly, but it's actually much easier now thanks to @remyhaemmerle-da 's parser. see https://github.com/DACH-NY/daml/blob/2766d13da75fcf7b1e08f00fbc02d6891aa53645/daml-foundations/daml-lf/interface/src/test/scala/com/digitalasset/daml/lf/iface/TypeSpec.scala#L75 for an example test where i use the type parser.

problematic tests we should make sure to test:

and anything else @stefanobaghino-da , @gerolf-da , or @mariop-da can think of.

@gerolf-da
Copy link
Contributor

@francesco-da: regarding point 1) " strange names (dollars, keywords, etc)", other than keywords in the target language, how can we even get strange names. SimpleString should shield us from that, no?
The only case SimpleString doesn't seem to be covering is when a name starts with a number, although that might be more of a restriction in the particular uses of SimpleString (i.e. a party might start with a number, but a module name not).

@remyhaemmerle-da
Copy link
Collaborator

SimpleString was designed for Party and PackageId only. Note that SimpleString does not handles '$'
I was considering adding a new type for everything that may end up as Java Identifier, but not before the migration to bazel is finished.

@gerolf-da gerolf-da reopened this Feb 28, 2019
@francesco-da francesco-da changed the title test java codegen edge cases using daml-lf directly test java codegen with strange type / module names using daml-lf directly Mar 21, 2019
@ghost ghost transferred this issue from another repository Mar 31, 2019
@ghost ghost added the component/java-ecosystem Java development experience label Mar 31, 2019
@ghost ghost added this to the Java Ecosystem First Version milestone Mar 31, 2019
@ghost ghost unassigned gerolf-da Apr 4, 2019
ghost pushed a commit that referenced this issue Jun 12, 2019
ghost pushed a commit that referenced this issue Jun 12, 2019
hsenag pushed a commit to hsenag/daml that referenced this issue Sep 13, 2019
@gerolf-da gerolf-da modified the milestones: Maintenance, Backlog Feb 14, 2020
@gerolf-da
Copy link
Contributor

We don't intend on writing DAML-LF directly for java codegen tests.

nickchapman-da added a commit that referenced this issue May 21, 2021
CHANGELOG_BEGIN
CHANGELOG_END

NormalizeRollbackSpec, WIP

WIP2

adapt to asVersionedTransaction

first stab at traversal for normalize-rollbacks... implement normalization rule #1

adapt existing testcase for rollback normalization rule #1

pluralize spec filename

temp disable rollback normalization

methodically test normalization rule #1

lots more tests

spec: check all 3 norm conditions

cleanup test/Shape code a bit

implement normalization rules #2 and #3 (using canonical types) and enable tests

add some comments and some 8020 todo markers
mergify bot pushed a commit that referenced this issue May 25, 2021
* Normalize rollbacks: first draft

CHANGELOG_BEGIN
CHANGELOG_END

NormalizeRollbackSpec, WIP

WIP2

adapt to asVersionedTransaction

first stab at traversal for normalize-rollbacks... implement normalization rule #1

adapt existing testcase for rollback normalization rule #1

pluralize spec filename

temp disable rollback normalization

methodically test normalization rule #1

lots more tests

spec: check all 3 norm conditions

cleanup test/Shape code a bit

implement normalization rules #2 and #3 (using canonical types) and enable tests

add some comments and some 8020 todo markers

* add 2 more testcases from Sofia

* ensure tx produced when normalizing rollbacks has increasing node-ids when listed in pre-order

* enable rollback normalization in interpreter

* manage state functionaly for the created tx (counter & node-map)

* un-nest sub defs from normalizeTx (we can because we removed the mutable state)

* rename: force* --> push*

* introduce CPS for push functions

* introduce trampolines for push functions to be stack safe

* one more bounce

* ensure generated node-ids start from 0

* test that transaction node-ids start from 0

* add commets about pass1/2; move makeRoll (part of pass 1) earlier in file

* intro CPS for pass-1 over original tx

* intro trampolines for pass-1. everything is stack safe now

* clarify comment

* remove make stack-safe todo

* be more private

* factorize/share Trampoline implementation with previous implementation in speedy.Anf

* prefer Vector over List, for better algorithmic complexity

* make Trampoline private to lf
sofiafaro-da added a commit that referenced this issue Jul 5, 2021
Part of #9947, building on the key visibility checks from #10136

This PR adds a divulgence warning inside the traceLog.
I wasn't sure whether:

1. these warnings should be kept in a separate structure from the
   traceLog, and therefore transmitted separately, or
2. these warnings should be kept together with traces, but the severity
   should be tracked and also transmitted over grpc, and warnings should
   be logged as warnings instead of as debug messages, or
3. these warnings should be kept together with traces, but
   logged as warnings instead of debug messages,
4. these warnings should be treated exactly like traces

I'm leaning toward #2, but this PR implements #3.

This PR tests the warning via the script service tests.

changelog_begin
changelog_end
sofiafaro-da added a commit that referenced this issue Jul 5, 2021
Part of #9947, building on the key visibility checks from #10136

This PR adds a divulgence warning inside the traceLog.
I wasn't sure whether:

1. these warnings should be kept in a separate structure from the
   traceLog, and therefore transmitted separately, or
2. these warnings should be kept together with traces, but the severity
   should be tracked and also transmitted over grpc, and warnings should
   be logged as warnings instead of as debug messages, or
3. these warnings should be kept together with traces, but
   logged as warnings instead of debug messages,
4. these warnings should be treated exactly like traces

I'm leaning toward #2, but this PR implements #3.

This PR tests the warning via the script service tests.

changelog_begin
changelog_end
sofiafaro-da added a commit that referenced this issue Jul 6, 2021
* Add divulgence warning and test in script service.

Part of #9947, building on the key visibility checks from #10136

This PR adds a divulgence warning inside the traceLog.
I wasn't sure whether:

1. these warnings should be kept in a separate structure from the
   traceLog, and therefore transmitted separately, or
2. these warnings should be kept together with traces, but the severity
   should be tracked and also transmitted over grpc, and warnings should
   be logged as warnings instead of as debug messages, or
3. these warnings should be kept together with traces, but
   logged as warnings instead of debug messages,
4. these warnings should be treated exactly like traces

I'm leaning toward #2, but this PR implements #3.

This PR tests the warning via the script service tests.

changelog_begin
changelog_end

* scalafmt

* Address Moritz's review

* Rename traceLog.add to traceLog.addDebug

* fix test

* Add test using exercise

* add single transaction test
fabiotudone-da added a commit that referenced this issue Oct 5, 2021
)

* Try and improve the explanation of compatibility test exclusions

CHANGELOG_BEGIN
CHANGELOG_END

* Fix scenario description

* Attempt #2 at trying and improving the explanation of compatibility test exclusions
skisel-da added a commit that referenced this issue Aug 17, 2022
…n filter. Attempt #2

CHANGELOG_BEGIN
CHANGELOG_END
atriantafyllos-da added a commit that referenced this issue Jan 16, 2024
paulbrauner-da pushed a commit that referenced this issue Jan 16, 2024
…1704.0.v67e3d1e3/3.0.0-snapshot.20240115.12269.0.vee57276e (#18183)

* update canton to 20240115.12269.0.vee57276e/2.9.0-snapshot.20240115.11704.0.v67e3d1e3/3.0.0-snapshot.20240115.12269.0.vee57276e

tell-slack: canton

* Adapt changes after changing of Decode.assertDecodeInfoPackage signature

* Fix canton-3x Bazel rules for 'Moved http health to node and migrated health based tests to X nodes #16415'

* Fixed GetEventsByContractIdResponse misalign in v2.

* Removed unused dependency.

* Removed unused dependency #2.

* Fix daml3-script upgrade querying. Disable the test as more work needed.

---------

Co-authored-by: Azure Pipelines Daml Build <[email protected]>
Co-authored-by: Tudor Voicu <[email protected]>
Co-authored-by: Yves Geissbuehler <[email protected]>
Co-authored-by: Andreas Triantafyllos <[email protected]>
Co-authored-by: Samuel Williams <[email protected]>
oliverse-da pushed a commit that referenced this issue Oct 21, 2024
* update canton to 20241020.14357.va37ef963

tell-slack: canton

* Changes for getActiveContracts.

* Changes for getActiveContracts #2.

* Improve terminology in upgrades error messages (#20053)

* Drop unused NewVariant errors, add NotAtEnd errors, improve messages

* Refactor error printing slightly

* Update error message expectations in lsp-tests & damlc-upgrades

* Add metadata to pkg IDs & drop upgrading/upgraded in upgrade err msgs

* Replace "Variant" with "Constructor" where appropriate

* lint

* Adjust filepaths, expectations for Variant -> Constructor rename

* Fixes for field names and test expectations given added metadata

* Increase grpc message max log length

* lint

* Move & rename PkgIdWithMeta, make name/version non-optional

* Use shared variable instead of calling PkgIdWithNameAndVersion thrice

* lint

---------

Co-authored-by: Azure Pipelines Daml Build <[email protected]>
Co-authored-by: Andreas Triantafyllos <[email protected]>
Co-authored-by: dylant-da <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/java-ecosystem Java development experience
Projects
None yet
Development

No branches or pull requests

3 participants