Add Core Erlang support. by cmeiklejohn · Pull Request #384 · basho/rebar

cmeiklejohn · 2013-11-04T20:34:22Z

Support the compilation of .core files in the directory for applications
which use source code authored directly in Core Erlang.

Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

jaredmorrow · 2013-11-08T15:08:24Z

@cmeiklejohn what do you think about attempting to make a unit test for this?

cmeiklejohn · 2013-11-08T17:43:51Z

I pushed a test that writes out a Erlang eunit test and verifies that the Core Erlang has been compiled correctly. However, when running eunit directly it appears to be looking for a test module for the Core file, which isn't produced. It appears that this is a problem in eunit, but I'm not 100% sure. Any thoughts, @psyeugenic?

cmeiklejohn · 2013-11-18T19:09:58Z

@richcarl Any thoughts here?

richcarl · 2013-11-21T13:58:46Z

If you tell eunit to test a module x, it will also look for a module x_tests, but if it doesn't find one it should not be a problem as it should simply run only the test functions found in x itself. What's happening in your case?

cmeiklejohn · 2013-11-21T16:38:17Z

it's looking for a test module generated from the compilation of the core erlang module -- which it doesn't find and I gives me the following output:

myapp_mymod_tests: myfunc_core_test...[0.001 s] ok
[done in 0.007 s]
[done in 0.010 s]
undefined *** test module not found ***
**myapp_mycoremod
=======================================================
Failed: 0. Skipped: 0. Passed: 3.
One or more tests were cancelled.
ERROR: One or more eunit tests failed.

richcarl · 2013-11-22T20:55:04Z

I haven't had time to check out the code and try it, but it seems pretty strange. Somehow eunit gets passed the atom 'myapp_mycoremod' as a test to be executed, perhaps from a generator function. But I can't see anything in your commit that would cause that to happen.

richcarl · 2013-11-23T20:42:21Z

Tried to see what's going on, but I think it's rebar scanning for files on its own, and somehow ends up finding this module although it for some reason can't be found in the code path when it tries to run it. Perhaps a race condition where the teardown has already removed the .beam file when it comes to the point where it tries to run the tests for the module that it found.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Properly detecting change meant moving from rebar_base_compiler, so it also meant processing protocol buffer files in sequence instead of in parallel.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Use the rebar_base_compiler's ability to specify both source and target file names, to be able to also support prefixes. This also introduces a call to gpb_compile:format_error, so the xref recipe needs to be updated to ignore it, to avoid false errors.

cmeiklejohn · 2013-11-04T20:34:22Z

Support the compilation of .core files in the directory for applications
which use source code authored directly in Core Erlang.

Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

jaredmorrow · 2013-11-08T15:08:24Z

@cmeiklejohn what do you think about attempting to make a unit test for this?

cmeiklejohn · 2013-11-08T17:43:51Z

I pushed a test that writes out a Erlang eunit test and verifies that the Core Erlang has been compiled correctly. However, when running eunit directly it appears to be looking for a test module for the Core file, which isn't produced. It appears that this is a problem in eunit, but I'm not 100% sure. Any thoughts, @psyeugenic?

cmeiklejohn · 2013-11-18T19:09:58Z

@richcarl Any thoughts here?

richcarl · 2013-11-21T13:58:46Z

If you tell eunit to test a module x, it will also look for a module x_tests, but if it doesn't find one it should not be a problem as it should simply run only the test functions found in x itself. What's happening in your case?

cmeiklejohn · 2013-11-21T16:38:17Z

it's looking for a test module generated from the compilation of the core erlang module -- which it doesn't find and I gives me the following output:

myapp_mymod_tests: myfunc_core_test...[0.001 s] ok
[done in 0.007 s]
[done in 0.010 s]
undefined *** test module not found ***
**myapp_mycoremod
=======================================================
Failed: 0. Skipped: 0. Passed: 3.
One or more tests were cancelled.
ERROR: One or more eunit tests failed.

