Hi there,
I am trying to run the code from repo GitHub - digital-asset/ex-cdm-swaps on Mac Pro M1 Chip.
I am getting errors - “Exception in thread “main” java.sql.SQLException: Error opening connection” when running daml navigator server, but I have sqlite-jdbc installed already on my machine. I am not sure if it has something to do with the apple chip.
Can someone help me take a look at the error?
Hi Eric,
We do not officially support Apple Silicon yet. SDK versions 1.17.0 and above have been reported to work on M1 machines under Rosetta.
Try installing it via softwareupdate --install-rosetta and running it again.
Hi Rohitt,
Thanks for the reply.
I tried installing softwareupdate --install-rosetta . But I am still getting the same error running the code after the installation.
However I do got an error when installing rosetta and I am not sure how to resolve this since I can’t find any solutions online.
Hi @Eric,
We do not support Rosetta; that is an Apple product. That said, my first recommendation would be to check that your operating system is up-to-date. At this point in time that means Monterey 12.6, which you can see by clicking “About This Mac” in the top-left Apple menu.
Hi @Eric,
This error looks very similar to the one in this thread, which affects Daml 1.16.0. Which version of Daml are you using?
Thanks for the quick reply @Gary_Verhaegen, well i am trying to run the project ex-cdm-swap and I see two versions are available for this project, one is 0.13 on master branch and other one is 1.3 on sdk-upgrade branch. Are you guys planning to upgrade the project ex-cdm-swap to latest daml version anytime soon?
Hi Eric
We currently don’t have plans to upgrade this example, as it is (or will be) superseeded by Daml Finance. There is currently an example of an FpML swap in there, and we do plan to add support for CDM trade definitions at some point.
That being said, you can certainly use the Daml CDM distribution available for download in the CDM Portal to make use of the data types define therein in your workflows.
Thanks @georg, btw how do we find the latest implementation for cdm event specification module? This is using 0.13 sdk GitHub - digital-asset/lib-cdm-event-specification-module. If I want to adapt it to latest sdk, is it possible? @Gary_Verhaegen @georg @rohitt
Hi @Eric,
As far as I’m aware, that repo is the latest version of that project. I’m not familiar with that project myself so I’m not sure what the future plans are, but for your convenience I have opened a PR to update it to 2.4.0.
@Eric similar to the CDM swaps example, the event specification module is based on a very outdated version of the ISDA CDM definitions. We intend to superseed it with CDM functionality in Daml Finance, but don’t have a concrete timeline for it.
If you can describe what you’re trying to achieve by using CDM we can help finding the best way forward for you.
My team is working on a CDS project using DAML so just wanted to see if the event specification modules can be updated to latest version. I just saw that the repo has been updated to version 2.4. I appreciate all the helps! @Gary_Verhaegen @georg
You might be interested in our CDS implementation in Daml Finance then! It supports lifecycling (ie. generating all contractual cashflows) and settlement thereof out of the box.
Here is the test case that shows how such trade is lifecycled.
@georg I looked through the cds implementation in Daml Finance. As you said it supports lifecycling and settlement but does it have event/choices like ProposeTermination, ProposePartialTermination, and ProposeNovation etc… that we saw in here? I feel like I am mixing a few things, but it will help if you can clarify that for me.
Daml Finance currently supports instrument lifecycle events, so those that result in the update of an instrument (eg. coupon payments, corporate actions, or the interest/default payments on a CDS). The events you listed we consider position lifecycle events, as they affect positions (ie. Holdings) and not the instrument (ie. the economic terms of a trade). Daml Finance currently doesn’t have an implementation for those, but it should be fairly straight-forward to add workflows to support these.
For example, for a novation you’d implement a propose/accept workflow, where the current counterparties of a trade (ie. the custodian and owner on a Holding) agree with the new counterparty on the terms of the novation. Then, the novation is executed essentially by transferring that Holding to a new counterparty. In case of a partial novation you’d first split off the notional to be novated, and transfer only that.
A termination would be implemented in a similar way, where two counterparties agree on archiving a Holding contract.
Hope this helps.
Thanks @georg , your explanations are very helpful!
