SmartPy

12 Feb 2025 01:34

entrypoint expects parameter of type sp.unknown, but got sp.record(contractLambda = sp.lambda_(sp.u ....

SmartPy

10 Feb 2025 07:57

What you can do is having a lambda given as a parameter with_operations=True that you execute. The lambda may contain the transfer and be changed whenever you want.
See https://smartpy.io/ide?template=multisig_lambda.py

SmartPy

08 Feb 2025 04:24

sp.transfer(
self.data.entryPointParams,
sp.mutez(0),
sp.contract(sp.record(
gameId = sp.nat,
card = sp.nat,
hash = sp.string
),
self.data.adContract,
"firstCard").unwrap_some()
)

SmartPy

08 Feb 2025 04:21

I think what I "really" want to do is actually impossible, because of how Smart Contract work. I can work around and emulate this action I'm pretty sure, but ideally I wan the following to happen. Contract receives enough data to create an "arbitrary" contract call. It seems like the entrypoint won't be able to handle constructing the call to the contract within the contract as that isn't a 'static' object... I think

SmartPy

07 Feb 2025 20:41

Ah thank you! that's in compiler, so in micheleson it always end up as int or nat! cool, I'll just type everything appropriately (after looking it ) I'm only using nats and not ints! I'm coming from scientific computing in python so I'm used to everything just being a float lol

SmartPy

07 Feb 2025 19:00

Thank you! I was always confused by int_or_nat, seems like it should alwasy be int or nat but not 'either' not sure what it really does but that makes sense, I've been using int_or_nat in a lot of places when I really know if it's an int or nat, but is there a reason to no just use int everywhere even if i know the variable is a nat?

SmartPy

07 Feb 2025 09:26

Here is one minimal example of a contract calling another.
The caller contract has called the receiver in this transaction.

SmartPy

07 Feb 2025 05:13

and this works calling default of B with no params: sp.transfer((), sp.tez(0), sp.contract(sp.unit, self.data.adContract).unwrap_some())

SmartPy

07 Feb 2025 04:18

in test this looks absolutely correct:

SmartPy

07 Feb 2025 04:17

does there need to something 'special' about the 'firstCard' entry point in contract B?

SmartPy

07 Feb 2025 04:10

self.data.adContract = sp.address("KT1RzAPDTcAUvoXAQNhUw5VMqHsby7SbUT5b")

SmartPy

07 Feb 2025 04:09

self.data.entryPointParams = sp.record (
gameId = 0,
hash = 'doadfg',
card = 3143534
)

SmartPy

07 Feb 2025 04:08

I've doubled checked the contract address and spelling of the entry point, the contracta address. trying to call this contract

SmartPy

07 Feb 2025 04:06

>. CONTRACT %firstCard (pair (int %card) (pair (int %gameId) (string %hash))); # option (contract (pair (int %card) (pair (int %gameId) (string %hash)))) : list operation : @parameter%logRequest : @storage
IF_NONE
{
PUSH int 143; # int : list operation : @parameter%logRequest : @storage
FAILWITH; # FAILED
}
{}; # @some : list operation : @parameter%logRequest : @storage

SmartPy

07 Feb 2025 04:05

looking at: https://smartpy.io/templates/inter_contract_calls.py

SmartPy

12 Feb 2025 01:32

Thanks! This is getting closer but when I try it out I get 'existential type error' unless I cast the contractLambda exactly as it should be (not arbitrary or not built outside blockchain/smart contract)

SmartPy

08 Feb 2025 04:24

assuming gameId/card/hash/'firstCard' to be arbitrary

SmartPy

08 Feb 2025 04:24

I guess the question is can a smart contract dynamically make contract calls using somthing like

SmartPy

07 Feb 2025 20:43

Yes, exactly.

> I'm coming from scientific computing in python so I'm used to everything just being a float lol

I understand 🙂 If you specify the types of the storage and transfers, you probably don't need to specify it anywhere else. When you're near the release, you can add types on entry-point parameters to be 100% sure.

SmartPy

07 Feb 2025 20:39

Two things to note: nat prevents any computation to go under zero so if you know you'll always need a number upper zero that provides a type safe security (at compilation time). Second thing, if you interface with a contract that uses nat, you must send nat and vice-versa. int_or_nat is mostly used by the compiler as an intermediate representation. When you compiles, if it cannot determine a constraint the chosen will be int (but you shouldn't rely on this).

SmartPy

07 Feb 2025 09:31

I think the problem is situated here.
The interface of the entrypoint is sp.record(gameId=sp.nat, card=sp.nat, hash=sp.string). Basically you should avoid at maximum sp.int_or_nat, if no clue is found by the compiler it is resolved by sp.int, in your case you want sp.nat as that's what the destination contract is using.

SmartPy

07 Feb 2025 09:07

The syntax changed two years ago, are you using contracts with the old syntax?
Now contracts are defined withing a module, a .spy file or a function with the decorator @sp.module.
I suggest that you read the whole https://smartpy.io/tutorial. Do not hesitate to ask further question.

SmartPy

07 Feb 2025 05:08

anwway any help with trying to debug if it's the calling contract ('A') or called contract ('B') or both that are the problem but I think it's 'A' as 'B' exists

SmartPy

07 Feb 2025 04:17

e.g. when you make a default entrypoint it must pass

SmartPy

07 Feb 2025 04:11

IF_NONE is called, because the contract cant find the other contract or the entry point setup is wrong?

SmartPy

07 Feb 2025 04:09

sp.transfer(
self.data.entryPointParams,
sp.mutez(0),
sp.contract(sp.record(
gameId = sp.int_or_nat,
card = sp.int_or_nat,
hash = sp.string
),
self.data.adContract,
"firstCard").unwrap_some()
)

SmartPy

07 Feb 2025 04:08

https://better-call.dev/ghostnet/KT1RzAPDTcAUvoXAQNhUw5VMqHsby7SbUT5b/interact/firstCard

SmartPy

07 Feb 2025 04:06

so pushing 143 when fails

SmartPy

07 Feb 2025 04:05

> # Note that, as above, we have to call .unwrap_some() in order to open the sp.option[...],
# as the contract may not exist.

SmartPy

07 Feb 2025 03:51

Hey yall does anyone have a minimum working example of a smart contract calling another?
I can get it to work in test scenarios but not on chain