richcarl · 2013-11-22T20:55:04Z

I haven't had time to check out the code and try it, but it seems pretty strange. Somehow eunit gets passed the atom 'myapp_mycoremod' as a test to be executed, perhaps from a generator function. But I can't see anything in your commit that would cause that to happen.

richcarl · 2013-11-23T20:42:21Z

Tried to see what's going on, but I think it's rebar scanning for files on its own, and somehow ends up finding this module although it for some reason can't be found in the code path when it tries to run it. Perhaps a race condition where the teardown has already removed the .beam file when it comes to the point where it tries to run the tests for the module that it found.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Properly detecting change meant moving from rebar_base_compiler, so it also meant processing protocol buffer files in sequence instead of in parallel.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Use the rebar_base_compiler's ability to specify both source and target file names, to be able to also support prefixes. This also introduces a call to gpb_compile:format_error, so the xref recipe needs to be updated to ignore it, to avoid false errors.

cmeiklejohn · 2013-11-04T20:34:22Z

Support the compilation of .core files in the directory for applications
which use source code authored directly in Core Erlang.

Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

jaredmorrow · 2013-11-08T15:08:24Z

@cmeiklejohn what do you think about attempting to make a unit test for this?

cmeiklejohn · 2013-11-08T17:43:51Z

I pushed a test that writes out a Erlang eunit test and verifies that the Core Erlang has been compiled correctly. However, when running eunit directly it appears to be looking for a test module for the Core file, which isn't produced. It appears that this is a problem in eunit, but I'm not 100% sure. Any thoughts, @psyeugenic?

cmeiklejohn · 2013-11-18T19:09:58Z

@richcarl Any thoughts here?

richcarl · 2013-11-21T13:58:46Z

If you tell eunit to test a module x, it will also look for a module x_tests, but if it doesn't find one it should not be a problem as it should simply run only the test functions found in x itself. What's happening in your case?

cmeiklejohn · 2013-11-21T16:38:17Z

it's looking for a test module generated from the compilation of the core erlang module -- which it doesn't find and I gives me the following output:

myapp_mymod_tests: myfunc_core_test...[0.001 s] ok
[done in 0.007 s]
[done in 0.010 s]
undefined *** test module not found ***
**myapp_mycoremod
=======================================================
Failed: 0. Skipped: 0. Passed: 3.
One or more tests were cancelled.
ERROR: One or more eunit tests failed.

richcarl · 2013-11-22T20:55:04Z

I haven't had time to check out the code and try it, but it seems pretty strange. Somehow eunit gets passed the atom 'myapp_mycoremod' as a test to be executed, perhaps from a generator function. But I can't see anything in your commit that would cause that to happen.

richcarl · 2013-11-23T20:42:21Z

Tried to see what's going on, but I think it's rebar scanning for files on its own, and somehow ends up finding this module although it for some reason can't be found in the code path when it tries to run it. Perhaps a race condition where the teardown has already removed the .beam file when it comes to the point where it tries to run the tests for the module that it found.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Properly detecting change meant moving from rebar_base_compiler, so it also meant processing protocol buffer files in sequence instead of in parallel.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Use the rebar_base_compiler's ability to specify both source and target file names, to be able to also support prefixes. This also introduces a call to gpb_compile:format_error, so the xref recipe needs to be updated to ignore it, to avoid false errors.

cmeiklejohn · 2013-11-04T20:34:22Z

Support the compilation of .core files in the directory for applications
which use source code authored directly in Core Erlang.

Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

jaredmorrow · 2013-11-08T15:08:24Z

@cmeiklejohn what do you think about attempting to make a unit test for this?

cmeiklejohn · 2013-11-08T17:43:51Z

I pushed a test that writes out a Erlang eunit test and verifies that the Core Erlang has been compiled correctly. However, when running eunit directly it appears to be looking for a test module for the Core file, which isn't produced. It appears that this is a problem in eunit, but I'm not 100% sure. Any thoughts, @psyeugenic?

