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

Jump to bottom

More ways to trigger evalable #53

Open
AlexDaniel opened this issue Oct 19, 2016 · 7 comments
Open

More ways to trigger evalable #53

AlexDaniel opened this issue Oct 19, 2016 · 7 comments
Labels
evalable Issues related to Evalable bot testneeded Issue is generally resolved but tests were not written yet

Comments

@AlexDaniel
Copy link
Member 

<seatek> say '123abcg' ~~ /<xdigit + [g]>+/
<seatek> m:say '123abcg' ~~ /<xdigit + [g]>+/
<seatek> m: say '123abcg' ~~ /<xdigit + [g]>+/
<camelia> rakudo-moar 906719: OUTPUT«5===SORRY!5=== Error while compiling <tmp>␤Quantifier quantifies nothing␤at <tmp>:1␤------> 3say '123abcg' ~~ /<xdigit +7⏏5 [g]>+/␤»

m: without a space should work. Also, perhaps it should be able to figure out that say …something… should be executed as well. How often people start their sentences with “say” for other reasons? If there are any false positives, perhaps also check if the message has too many symbols or something.
@AlexDaniel AlexDaniel added the evalable Issues related to Evalable bot label Oct 19, 2016
@MasterDuke17
Copy link
Collaborator

I had another thought, anything that results in a "useless use of", also try the same thing with 'say ' in front and return both results.

@AlexDaniel AlexDaniel added the testneeded Issue is generally resolved but tests were not written yet label Jan 6, 2017
@AlexDaniel
Copy link
Member Author

This is exactly the reaction I was hoping for: https://irclog.perlgeek.de/perl6/2017-05-18#i_14599572

@AlexDaniel AlexDaniel mentioned this issue Jul 21, 2017
Closed
AlexDaniel added a commit that referenced this issue Aug 2, 2017
@AlexDaniel
Minimal tests for ‘m:’ messages
787680c 
Issue #53 can now be closed.
@AlexDaniel
Copy link
Member Author

I think this can be closed. Would be great to have more tests though.

@AlexDaniel AlexDaniel removed the testneeded Issue is generally resolved but tests were not written yet label Sep 6, 2017
@AlexDaniel
Copy link
Member Author

Maybe we should make it harder to trigger. Example: https://irclog.perlgeek.de/perl6/2017-09-05#i_15118238
The message in question actually looks like code. However, I've noticed that all times that we have evalable trigger on something we don't want to, it is always with non-zero exit code. So let's check the exit code before printing anything.

@AlexDaniel AlexDaniel reopened this Sep 6, 2017
AlexDaniel added a commit that referenced this issue Jan 31, 2018
@AlexDaniel
Add more brains to detect code
1a5c187 
This should trigger more and less at the same time. We will no longer
see annoying evals that result in compile time error, but we might see
it being triggered on things that actually work (even if
surprisingly).

Somewhat similar to Braitenberg vehicles, achieves intelligent
behavior using even simpler rules. Can now detect code in any message,
not just starting with “say”. Contrary to the logical approach of
detecting code and then running it, it runs every message first and
then only sends a response if the output is nice (0 exit code, no
warnings, etc.).

Rhesolves #53, #130
@AlexDaniel AlexDaniel added the testneeded Issue is generally resolved but tests were not written yet label Jan 31, 2018
@AlexDaniel
Copy link
Member Author

Leading space triggers both evalable and camelia: https://irclog.perlgeek.de/perl6/2018-02-03#i_15773390.

@AlexDaniel AlexDaniel removed the testneeded Issue is generally resolved but tests were not written yet label Feb 3, 2018
AlexDaniel added a commit that referenced this issue Feb 6, 2018
@AlexDaniel
Make sure to show segfaults
e91df0d 
Motivated by this situation:
https://irclog.perlgeek.de/perl6/2018-02-05#i_15780531

Related issues: #53, #130.
AlexDaniel added a commit that referenced this issue Feb 6, 2018
@AlexDaniel
Fixes for ‘ m:’ with leading space
3f0ba37 
See this comment:
#53 (comment)
@AlexDaniel AlexDaniel added the testneeded Issue is generally resolved but tests were not written yet label Feb 11, 2018
JJ pushed a commit to JJ/whateverable that referenced this issue Jun 3, 2018
@AlexDaniel @JJ
Add an extra autodetection test
f9b5703 
Actually, the feature is well tested, and even this test is somewhat
redundant. Closes Raku#53.
@AlexDaniel
Copy link
Member Author

AlexDaniel commented Dec 17, 2018 •
edited

Somehow @jnthn++ is triggering evalable unintentionally, all the time.

<jnthn> m:g does multiple matches, and <( )> set the limits of the matching
<evalable6> jnthn, rakudo-moar 38afa2d6f: OUTPUT: «(exit code 1) ===SORRY!=== Error while compiling /tmp/O2Rtjzi3To␤Two ter…»
<evalable6> jnthn, Full output: https://gist.github.com/eea772e80efd46824cfd08cf7403a759
<jnthn> Oh, be quiet, evalable6 

<jnthn> | sleep &
<evalable6> jnthn,  rakudo-moar 890d628a2: OUTPUT: «Use of uninitialized value of type  Callable in numeric context␤ in block <unit> at /tmp/T…»
<evalable6> jnthn, Full output: https://gist.github.com/6233b79f46e6a3beb6420821bcce405a

These can be simply special-cased, I don't remember any other false positive.

@AlexDaniel AlexDaniel reopened this Dec 17, 2018
@AlexDaniel
Copy link
Member Author

I fixed it a little bit in a32bb60, but m:g is still triggering, so that should be special-cased too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
evalable Issues related to Evalable bot testneeded Issue is generally resolved but tests were not written yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@AlexDaniel @MasterDuke17