These are chat archives for evhub/coconut

Aug 2016
Chuck Daniels
Aug 18 2016 00:47
@evhub Ah, I had tried that before, but I didn’t consider the ordering of the patterns. However, instead of using @prepattern, I simply reversed the order of the matches, which also makes me wonder why you implemented @prepattern in the first place. Anyway, the following works perfectly (which prints the first 10 primes)! Thanks!
def sieve([head] :: tail) = [head] :: sieve(n for n in tail if n % head)

def sieve((||)) = (||)

primes = count(2) |> sieve
primes$[:10] |> list |*> print

@evhub On a separate not, I think your example in your documentation for Chain may be off. It works, but I’m guessing it’s not what you intended:

def N(n=0):
    return (0,) :: N(n+1) # no infinite loop because :: is lazy

I think you meant return (n,), not return (0,), no?

Evan Hubinger
Aug 18 2016 01:10
@chuckwondo Good catch with the documentation example. If you want, you can submit a PR for that, otherwise I'll just fix it. As for prepattern, you're right that it really isn't that useful, although it's occasionally nice for composing with pattern functions defined in other modules.
Chuck Daniels
Aug 18 2016 13:30
@evhub I’m looking at cocotest further to determine how to add tests for the multi-line “shorthand” function notation that you asked me to add. I need a bit more direction, please. To get me started, how do I run the full suite of tests? I want to make sure I can successfully run all current tests before I attempt to add any new ones. Also, is there a particular reason you have the tests in a separate repo? Seems to make it hard to connect tests to issues created in the coconut repo, no?
Evan Hubinger
Aug 18 2016 17:08
@chuckwondo To run the tests, compile everything with Coconut, then run python and python src/ As for why they're in different repos--honestly, they really shouldn't be. That was how I did it when I was first setting everything up, but really I should move the tests back into the main repository.
Chuck Daniels
Aug 18 2016 17:35

@evhub Cool. I’ll give it a shot. Aside from pulling cocotest into the main repo, would you be up for refactoring the test using a testing framework, such as pytest (with possibly a mix of others, if/where it makes sense)? The reason I suggest this is that long lists of bare asserts may be a bit less descriptive/intuitive. Of course, I don’t want to make it overly complex, but one clear problem is that using bare asserts doesn’t allow for useful reporting/collections of multiple test failures. As soon as one fails, none of the following asserts are executed, so you only see one failure at a time.

Anywho, I’ll start with getting the existing tests running for myself before I do anything else. :-)

Chuck Daniels
Aug 18 2016 18:15

@evhub Coconut failed when compiling cocotest:

(cocotest) $ coconut --force .
Coconut: Compiling       extras.coco ...
Coconut: Compiled to .
Coconut: Compiling       runner.coco ...
Coconut: Compiled to .
Coconut: Compiling       __init__.coco ...
Coconut: Compiled to .
Coconut: Compiling       main.coco ...
CoconutParseError: parsing failed (line 93)
    global (glob_a, glob_b) = (x, x)

This happens with Python 2.7 and Python 3.5.

@evhub Also, there appear to be undocumented dependencies, as there is no requirements file in the repo, but I got the following when attempting to run python (yes, I tried to run even though the full compilation failed, as shown in the previous message):

(cocotest) $ python
Traceback (most recent call last):
  File "", line 30, in <module>
    from coconut.icoconut import CoconutKernel
  File "/Users/charlie/miniconda3/envs/cocotest/lib/python2.7/site-packages/coconut/icoconut/", line 19, in <module>
    from .root import *
  File "/Users/charlie/miniconda3/envs/cocotest/lib/python2.7/site-packages/coconut/icoconut/", line 24, in <module>
    from ipykernel.kernelbase import Kernel
ImportError: No module named ipykernel.kernelbase

What are all of the dependencies?

Evan Hubinger
Aug 18 2016 20:50
@chuckwondo Yeah, I really need to document this process better... the first error will go away if you use develop Coconut instead of master Coconut, since that test is for in-line global / nonlocal statements, support for which is only in develop right now. The second error is because tests Coconut's jupyter kernel, which requires jupyter to be installed. And I also completely agree about using pytest instead of just assert.
The whole testing process works, but it's all kind of a mess right now. Especially since, instead of using a Makefile or tox or anything to determine what commands to run, I generate them using coconut-travis-generator, which is really derpy.
Chuck Daniels
Aug 18 2016 22:08
@evhub Makes sense. I’m not familiar with how to install a locally developed Python package. I’m fine with using git, but once I checkout the develop branch and merge from upstream, how do I build and install the package?