cmeiklejohn · 2013-11-18T19:09:58Z

@richcarl Any thoughts here?

richcarl · 2013-11-21T13:58:46Z

If you tell eunit to test a module x, it will also look for a module x_tests, but if it doesn't find one it should not be a problem as it should simply run only the test functions found in x itself. What's happening in your case?

cmeiklejohn · 2013-11-21T16:38:17Z

it's looking for a test module generated from the compilation of the core erlang module -- which it doesn't find and I gives me the following output:

myapp_mymod_tests: myfunc_core_test...[0.001 s] ok
[done in 0.007 s]
[done in 0.010 s]
undefined *** test module not found ***
**myapp_mycoremod
=======================================================
Failed: 0. Skipped: 0. Passed: 3.
One or more tests were cancelled.
ERROR: One or more eunit tests failed.

richcarl · 2013-11-22T20:55:04Z

I haven't had time to check out the code and try it, but it seems pretty strange. Somehow eunit gets passed the atom 'myapp_mycoremod' as a test to be executed, perhaps from a generator function. But I can't see anything in your commit that would cause that to happen.

richcarl · 2013-11-23T20:42:21Z

Tried to see what's going on, but I think it's rebar scanning for files on its own, and somehow ends up finding this module although it for some reason can't be found in the code path when it tries to run it. Perhaps a race condition where the teardown has already removed the .beam file when it comes to the point where it tries to run the tests for the module that it found.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Properly detecting change meant moving from rebar_base_compiler, so it also meant processing protocol buffer files in sequence instead of in parallel.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Use the rebar_base_compiler's ability to specify both source and target file names, to be able to also support prefixes. This also introduces a call to gpb_compile:format_error, so the xref recipe needs to be updated to ignore it, to avoid false errors.

cmeiklejohn · 2013-11-04T20:34:22Z

Support the compilation of .core files in the directory for applications
which use source code authored directly in Core Erlang.

Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

jaredmorrow · 2013-11-08T15:08:24Z

@cmeiklejohn what do you think about attempting to make a unit test for this?

cmeiklejohn · 2013-11-08T17:43:51Z

I pushed a test that writes out a Erlang eunit test and verifies that the Core Erlang has been compiled correctly. However, when running eunit directly it appears to be looking for a test module for the Core file, which isn't produced. It appears that this is a problem in eunit, but I'm not 100% sure. Any thoughts, @psyeugenic?

cmeiklejohn · 2013-11-18T19:09:58Z

@richcarl Any thoughts here?

richcarl · 2013-11-21T13:58:46Z

If you tell eunit to test a module x, it will also look for a module x_tests, but if it doesn't find one it should not be a problem as it should simply run only the test functions found in x itself. What's happening in your case?

cmeiklejohn · 2013-11-21T16:38:17Z

it's looking for a test module generated from the compilation of the core erlang module -- which it doesn't find and I gives me the following output:

myapp_mymod_tests: myfunc_core_test...[0.001 s] ok
[done in 0.007 s]
[done in 0.010 s]
undefined *** test module not found ***
**myapp_mycoremod
=======================================================
Failed: 0. Skipped: 0. Passed: 3.
One or more tests were cancelled.
ERROR: One or more eunit tests failed.

richcarl · 2013-11-22T20:55:04Z

I haven't had time to check out the code and try it, but it seems pretty strange. Somehow eunit gets passed the atom 'myapp_mycoremod' as a test to be executed, perhaps from a generator function. But I can't see anything in your commit that would cause that to happen.

richcarl · 2013-11-23T20:42:21Z

