I believe that I maybe found a bug in the compiler.

Steps to reproduce:

cat > puzzle.cl <<EOF
(mod params
 (defun ident (arg)
  (f (list arg))
 )

 (ident (ident params))
)
EOF

run puzzle.cl

Expected result:

I expect a CLVM puzzle to be written to stdout, which would output its solution when passed to brun (i.e. "identity puzzle").

Actual results:

The run command fails with the following message:

FAIL: first of non-cons 1

Some more insight:

When I modify the puzzle in either one of the following ways, then it translates and the resulting CLVM behaves as expected:

1. (f (list arg)) -> (f arg)
2. (f (list arg)) -> (list arg)
3. (f (list arg)) -> (f (f arg))
4. (f (list arg)) -> (list (list arg))
5. (f (list arg)) -> (list (f arg))
6. (ident (ident params)) -> (ident params)
7. (mod params ...) -> (mod (params) ...)

Please note that the documentation admits any of the following possibilities:

• (mod params ...)
• (mod (param_one param_two) ...)
• (mod ((param)) ...)

Quoting https://chialisp.com/docs/high_level_lang#squaring-a-list:

You can name each parameter in a list or you can name the list itself. This works at any place where you name parameters, and allows you to handle lists where you aren't sure of the size.

Hi,

This isn't really a bug but I recently had some issues getting a functional clvm environment on my server running Ubuntu 18.04 and I thought that I should share the steps that I had to follow here.

First I've wasted a lot of time trying to make things work without really checking the version of Python I was using. Turns out that I was using python 3.6 and that IIUC for the blspy dependency to be resolved properly you need at least 3.7.

Then I still had a few issues, here's the commands I had to run:

git clone https://github.com/Chia-Network/clvm_tools.git
cd clvm_tools
python3 -m venv clvm_env
. ./clvm_env/bin/activate
pip install -e .
git clone https://github.com/Chia-Network/clvm.git
cd clvm
python3 -m venv venv
. ./venv/bin/activate
pip install -e '.[dev]'
cd ..
run '(mod ARGUMENT (+ ARGUMENT 3))'

I could probably create only one venv but once I got it to work I focused on playing with Chialisp :).

Let me know if you want me to try something, I really believe that providing some really clear setup instructions that work on all platforms will help with the adoption of Chialisp.

Thanks

After I installed and try simple cmd. I got this error. any idea : D

Here is a patch that fixes a compile issue that makes it not able to find clvm_tools in chia-blockchain-1.1.6:

--- pyproject.toml.orig	2021-05-30 14:12:11.254703000 -0400
+++ pyproject.toml	2021-05-30 14:11:35.404486000 -0400
@@ -3,5 +3,5 @@
 requires = ["setuptools>=42", "wheel", "setuptools_scm[toml]>=3.4"]

 [tool.setuptools_scm]
-fallback_version = "unknown"
+fallback_version = "0.4.3"
 local_scheme = "no-local-version"

I am trying to build an RPM from this but see no tar.gz file on pypi. Can you please upload the source tarball to pypi ?

warning: Downloading https://pypi.io/packages/source/c/clvm_tools/clvm_tools-0.4.3.tar.gz
curl: (22) The requested URL returned error: 404
error: Couldn't download https://pypi.io/packages/source/c/clvm_tools/clvm_tools-0.4.3.tar.gz

https://pypi.org/project/clvm-tools/#files only shows a .whl file.

$python3 setup.py --help-commands | grep sdist
sdist create a source distribution (tarball, zip file, etc.)

so if you can first generate this sdist tar ball then upload it

stage_0

def run_program(
    program,
    args,
    operator_lookup=OPERATOR_LOOKUP,    # <== operator_lookup can be changed by parameter
    max_cost=None,
    pre_eval_f=None,
    strict=False,
):
    ...

stage_1

class RunProgram:
    def __init__(self):
        operator_lookup = OperatorDict(OPERATOR_LOOKUP)
        operator_lookup.update((k.encode("utf8"), v) for (k, v) in BINDINGS.items())
        self.operator_lookup = operator_lookup

    # __call__  does not accept `operator_lookup` here. So `operator_lookup` can't be changed outside by parameter.
    def __call__(self, program, args, max_cost=None, pre_eval_f=None, strict=False):
        return run_program_0(
            program,
            args,
            operator_lookup=self.operator_lookup,
            max_cost=max_cost,
            pre_eval_f=pre_eval_f,
            strict=strict,
        )

