<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 28, 2014 at 10:09 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A macro for ?OTP_RELEASE or ?OTP_VERSION makes *absolutely no sense*. There are no guarantees that people are going to compile on a fresh Erlang release. If I create a release named PONIES, this will not help at all when I then use the compiler app I included to compile some stuff at runtime.<br>
<br>
Something a little better is ?COMPILER_VERSION, but people might also run a custom compiler code with a custom version number, so that's a no go either.<div class=""><br></div></blockquote><div><br></div><div>It would make sense for me, that's why I considered it. However, I agree that my use case is special and is probably not enough to support this addition by itself.</div>
<div><br></div><div>Since I have a patched debugger for erlide and I don't know which version will users run their code on, I need to provide separate debuggers for all supported versions and I am going to compile the code on fresh releases. This isn't a problem until there are incompatibilities. I suppose that the debugger is stable enough that I could maintain different patched variants for the different versions, but it's still work that could be used for other features/improvements/fixes.</div>
<div><br></div><div>regards,</div><div>Vlad</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
On 02/28/2014 09:36 AM, Vlad Dumitrescu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
Hi,<br>
<br>
I've been hit by this too, as I have a patched debugger that I need to<br>
compile on older versions too and there are issues with<br>
unicode/maps/named funs. Unfortunately, there might be cases where code<br>
will still have to be duplicated, because macros can only wrap full forms.<br>
<br>
From a brief look att epp.erl, it feels like adding a ?OTP_RELEASE or<br>
?OTP_VERSION predefined macro would be easy and the only possible<br>
problem is if there are user-defined macros with the same name.<br>
<br>
predef_macros(File) -><br>
Machine = list_to_atom(erlang:system_<u></u>info(machine)),<br>
{ok, Release0} = file:read_file(code:root_dir()<u></u>++"/OTP_VERSION"),<br>
Release = string:strip(Release0, right, $\n),<br>
...<br>
{{atom,'OTP_RELEASE'}, {none,[{string,1,Release}]}},<br>
...<br>
<br>
By the way, wouldn't it be useful to have an erlang:system_info() that<br>
reads the file and strips the 'ok' and the whitespace?<br>
<br>
best regards,<br>
Vlad<br>
<br>
<br>
On Fri, Feb 28, 2014 at 1:08 AM, ANTHONY MOLINARO<br></div><div class="">
<<a href="mailto:anthonym@alumni.caltech.edu" target="_blank">anthonym@alumni.caltech.edu</a> <mailto:<a href="mailto:anthonym@alumni.caltech.edu" target="_blank">anthonym@alumni.<u></u>caltech.edu</a>>> wrote:<br>
<br>
I also have felt this pain with the transition from behaviour_info<br>
to callbacks for behaviours. Ideally, the preprocessor would define<br>
a macro along the lines of ?MODULE, ?MODULE_STRING, ?FILE, ?LINE,<br>
and ?MACHINE which is the full list according to<br>
<a href="http://www.erlang.org/doc/reference_manual/macros.html" target="_blank">http://www.erlang.org/doc/<u></u>reference_manual/macros.html</a>.<br>
<br>
If there was one additional macro call ?RELEASE with the major<br>
release, then it would be possible to conditionally compile at least<br>
dialyzer stuff (I don't know about the file encoding, I guess it<br>
would depend on whether the check is done during the preprocessor or<br>
at a later step). This would probably prevent the proliferation of<br>
different compile macros which seem to crop up as every individual<br>
library adds their own based on a rebar or makefile check.<br>
<br>
-Anthony<br>
<br>
On Feb 27, 2014, at 3:06 PM, Jesper Louis Andersen<br>
<<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.<u></u>com</a><br></div>
<mailto:<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@<u></u>gmail.com</a>>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Release 17.0 brings two changes which prove to take some work<br>
getting around.<br>
<br>
1. utf-8 is now the default encoding.<br>
<br>
This is a rather insignificant change. The source code which uses<br>
latin1 can be fixed by one of three ways:<br>
<br>
* Tell the compiler the file is latin1. This won't work going<br>
forward but works now.<br>
* Change the file to utf-8. This won't work going backward a long<br>
way. But it will work going backwards for a bit.<br>
* Change the file to ASCII. This works both backward and forward<br>
as long as we want.<br>
<br>
This is a benign problem. I have tried compiling some projects and<br>
it turns out there are numerous repositories which needs fixing<br>
now. But the fix is rather simple.<br>
<br>
2. Dialyzer dislikes queue(), dict(), ...<br>
<br>
Dialyzer now prefers using queue:queue() and the like. This is<br>
*definitely* the right thing to support as it is much more<br>
consistent with the rest of the system and doesn't treat certain<br>
types as magically introduced types.<br>
<br>
-module(z).<br>
<br>
-export([f/1]).<br>
<br>
-spec f(queue:queue()) -> queue:queue().<br>
f(Q) -> queue:in(3, Q).<br>
<br>
Which is nice, but this doesn't work on R16B03:<br>
<br>
z.erl:5: referring to built-in type queue as a remote type; please<br>
take out the module name<br>
z.erl:5: referring to built-in type queue as a remote type; please<br>
take out the module name<br>
<br>
So here, I have no way of getting my source code to work with both<br>
R16 and 17.0 easily. There is no transition period so-to-speak.<br>
Many projects run with warnings-as-errors and they are in trouble:<br>
<br>
* They can't compile<br>
* They can remove the warnings-as-errors but this defeats the purpose<br>
* They will have warnings spewed out over the console all the time<br>
<br>
In the case of crypto:hash/2, we had somewhat the same situation.<br>
Prominent projects like Yaws, and lesser projects like Emysql has<br>
EPP macros in place as well as detection in order to figure out<br>
what to do. Or you can disable the warnings in this case<br>
specifically for this. But can I do the same with wrong type<br>
specs? Also, this workaround is done in almost every project out<br>
there, which is darn irritating.<br>
<br>
I don't know what we need to solve this. At one point, I would<br>
really like to have a set of feature flags<br>
<br>
<a href="http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm" target="_blank">http://www.lispworks.com/<u></u>documentation/HyperSpec/Body/<u></u>v_featur.htm</a><br>
, ZFS, ...<br>
<br>
where you have a way to compile-time scrutinize what your<br>
environment supports. Another way to solve it is the variant Go<br>
uses, namely "build constraints"<br>
<br>
<a href="http://golang.org/pkg/go/build/#pkg-overview" target="_blank">http://golang.org/pkg/go/<u></u>build/#pkg-overview</a><br>
<br>
which will mention under which circumstances to include a file as<br>
a part of an application. This would allow for easy handling of<br>
crypto:hash/2, but I do note it will fail on the dialyzer problem.<br>
It looks like the only sane way to solve that is to allow both<br>
queue() and queue:queue() as aliases for a major release and then<br>
proceed to remove queue().<br>
<br>
Am I completely wrong here? I can accept languages evolve and that<br>
Release 17 has maps which will be used and break a lot of software<br>
for R16 quickly. But I also feel we should have some way of having<br>
a process so there is a way to handle this gracefully going<br>
forward. It is natural for libraries and languages to evolve and<br>
break compatibility. Yet, it should be easy to handle for<br>
programmers. There is much time wasted, which could be used better<br>
were there a nice solution.<br>
<br>
Thoughts?<br>
<br>
--<br>
J.<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br></div></div>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><div class="">
<br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
Loïc Hoguin<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
</div></div></blockquote></div><br></div></div>