pzbitskiy / tealang Goto Github PK

• gtxns/gtxnsa
• assert
• dig (codegen optimization)
• swap (codegen optimization)
• select (codegen optimization)
• getbit/setbit
• getbyte/setbyte
• pushbytes/pushint (codegen optimization)
• min_balance
• txn fields

Opcodes (these are the ops introduced in v5 but supporting all of them may not be necessary):

• ed25519verify (now available in stateful programs)
• ecdsa_verify, ecdsa_pk_decompress, ecdsa_pk_recover (for k1 curve)
• loads, stores (scratch slot index is top of stack) (scratch space manipulation)
• cover, uncover (stack manipulation)
• extract, extract3, extract_uint16, extract_uint32, extract_uint64
• app_params_get
• log
• itxn_begin, itxn_field, itxn_submit, itxn, itxna (inner transactions)
• txnas, gtxnas, gtxnsas, args (dynamic indexing)

Transaction fields:

• Logs
• NumLogs
• CreatedApplicationID
• CreatedAssetID
• Nonparticipation

Global fields:

• CurrentApplicationAddress
• GroupID

Hello, I was trying to make it do the PRs against this repo, but it came up with a bunch of changes that didn't make sense to me and had no idea what to do with that. So the PRs are against shiqizng's fork. Hope that is workable.

I am not 100% sure but it seems like a number in my scratch space was overwritten in a different function. It says something like let x = thecall() (which always returns 1) and one thing that does is store 6.

But there is another function that always loads from 6, which is supposed to be the parameter of the function. And so the second time I call that function, I always end up with 1 for that number instead of what it was.

Also, random question, is there a way to discard a return value, or not return anything? Because that assignment of x (which I don't use) is what seems to have clobbered my other argument. I am going to try to use a variable declared at the top level or something.

Thanks. By the way, appreciate that you guys have done so many of these v3 v4 updates so quickly.

Hello, so towards the end of my program I am trying to sum 4 numbers. The number was coming out wrong. And I keep trying to do it a slightly different way and getting different answers, some too high and some too low.

These opcodes expose AVM scratch space but tealang uses it for local vars allocation.
The solution might be in a special define shared slots(1, 24) or similar in order to inform tealang compiler do not use these slots for local vars.

Hello, I am guessing you were busy working on AVM 1 or something. Which by the way is one of the biggest updates to a platform I have ever seen. But anyway, are you planning on continuing to work on Tealang and upgrading it to allow the new capabilities?

I heard something about an LLVM project that would make Algorand accessible from lots of languages or something. Don't know if something related to that has now superceded Tealang. But to me Tealang is still the best option for the previous version features.

Use case:
get or getEx return either uint64 or []byte and there is no way to know.

Solution:
Implement "fake" type cast functions uint64 and bytes to switch variable type.

The following should work:

let a = accounts[0].get("key") // unknown type
let b = uint64(a) + 1
a = uint64(a)
let c = a + b

lang feature:

• For loop

txn fields:

• ExtraProgramPages -sz

op codes :

• divmodw - sz
• gload t i - sz (requires exposing store, postponed)
• gloads i -sz
• gaid t
• gaids
• callsub target
• retsub
• shl
• shr
• sqrt
• bitlen
• exp
• expw
• byte-array arithmetics

Sorry to bother you again. I am trying to use apps[0].get or apps[0].getEx. Tried both, not able to check if that storage value matches the txn.Sender.

let ok, creator = apps[0].getEx("Creator")
let sentByCreator = txn.Sender == creator

..gives me:

error at app.tl line 26, col 5 near token "sentByCreator"
    let sentByCreator = txn.Sender == creator
   -----^-----
incompatible types: 'byte[]' vs 'uint64' in expr 'txn.Sender
 == ident creator'

I also tried with apps[0].get() and that one was a similar error except it said it was 'unknown'.

let creator = apps[0].get("Creator")

 let sentByCreator = txn.Sender == creator
   -----^-----
incompatible types: 'byte[]' vs 'unknown' in expr 'txn.Sender
 == ident creator'

Is there a way to indicate whether that app_global_get is supposed to be a byte[] or a uint? Or maybe there is something more basic I am doing wrong.

Thanks for your time.

Initially tealang v1 functions were seen as pure functions since TEAL v1 did not have side effects. TEAL v2+ allows external state writes so one might want a complex state updating function that does not return but has side-effects instead.

Implementation notes:

1. Add void keyword to function declarations
2. Allow return statement (no args)
3. Do not enforce returning a value from void functions
4. return and function x() void become statements from the grammar point of view.

Hello, I tried this out on a simple test program. Had to change something in a shell script from sh to bash and maybe one other thing (remove an extra \n) and could not get the TEAL code output to work without a segfault, but other than that it seemed to work so far for outputting the binary.

If this works, it's like 10 times better than PyTeal in my opinion. Is there a reason I didn't see it mentioned a lot of places in the docs?

Because I have no idea when the LLVM stuff is coming out but until then I am hoping I can get by with TEAL v2 and Tealang.

Opcodes (these are the ops introduced in v6 but supporting all of them may not be necessary):

• acct_params_get
• bsqrt, divw
• itxn_next, gitxn, gitxna (inner transactions)
• gloadss (dynamic indexing) (scratch space access)
• itxnas, gitxnas (dynamic indexing)

Transaction fields:

• LastLog
• StateProofPK

Global fields:

• OpcodeBudget
• CallerApplicationID
• CallerApplicationAddress

Making some notes for issues building, I'm on windows 10 using WSL2 Ubuntu 20.04

Antlr install page is version 4.9.2 now, 4.8 is hardcoded in the Makefile
go:generate directive in stdlib.go specifies sh but that causes issues for me, swapping for $SHELL works
currently stuck on make complaining about not being able to find sodium.h
replacing the go-algorand repo in the go.mod with the local one lets it build but I'm sure that isn't the right way to do it.

I'll update with resolution or any more stumbling blocks and submit a pr if you'd like one.