Tried to see what's going on, but I think it's rebar scanning for files on its own, and somehow ends up finding this module although it for some reason can't be found in the code path when it tries to run it. Perhaps a race condition where the teardown has already removed the .beam file when it comes to the point where it tries to run the tests for the module that it found.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Properly detecting change meant moving from rebar_base_compiler, so it also meant processing protocol buffer files in sequence instead of in parallel.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Use the rebar_base_compiler's ability to specify both source and target file names, to be able to also support prefixes. This also introduces a call to gpb_compile:format_error, so the xref recipe needs to be updated to ignore it, to avoid false errors.

cmeiklejohn · 2013-11-04T20:34:22Z

Support the compilation of .core files in the directory for applications
which use source code authored directly in Core Erlang.

Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

jaredmorrow · 2013-11-08T15:08:24Z

@cmeiklejohn what do you think about attempting to make a unit test for this?

cmeiklejohn · 2013-11-08T17:43:51Z

I pushed a test that writes out a Erlang eunit test and verifies that the Core Erlang has been compiled correctly. However, when running eunit directly it appears to be looking for a test module for the Core file, which isn't produced. It appears that this is a problem in eunit, but I'm not 100% sure. Any thoughts, @psyeugenic?

cmeiklejohn · 2013-11-18T19:09:58Z

@richcarl Any thoughts here?

richcarl · 2013-11-21T13:58:46Z

If you tell eunit to test a module x, it will also look for a module x_tests, but if it doesn't find one it should not be a problem as it should simply run only the test functions found in x itself. What's happening in your case?

cmeiklejohn · 2013-11-21T16:38:17Z

it's looking for a test module generated from the compilation of the core erlang module -- which it doesn't find and I gives me the following output:

myapp_mymod_tests: myfunc_core_test...[0.001 s] ok
[done in 0.007 s]
[done in 0.010 s]
undefined *** test module not found ***
**myapp_mycoremod
=======================================================
Failed: 0. Skipped: 0. Passed: 3.
One or more tests were cancelled.
ERROR: One or more eunit tests failed.

richcarl · 2013-11-22T20:55:04Z

I haven't had time to check out the code and try it, but it seems pretty strange. Somehow eunit gets passed the atom 'myapp_mycoremod' as a test to be executed, perhaps from a generator function. But I can't see anything in your commit that would cause that to happen.

richcarl · 2013-11-23T20:42:21Z

Tried to see what's going on, but I think it's rebar scanning for files on its own, and somehow ends up finding this module although it for some reason can't be found in the code path when it tries to run it. Perhaps a race condition where the teardown has already removed the .beam file when it comes to the point where it tries to run the tests for the module that it found.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Properly detecting change meant moving from rebar_base_compiler, so it also meant processing protocol buffer files in sequence instead of in parallel.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Use the rebar_base_compiler's ability to specify both source and target file names, to be able to also support prefixes. This also introduces a call to gpb_compile:format_error, so the xref recipe needs to be updated to ignore it, to avoid false errors.

cmeiklejohn · 2013-11-04T20:34:22Z

Support the compilation of .core files in the directory for applications
which use source code authored directly in Core Erlang.

Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

jaredmorrow · 2013-11-08T15:08:24Z

@cmeiklejohn what do you think about attempting to make a unit test for this?

cmeiklejohn · 2013-11-08T17:43:51Z

I pushed a test that writes out a Erlang eunit test and verifies that the Core Erlang has been compiled correctly. However, when running eunit directly it appears to be looking for a test module for the Core file, which isn't produced. It appears that this is a problem in eunit, but I'm not 100% sure. Any thoughts, @psyeugenic?

cmeiklejohn · 2013-11-18T19:09:58Z

@richcarl Any thoughts here?

richcarl · 2013-11-21T13:58:46Z

If you tell eunit to test a module x, it will also look for a module x_tests, but if it doesn't find one it should not be a problem as it should simply run only the test functions found in x itself. What's happening in your case?

cmeiklejohn · 2013-11-21T16:38:17Z

it's looking for a test module generated from the compilation of the core erlang module -- which it doesn't find and I gives me the following output:

