Erjang + LFE bug when getting results from java.lang.System:getProperty

[Duncan McGreggor]

Hey all,

Apologies for the cross-post, but this really does seem to affect both projects :-/

As reported in this Erjang bug:
  https://github.com/trifork/erjang/issues/84

When making calls like (java.lang.System:getProperty '"java.io.tmpdir") in LFE+Erjang, an error is raised:

exception error: badarg
  in (: lfe_io_pretty
        print1
       "/var/folders/c8/2cl5l5_102b1qq8bh05t7xw40000gn/T/")

Kresten gave some key insight when he described how Java strings are passed back to Erlang as cons cells of the form (cons a b) java-string (where a would hold the first character and b the rest).

My first fix for this was the following in lfe_io_pretty.erl

 print1(_, 0, _, _) -> "...";
+%% Handle specialized forms from Erjang
+print1([Head|Tail], _, _, _) when is_list(Head) and is_list(Tail) ->
+    Head ++ Tail;

This worked well, but, as you can see, it returned a nested list. I toyed with [Head] ++ Tail, and then started running through various use cases... and I came to the following conclusions:

* I can easily see where a user would have a list like '("a" "pple") and would not want that pretty printed any other way than ("a" "pple"), representing the data structure they had created.

* As such, I am thinking that we shouldn't reassemble the strings from Java in LFE, but rather pass them through as-is.

* The fix in LFE should be as minimal as possible and a new LFE library might be created which would be specifically designed to deal with Java results Erjang. This would have the added benefits of being able to shorten calls (e.g., replace the user input of (jlfe-system:...) with (java.lang.System:...), and others like this).

Alternatively, work along these lines (reassembling results, providing aliases, etc.) could go in Erjang, if that was something Kresten felt was useful/desirable. Having extremely rusty Java "skills", I will still likely prototype any efforts in an LFE library...

What do people think about these or other options?

d

[Robert Virding]

Special casing that in lfe_io_pretty is not the way to go. The lfe_io modules should print out the data as it is and not try to interpret it. Someone most definitely will want to print data of that format will expect to see it as it is.

I am still trying to understand where the badarg error comes from.

[Duncan McGreggor]

Robert and I have been on #erlang-lisp trying to debug *where* in LFE this is actually going wrong. Turning out to be rather tricky to track down. You're more than welcome to join us :-)

Here's a gist with some debug statements we're working with and some output we're getting:
  https://gist.github.com/oubiwann/10068970

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.