With a snippet like
perl6 -e 'loop { FIRST say "foo"; last }'
I get
WARNINGS for -e:
Useless use of LOOP_BLOCK_1 symbol in sink context (line 1)
foo
I know how to work around the warning. I'm wondering about what the source of the warning is. I found this open ticket, but it doesn't seem to have received any attention.
What is this warning about?
And what about this is useless?
Version
$ perl6 --version
This is Rakudo version 2018.06 built on MoarVM version 2018.06
implementing Perl 6.c.
It's a bug, a bogus warning.
I know how to work around the warning.
That's the main thing.
I'm wondering about what the source of the warning is.
It's a bogus warning from the compiler.
I found this open ticket, but it doesn't seem to have received any attention.
I think it got some attention.
bbkr, who filed the bug, linked to another bug in which they showed their workaround. (It's not adding do but rather removing the FIRST phaser and putting the associated statement outside of the loop just before it.)
If you follow the other links in bbkr's original bug you'll arrive at another bug explaining that the general "unwanted" mechanism needs to be cleaned up. I imagine available round tuits are focused on bigger fish such as this overall mechanism.
Hopefully you can see that it's just a bizarre warning message and a minor nuisance in the bigger scheme of things. It appears to come up if you use the FIRST phaser in a loop construct. It's got the very obvious work around which you presumably know and bbkr showed.
What is this warning about?
Many languages allow you to mix procedural and functional paradigms. Procedural code is run for its side effects. Functional code for its result. Some constructs can do both.
But what if you use a construct that's normally used with the intent of its result being used, and the compiler knows that, but it also knows it's been used in a context in which its value will be ignored?
Perls call this "useless use of ... in sink context" and generally warn the coder about it. ("sink" is an alternative/traditional term for what is often called "void" context in other language cultures.)
This error message is one of these warnings, albeit a bogus one.
And what about this is useless?
Nothing.
The related compiler warning mechanism has gotten confused.
The "Useless use of ... in sink context" part of the message is generic and hopefully self-explanatory.
But there's no way it should be saying things like "LOOP_BLOCK_1 symbol". That's internal mumbo-jumbo.
It's a warning message bug.
Related
While trying to learn Frege I copied some code from Dierk's Real World Frege to the online REPL an tried to execute it (see also How to execute a compiled code snipped in Frege online repl). The scripts I've tried don't compile :-(
What am I doing wrong?
Here are examples of what does not compile:
println ( 2 *-3 ) -- unlike haskell, this will work!
and the whole ValuesAndVariables.fr code
It is unavoidable that over the course of more than a year, an evolving language (and its libraries) change so that older code will not compile anymore.
It would be nice, if we could see an example, instead of a generalization like "most".
The next best thing would be to have an issue in Dierks project that points to the error(s).
But the very best would be en effort to find out what is wrong. This would also intensify your learning process.
Here are two ressources that could help:
https://github.com/Frege/frege/wiki/New-or-Changed-Features -- the release notes for every release, contains a summary of things that have changed between releases, and especially the reasons why code would not compile anymore and how to correct it.
http://www.frege-lang.org/doc/fregedoc.html -- the library docs. May explain possible errors like import not found, or missing identifiers.
Go, give it a try. And I'm convinced Dierk will be happy to accept pull requests.
Edit: Fixes for announced errors.
The error in:
println ( 2 *-3 )
stems indeed from a syntactical change.
It is, as of recently, demanded that adjacent operators be separated by at least one space.
Hence
println (2 * -3)
However, the error message you got here was:
can't resolve `*-`, did you mean `-` perhaps?
which could have triggered the idea that it tries to interpret *- as a single operator.
The other error in ValuesAndVariables1.fr is indeed a show stopper for a beginner. The background is that we have one pi that has type Double and one that has type Float and potentially many more through type class Floating, so one needs to tell which one to print.
The following will work:
import Prelude.Math -- unless already imported
println Float.pi
println (pi :: Double)
the online REPL at http://try.frege-lang.org is currently based on Frege V3.23.370-g898bc8c . Dierk's code examples are based on V3.21.500-g88270a0 (which can be seen in the gradle build file).
It seems that the Frege developers decided to change the Frege syntax slightly between those versions. THe result is that you will not be able to run these code snippets in the online REPL anymore.
I have some code comments like this:
/**
How to use this method.
#discussion To use it, do something like the following
id hook = [[STDeallocHook alloc] initWithBlock:^{
// Do something when 'hook' is dealloced
}];
*/
So the code example is indented with 4 spaces. When I compile the docset with appledoc, it compiles correctly and shows the code as code in the API reference I generate. However back in XCode (Where I have appledoc creating warnings for issues in the doco) I get the warning:
Invalid [[STDeallocHook alloc] reference found hear STDeallocHook.h#16, unknown object: [STDeallocHook !
I think what's happening is that appledoc is looking for markdown links inside the code block.
How can I stop this warning from appearing?
I've been unable to stop it as well. It looks like it's been a known bug since 2011, but it's still broken.
Interestingly enough, I don't get it for everything. In a large code example, I'll only get a few of them... still haven't figured out how it determines to cause me grief or not...
Workarounds
This works around the warning, and looks fine in the generated documentation, but looks like crap in plain text: substitute the leading [ with the HTML escape code [
Future Fix
Supposedly, the mythical version 3 has addressed it, but I can't find any mention of an ETA for it. There is a "3.0exp1" branch from March 2012, and a "3.0dev" branch from October 2014.
If you have both the time and inclination, maybe you can see how it was fixed and patch it yourself (though the codebase has apparently changed a ton since then).
My Attempt
I felt unsatisfied with that answer, so, I went back and looked at the source code. First time in that code. It's not exactly easy to navigate... and none of the classes are documented, which I find quite strange, especially for a documentation tool.
Anyway, I think I know why I only get the warning sometimes. The parser treats all underscores as formatting markers. Thus, if it finds two of them in the same "block" of text, it splits them up. Since the code I tested on had category documentation, only the last one encountered in each "block" caused a warning... because all the others were treated as italics... and then ignored.
Also, it seems that I may be able to coerce it into skipping source-code blocks if they are marked as either...
#code
[self wjh_doSomething];
#endcode
or
```
[self wjh_doSomething];
```
or
~~~
[self wjh_doSomething];
~~~
The first is common in documentation blocks, the latter two in markdown.
It's a hack, but it seems to work. I sent a PR, which can be found here. Who knows if it will get accepted, but feel free to try it out yourself if you are so inclined.
I think I'll at least use it locally, as it cleans up a ton of warnings for me... and I may just go try to regenerate all my documented stuff to boot.
Edit
Well, I guess I should have gone and looked at the open PRs first. There seems to be a PR already sitting there that deals with the same issue, that has been there since May. It would have saved me time... but it was a little fun experimenting with it a bit ;-)
You may want to use that one... it seems to be simpler. Simpler is better, but I have not used that one and I'm not sure it completely ignores the blocks, but he seems to have quieted the warnings with his patch.
That one does not support #code/#endcode, which I'm glad to have.
Is there a lint for Elixir (like for Javascript) which checks that every function has a type specification?
There is an Erlang compiler switch, +warn_missing_spec, which does this, but I'm having trouble getting it to work with Elixir at the moment, I think there is a bug with it's parsing of the ELIXIR_ERL_OPTS environment variable which is converting +warn_missing_spec into -warn_missing_spec which isn't a valid compiler option. I'm going to open an issue on the tracker, but thought you might like to know that this does indeed exist.
EDIT: As José mentioned below, the correct flag is ERL_COMPILER_OPTIONS. You can enable the missing spec warning during compilation by doing the following:
ERL_COMPILER_OPTIONS="warn_missing_spec" mix compile
Keep in mind you may get superfluous warnings from Elixir itself, for functions like __MODULE__. It should still be useful though. One last thing to note, I discovered this morning that there is a problem using this flag with mix compile, and that it's currently only warning about mix.exs. This is being fixed, and may even be fixed by the time you see this, but it's something to be aware of.
...is there anything I could do about it?
To be more precise, I would like to replace the caret "^" with something like "§" - granted, there's not much left on the keyboard that's not in use already.
After thinking about it for a while (dismissed using run script build phases along the way) I think the only way to do it would be a custom llvm build.
While I don't quite think I'm ready to deal with the internals of compilers, I have the naive hope that replacing one symbol with another isn't too hard. And the idea of building and running my own version of a compiler tickles me, be it just for a good deal of childish fun.
So I started poking around in the llvm sources, but - surprise - got nowhere so far.
If someone is familiar with these kind of things, could you please point me to a place to look at?
That would be awesome! Thanks!
Extending LLVM can be a bit of a hassle, especially considering how fast-moving the compiler team is, so it's a good thing you don't have to. The C preprocessor exists to perform the exact same thing you've outlined (text replacement). I'm fairly sure § isn't aliased to anything important, so #define § ^ should work great. If you still want to write your own module, LLVM provides instructions on how to extend their compiler.
Actually the code relevant for such a change isn't a part of LLVM at all, but a part of its Objective-C frontend, called Clang. Confusingly, "Clang" is also the name of the entire C/C++/ObjC compiler based on both Clang and LLVM.
While I don't quite think I'm ready to deal with the internals of compilers, I have the naive hope that replacing one symbol with another isn't too hard.
And you'll be right. What you're trying to do is very simple change.
In fact, if ^ was only used for blocks, it would be a trivial change - just modify the lexer to generate the "caret" token from § instead of ^: take a look at the lexer code to see what I mean (search for ^).
Unfortunately it's used for xor as well, so we'll have to modify both the lexer and the parser. The lexer to add a new token type and create that token from §, the parser to actually do something with it, e.g. by adding:
case tok::section: // 'section' is the token type you've added
Res = ParseBlockLiteralExpression();
break;
(and then fixing the assert at the beginning of ParseBlockLiteralExpression()).
You might run into some issues, though, as § isn't in ASCII - though as far as I know Clang should be able to deal with UTF-8 encoded files.
This code hummed along merrily for a long time, until we recently discovered an edge case where it fails silently-- no errors returned.
The fail is apprently pretty subtle. We can get the code to run uneventfully in the edge case by:
1) compiling with any set of options that includes -traceback or debug (-g or -gopt);
2) compiling with -fast -Mnounroll;
3) compiling with optimization <2;
4) adding WRITE statements into the code to determine the location of the fail;
In other words, most of the tools useful for debugging the failure-- actually result in the failure disappearing.
I am probing for any information on failures related to loop unrolling or other optimization, and their resolution.
Thank you all in advance.
I'm not familiar with pgf (heck, it's been 10 years since I used any fortran), but here are some general suggestions for tracking down (potential) compiler bugs:
Simplify a reproducible case. I.e. try to reproduce the problem with a similar looking piece of code that has all the superfluous details removed. This is helpful because a) you'll be less hesitant to release the code publicly, and b) if someone attempts to diagnose the problem, it will be easier for them with less surrounding material.
Talk to the experts: If you have a support contract for pgf, use it! There's a support request form on their site. If not, there's a User Forums section where you might be able to post your information - someone else may have better workaround, or an employee there may be able to log your problem.
Double-check your code. Is it possible that you're relying on some sort of unspecified behavior? This is the sort of thing that would cause your program to switch behavior when changing optimization levels. I'm not saying compiler bugs are impossible, but it could be a hack in your code too.
Hope that's helpful.