myapp_mymod_tests: myfunc_core_test...[0.001 s] ok
[done in 0.007 s]
[done in 0.010 s]
undefined *** test module not found ***
**myapp_mycoremod
=======================================================
Failed: 0. Skipped: 0. Passed: 3.
One or more tests were cancelled.
ERROR: One or more eunit tests failed.

richcarl · 2013-11-22T20:55:04Z

I haven't had time to check out the code and try it, but it seems pretty strange. Somehow eunit gets passed the atom 'myapp_mycoremod' as a test to be executed, perhaps from a generator function. But I can't see anything in your commit that would cause that to happen.

richcarl · 2013-11-23T20:42:21Z

Tried to see what's going on, but I think it's rebar scanning for files on its own, and somehow ends up finding this module although it for some reason can't be found in the code path when it tries to run it. Perhaps a race condition where the teardown has already removed the .beam file when it comes to the point where it tries to run the tests for the module that it found.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Properly detecting change meant moving from rebar_base_compiler, so it also meant processing protocol buffer files in sequence instead of in parallel.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Use the rebar_base_compiler's ability to specify both source and target file names, to be able to also support prefixes. This also introduces a call to gpb_compile:format_error, so the xref recipe needs to be updated to ignore it, to avoid false errors.

cmeiklejohn · 2013-11-04T20:34:22Z

Support the compilation of .core files in the directory for applications
which use source code authored directly in Core Erlang.

Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

jaredmorrow · 2013-11-08T15:08:24Z

@cmeiklejohn what do you think about attempting to make a unit test for this?

cmeiklejohn · 2013-11-08T17:43:51Z

I pushed a test that writes out a Erlang eunit test and verifies that the Core Erlang has been compiled correctly. However, when running eunit directly it appears to be looking for a test module for the Core file, which isn't produced. It appears that this is a problem in eunit, but I'm not 100% sure. Any thoughts, @psyeugenic?

cmeiklejohn · 2013-11-18T19:09:58Z

@richcarl Any thoughts here?

richcarl · 2013-11-21T13:58:46Z

If you tell eunit to test a module x, it will also look for a module x_tests, but if it doesn't find one it should not be a problem as it should simply run only the test functions found in x itself. What's happening in your case?

cmeiklejohn · 2013-11-21T16:38:17Z

it's looking for a test module generated from the compilation of the core erlang module -- which it doesn't find and I gives me the following output:

myapp_mymod_tests: myfunc_core_test...[0.001 s] ok
[done in 0.007 s]
[done in 0.010 s]
undefined *** test module not found ***
**myapp_mycoremod
=======================================================
Failed: 0. Skipped: 0. Passed: 3.
One or more tests were cancelled.
ERROR: One or more eunit tests failed.

richcarl · 2013-11-22T20:55:04Z

I haven't had time to check out the code and try it, but it seems pretty strange. Somehow eunit gets passed the atom 'myapp_mycoremod' as a test to be executed, perhaps from a generator function. But I can't see anything in your commit that would cause that to happen.

richcarl · 2013-11-23T20:42:21Z

Tried to see what's going on, but I think it's rebar scanning for files on its own, and somehow ends up finding this module although it for some reason can't be found in the code path when it tries to run it. Perhaps a race condition where the teardown has already removed the .beam file when it comes to the point where it tries to run the tests for the module that it found.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Properly detecting change meant moving from rebar_base_compiler, so it also meant processing protocol buffer files in sequence instead of in parallel.