stage_2

    # As well as stage_0, operator_lookup can be changed by parameter, but this is different from stage_1.
    def run_program(
        program, args, operator_lookup=operator_lookup, max_cost=None, pre_eval_f=None, strict=False
    ):
        return run_program_0(
            program,
            args,
            operator_lookup=operator_lookup,
            max_cost=max_cost,
            pre_eval_f=pre_eval_f,
            strict=strict
        )

The strangeness comes from the facts that:
stage_0: run_program accepts operator_lookup by parameter. It can be modified from outside by parameter.
stage_1: run_program DOES NOT accepts operator_lookup by parameter. It cannot be modified from outside by parameter.
stage_2: Does not inherit stage_1 spec. Equipping stage_0 style argument.

I feel inconsistency of run_program specification between stage_1 and stage_2.
It is clean if stage_1 also accepts operator_lookup parameter as well as other stages, or cut operator_lookup parameter from stage_2 as well as stage_1.

I don't know whether accepting operator_lookup parameter is important or not.
Maybe the best advise to my feeling is to just ignore and walk away.

But I want to hear from original author/developer, about whether this is important for entire specs or just a tiny small thing I should pass through.

Possible impact

In clvm_tools/cmds.py, user can change stage by specifying -s or --stage option.
And I found the code below, which switches run_program implemantation according to -s option.

    if hasattr(args.stage, "run_program_for_search_paths"):
        run_program = args.stage.run_program_for_search_paths(args.include)
    else:
        run_program = args.stage.run_program

And later, it is invoked without operator_lookup parameter.

            cost, result = run_program(
                run_script, input_sexp, max_cost=max_cost, pre_eval_f=pre_eval_f, strict=args.strict)

So , in current clvm_tools/cmds.py there is no issue at all.

But what if run_program above is invoked with operator_lookup parameter in future?
If it is then, it becomse that stage_1 implementation of run_program ignores operator_lookup while stage_2's impl doesn't.
Is this expected behaviour?

Thanks.

I write a simple contract want to have a test , but I can't find the docs how to deploy it to the blockchain

hi @matt-o-how
there was a workshop at Jul 17, 2020 about Decentralized Identity in chia with Matt Howard , but I cannot find any further news about this topic .

is it possible to use chia block chain as a DIDs method ?
is there any progress or implementation in this field?

thank you

How to reproduce the error

n = NodePath(-129)

Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "c:\users\chiaminejp\pycharmprojects\clvm_tools\clvm_tools\NodePath.py", line 67, in __init__
    blob = index.to_bytes(byte_count, byteorder="big", signed=True)
OverflowError: int too big to convert

NodePath(-256)

n = NodePath(-256)
str(n)

'NodePath: 65280'

Test environment

How to reproduce

# powershell
C:\Users\XXX\PycharmProjects\> git clone https://github.com/Chia-Network/clvm_tools
C:\Users\XXX\PycharmProjects\> cd clvm_tools
C:\Users\XXX\PycharmProjects\clvm_tools> python3 -m venv ven
C:\Users\XXX\PycharmProjects\clvm_tools> . venv\Scripts\activate.bat
C:\Users\XXX\PycharmProjects\clvm_tools> pip install -e .
C:\Users\XXX\PycharmProjects\clvm_tools> pip install clvm_rs
C:\Users\XXX\PycharmProjects\clvm_tools> python costs\generate-benchmark.py
C:\Users\XXX\PycharmProjects\clvm_tools> brun .\test-programs\all\all_nest-1-962.clvm
1
C:\Users\XXX\PycharmProjects\clvm_tools> echo $LastExitCode
0
C:\Users\XXX\PycharmProjects\clvm_tools> brun .\test-programs\all\all_nest-1-1002.clvm
C:\Users\XXX\PycharmProjects\clvm_tools> echo $LastExitCode
-1073741571

Maybe sys.setrecursionlimit(20000) does not increase stack size, and AFIK there are no easy way to increase the size on Windows.

It is highly unlikely that such a deep nested clvm program is used on coin spend, but at least you should put this fact into your brain.

But there is another approach. Replace recursive function call into loop. This can utilize heap memory instead of stack memory.
If you're interested, I already wrote such a conversion in my javascript implementation of clvm_tools.
Here is my work

In nodejs, it failed to run all_nest-1-1502.clvm due to Maximum call stack size exceeded error.
So I really tried hard to convert the recursion into loop in order to reduce stack memory consumed.
Fortunately as I develop javascript version of clvm_tools really looking like Python's code, you can also apply my work back into the Python's clvm_tools