Library updates, etc.

[Duncan McGreggor]

Hey all,

After Robert released LFE v0.10.0, I updated the most commonly used LFE libraries (ltest, lutil, lcfg, clj, and lfest -- with an additional community fix for lfest from Yuu Shimizu). After some positive prompting from Sean Jensen-Grey, I'm also trying to bring lfetool up to date.

This last has been a bit tricky, as one of the key supporting functions uses a fairly involved awk command (community-contributed), and it's not working on the latest Ubuntu. This is preventing the longer files from being base64 encoded.

The rest of the lfetool updates are coming along, though -- it bootstraps all of the latest releases into ~/.lfe/lib (I still need to update the rebar templates so that new projects use the latest, though).

I mention this in case you were wondering why lfetool was slow to catch up to the latest LFE release :-)

d

P.S. This has inevitably made me long for getting the rebar3 stuff sorted out; still haven't had time to get back to solving the problem there, with compiling plugin dependencies when the rebar3 plugin has been written in LFE ...

[Matthew Fitzpatrick]

Hey Duncan,

The mention of lfetool caught my eye. I'm trying to integrate some ltests into an existing vanilla erlang project that's been setup with rebar2. I was trying to figure out how one would execute those ltests from rebar. Do you know of anyway to run them via rebar? Or is there a different way to run them? I'm not having much success with any path I've attempted thus far.

[Duncan McGreggor]

Yeah, I just read your other email. I don't have super-great news for you, but perhaps some information that might help you wrap your head around how things work and what's possible.

The ltest testing framework actually uses Erlang behaviours to classify tests as unit, integration, or system. Neither rebar nor EUnit itself make this distinction. As such, lfetool is required to run these tests separately (which is usually what you want; less frequently you want to run all suites, e.g., prior to merging features or prior to deployments).

lfetool runs the tests by eval'ing Erlang from the command line which
1) gets the list of the desired tests (e.g., ltest:get-unit-beams, ltest:get-integration-beams)
2) runs the desired tests by calling eunit:tests with them as passed parameters

If you don't mind having two tools to run your tests, the easiest thing would be to use make or a shell script to run both rebar test and lfetool test. If it is absolutely essential that you not have two tools, I think the only way around this is to write a rebar2 plugin that does what lfetool does.

Hope this is helpful!

d

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

[Matthew Fitzpatrick]

Hey Duncan,

Thanks for the quick reply, sorry for the duplicate messaging.

Thanks for the information, its definitely enlightening.

Not a huge problem at all to depend on two tools. Like you suggested, a wrapper script would be an easy solution to make sure no one has to remember to type two commands to get a full test run.

A followup question: Is there a better way to inject LFE into a vanilla Erlang project than the approach I've taken? I'm kind of just ham-fisting my way through it seeing what works/what doesn't. 

[Duncan McGreggor]

On 10/16/2015 10:06 PM, Matthew Fitzpatrick wrote:

Hey Duncan,

Thanks for the quick reply, sorry for the duplicate messaging.

Didn't even register as a problem (I tend to write emails like I'm musing aloud ... slouched in a chair. 'Cause that's usually what's happening ;-)).

Thanks for the information, its definitely enlightening.

Not a huge problem at all to depend on two tools. Like you suggested, a wrapper script would be an easy solution to make sure no one has to remember to type two commands to get a full test run.

*nods*

A followup question: Is there a better way to inject LFE into a vanilla Erlang project than the approach I've taken? I'm kind of just ham-fisting my way through it seeing what works/what doesn't.

Obligatory mumbled comment with a cough: "Just rewrite it all in LFE :-)"

Seriously though, it's a matter of degree. Erlang + :LFE with just some LFE thrown in is dirt-simple: just adding rvirding/lfe in rebar.config. Once you've added unit tests in LFE, you've got two deps (and maybe more) plus either a hand-tooled Makefile or lfetool (or both). If you need to work around rebar2 quirks, oy umight have to do some fancy dancing with lcfg and an lfe.config file.

So, it can get hairy.

One of my long-term goals with lfetool is to rewrite as a series of rebar3 plugins (in LFE, of course). That will help LFE devs greatly in the future -- both with simplicity in tooling and greater flexibility in the same (a rare combo). But that doesn't help any of us right now :-/

Something else I should note: the recent changes we've made to the lfe executable have added support for things that lfetool was originally designed to provide (e.g., automatically pulling in rebar deps when running the REPL or compiling) ... I mention this in the event that you do start poking around in lfetool and notice things that seem redundant or ... byzantine (there's plenty of both!).

Happy coding!

d

[Robert Virding]

Just to extend a bit to Duncan's reply.

One thing you can definitely say is that introducing LFE into the system will not create any (new) issues of inconsistency. LFE code interacts seamlessly with the standard Erlang code so you can transparently call Erlang modules from LFE and call LFE modules from Erlang. For example there are no problems implementing OTP behaviour callback modules in LFE, it hust works. This means that in the future there are no problems with migrating code from Erlang to LFE, or the other way for that matter.

This seamless interaction is one of the goals of LFE.

Robert

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To post to this group, send email to lisp-flavoured-erlang@googlegroups.com.

Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To post to this group, send email to lisp-flavoured-erlang@googlegroups.com.

Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To post to this group, send email to lisp-flavoured-erlang@googlegroups.com.

[Matthew Fitzpatrick]

Obligatory mumbled comment with a cough: "Just rewrite it all in LFE :-)"

Haha, we've gotta get our feet wet first. The idea is to sneak it into test code, get used to syntax and what not, then creep it into utility functions, then finally main source proper (usually how this process seems to go).  Only like one or two of us have ever touched ANY form of Lisp so we want to start off slow. 

Seriously though, it's a matter of degree. Erlang + :LFE with just some LFE thrown in is dirt-simple: just adding rvirding/lfe in rebar.config. Once you've added unit tests in LFE, you've got two deps (and maybe more) plus either a hand-tooled Makefile or lfetool (or both). If you need to work around rebar2 quirks, oy umight have to do some fancy dancing with lcfg and an lfe.config file.

 

It truly is dirt simple. If I hadn't said it already, I was able to get LFE into the project and compiling as main source in less than 15 minutes. I then spent the rest of my time wrestling with getting the tests running.

Of course, those efforts were me trying to manipulate rebar2 into working. When I another chance, I'll attack it using lfetool and I imagine it will be much simpler that way.

This seamless interaction is one of the goals of LFE.

So far so good. Its good to hear about the behavior callbacks having first class support. We're also on a *verrrrrryyyyy* old version of Erlang (R15XX) so I was pleasantly surprised when it still "just worked".

Anyways, I'll hit it again next week and see where I can get. Thanks for all the information guys, truly appreciate it.

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.

Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.

Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.

Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.

[Duncan McGreggor]

Yeah, that's a really good point. The comments I was making refer strictly to tooling. They apply to any combination of languages. In support of Robert's comments, I think the usual difficulties encountered when supporting multi-language deployments are actually the least prevalent when using LFE + Erlang, given how closely LFE has stayed to the Erlang VM.

d

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.