For protocol buffer files, when there were gpb options to alter the module name with prefix or suffix, recompilation was not properly detected. This is now fixed. (Issue basho#384). Use the rebar_base_compiler's ability to specify both source and target file names, to be able to also support prefixes. This also introduces a call to gpb_compile:format_error, so the xref recipe needs to be updated to ignore it, to avoid false errors.

Add Core Erlang support.
b2b6480
Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

cmeiklejohn mentioned this pull request Nov 4, 2013
Add Core Erlang support. rebar/rebar#161
Closed

Don't subdirectory beams.
d118a19
In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

Add Core Erlang test.
d9cbd78

Add Core Erlang support.
b2b6480
Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

cmeiklejohn mentioned this pull request Nov 4, 2013
Add Core Erlang support. rebar/rebar#161
Closed

Don't subdirectory beams.
d118a19
In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

Add Core Erlang test.
d9cbd78

Add Core Erlang support.
b2b6480
Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

cmeiklejohn mentioned this pull request Nov 4, 2013
Add Core Erlang support. rebar/rebar#161
Closed

Don't subdirectory beams.
d118a19
In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

Add Core Erlang test.
d9cbd78

Add Core Erlang support.
b2b6480
Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

cmeiklejohn mentioned this pull request Nov 4, 2013
Add Core Erlang support. rebar/rebar#161
Closed

Don't subdirectory beams.
d118a19
In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

Add Core Erlang test.
d9cbd78

Add Core Erlang support.
b2b6480
Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

cmeiklejohn mentioned this pull request Nov 4, 2013
Add Core Erlang support. rebar/rebar#161
Closed

Don't subdirectory beams.
d118a19
In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

Add Core Erlang test.
d9cbd78

Add Core Erlang support.
b2b6480
Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

cmeiklejohn mentioned this pull request Nov 4, 2013
Add Core Erlang support. rebar/rebar#161
Closed

Don't subdirectory beams.
d118a19
In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

Add Core Erlang test.
d9cbd78

Add Core Erlang support.
b2b6480
Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

cmeiklejohn mentioned this pull request Nov 4, 2013
Add Core Erlang support. rebar/rebar#161
Closed

Don't subdirectory beams.
d118a19
In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

Add Core Erlang test.
d9cbd78

Add Core Erlang support.
b2b6480
Support the compilation of .core files in the directory for applications which use source code authored directly in Core Erlang.

cmeiklejohn mentioned this pull request Nov 4, 2013
Add Core Erlang support. rebar/rebar#161
Closed

Don't subdirectory beams.
d118a19
In the case of a beam called Coq.Arith.EqNat, which will be called directly in the Core Erlang like call 'Coq.Arith.EqNat':'beq_nat', don't put into a subdirectory or the emulator will not be able to find it.

Add Core Erlang test.
d9cbd78

Uh oh!

Conversation

cmeiklejohn commented Nov 4, 2013

Uh oh!

jaredmorrow commented Nov 8, 2013

Uh oh!

cmeiklejohn commented Nov 8, 2013

Uh oh!

cmeiklejohn commented Nov 18, 2013

Uh oh!

richcarl commented Nov 21, 2013

Uh oh!

cmeiklejohn commented Nov 21, 2013

Uh oh!

richcarl commented Nov 22, 2013

Uh oh!

richcarl commented Nov 23, 2013

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

cmeiklejohn commented Nov 4, 2013

Uh oh!

jaredmorrow commented Nov 8, 2013

Uh oh!

cmeiklejohn commented Nov 8, 2013

Uh oh!

cmeiklejohn commented Nov 18, 2013

Uh oh!

richcarl commented Nov 21, 2013

Uh oh!

cmeiklejohn commented Nov 21, 2013

Uh oh!

richcarl commented Nov 22, 2013

Uh oh!

richcarl commented Nov 23, 2013

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

cmeiklejohn commented Nov 4, 2013

Uh oh!

jaredmorrow commented Nov 8, 2013

Uh oh!

cmeiklejohn commented Nov 8, 2013

Uh oh!

cmeiklejohn commented Nov 18, 2013

Uh oh!

richcarl commented Nov 21, 2013

Uh oh!

cmeiklejohn commented Nov 21, 2013

Uh oh!

richcarl commented Nov 22, 2013

Uh oh!

richcarl commented Nov 23, 2013

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation