Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LFE's having a hard time including lager.hrl #99

Closed
oubiwann opened this issue Dec 9, 2014 · 8 comments
Closed

LFE's having a hard time including lager.hrl #99

oubiwann opened this issue Dec 9, 2014 · 8 comments
Labels

Comments

@oubiwann
Copy link
Member

oubiwann commented Dec 9, 2014

Here's the error in the REPL:

> (include-file "deps/lager/include/lager.hrl")
1: Warning: unable to translate macro 'INT_LOG'
exception error: #(unbound_func #(extend-module 1))

Something similar happens when I try to include it in a file and then compile. In the code:

(include-file "deps/lager/include/lager.hrl")

And the compile output:

Compiled src/sample-app-routes.lfe
Compiled src/sample-app-nav.lfe
src/sample-app-gae.lfe:5: Warning: unable to translate macro 'INT_LOG'
Compiled src/sample-app-gae.lfe
Compiled src/sample-app-content.lfe

Here's a copy of the hrl file.

oubiwann added a commit to oubiwann/gae-lfe-yaws-sample-app that referenced this issue Dec 9, 2014
These will be neccessary until this bug is fixed:
 * lfe/lfe#99
@rvirding
Copy link
Member

rvirding commented Dec 9, 2014

Half of the problem has been solved.

  • The #(unbound_func #(extend-module 1)) comes from a new form I have added which the shell didn't recognise and so tried to evaluate it as a function. extend-module allows you to add module information (exports, attributes, etc) not only in the top define-module but in different places as well and the compiler collects and combines them later.
  • The Warning: unable to translate macro 'INT_LOG' I think is because the body of the macro consists of 2 expressions (perfectly legal) and at the moment I only handle macros whose body consists of 1 expression. I will fix it.

I have restructured the lfe repo a little and you can get the latest version with improved code generation in the develop branch. The lfe-dev branch will disappear soon and there will soon be an lfe-dialyzer branch which contains some dialyzer interface modules, and the normal develop.

@oubiwann
Copy link
Member Author

oubiwann commented Dec 9, 2014

Awesome, Robert -- thanks!

@yurrriq
Copy link
Contributor

yurrriq commented Apr 19, 2016

Fixed with logjam, no?

@oubiwann
Copy link
Member Author

@yurrriq Well, logjam offers what is essentially a work-around...

It would be nice if LFE was capable of addressing the two bullet points @rvirding outlined above (and I think it does now).

Maybe the other half of the problem to which Robert referred is the Erlang parse transforms (used by lager) which LFE can't do anything about?

@yurrriq
Copy link
Contributor

yurrriq commented Apr 19, 2016

Ah, right... I wonder how we might support parse transforms. I suppose we might have to transform the parse transforms first. 🙃

@oubiwann
Copy link
Member Author

I just checked, and it's still a problem:

> (include-file "include/lager.hrl")
1: Warning: unable to translate macro 'INT_LOG'
LEVEL2NUM

@yurrriq
Copy link
Contributor

yurrriq commented Apr 19, 2016

😞 Thanks for checking.

@oubiwann oubiwann added the bug label May 7, 2019
@oubiwann
Copy link
Member Author

The logjam work-around uses older lager for logjam + older Erlang versions.

For newer versions of Erlang that support the new logger module, logjam just uses that.

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants