29 Dec 2023 |
earldouglas | * Full command:
scala-cli \
--scala 2.12.2 \
--compiler-plugin org.scala-lang.plugins:::scala-continuations-plugin:1.0.3 \
--dependency org.scala-lang.plugins::scala-continuations-library:1.0.3 \
-P:continuations:enable \
myscript.sc | 17:38:29 |
earldouglas | * Anyone familiar with passing options to scalac? I have a plugin argument (-P:continuations:enable ) that seems to be ignored (this code must be compiled with the Scala continuations plugin enabled ). Same behavior whether I include or omit that -P argument. | 17:38:36 |
earldouglas | For reference, how to do this in sbt: https://stackoverflow.com/questions/2683195/how-do-i-enable-continuations-in-scala/2683215#2683215 | 17:41:45 |
armanbilge#6192 | seems like it should just work | 17:43:54 |
armanbilge#6192 | https://scala-cli.virtuslab.org/docs/reference/cli-options/ | 17:43:55 |
earldouglas | From --scalac-verbose , it looks like the plugin is being loaded correctly: loaded plugin continuations . Makes me wonder if the -P: argument is not being propagated to scalac. | 17:46:08 |
sake92 | Try --scala-option -P... | 17:46:56 |
SethTisue#7418 | https://github.com/VirtusLab/scala-cli/issues/2621 might have relevant info? seems like --server=false might be worth trying? | 17:51:59 |
SethTisue#7418 | * https://github.com/VirtusLab/scala-cli/issues/2621 might have relevant info? seems like --server=false might be worth trying? | 17:52:06 |
SethTisue#7418 | * https://github.com/VirtusLab/scala-cli/issues/2621 might have relevant info? seems like --server=false might be worth trying? | 17:52:08 |
SethTisue#7418 | * https://github.com/VirtusLab/scala-cli/issues/2621 might have relevant info? seems like --server=false might be worth trying? | 17:52:25 |
armanbilge#6192 | does it work if you do //> using directives instead? | 17:55:45 |
SethTisue#7418 | I'm able to reproduce the problem, and running scala-cli with -v -v shows that the -P... argument simply isn't passed on | 18:02:10 |
earldouglas | That works! | 18:02:54 |
earldouglas | Confirmed; I can fix it by either moving all options under //> using , or by moving just the -P: option under //> using . | 18:04:13 |
SethTisue#7418 | if you have a spare minute, please file a bug report. I don't see an existing one | 18:04:36 |
earldouglas | Sure thing; will do later today. | 18:05:06 |
earldouglas | Thanks for the help, all! | 18:05:14 |
earldouglas | https://github.com/VirtusLab/scala-cli/issues/2653 | 18:16:35 |
3 Jan 2024 |
JD557#8432 | I think the standard way is to just put all the directives in a project.scala | 20:10:32 |
JD557#8432 | Yeah, not really 🫤 | 20:12:42 |
JD557#8432 | I guess you could use the using-directives lib to parse it | 20:13:04 |
JD557#8432 | Or export the build | 20:13:38 |
JD557#8432 | (give me a minute, let me just order dinner) | 20:13:53 |
JD557#8432 | I meant this https://github.com/VirtusLab/using_directives | 20:18:58 |
JD557#8432 | I only see the export option, but maybe it's not that hard to convert from JSON to using directives? | 20:28:51 |
4 Jan 2024 |
Quafadas#7582 | I'm using scala cli to run a gist, which ends like this.
Caused by: doobie.munit.analysisspec$Checker$ErrorItems
at doobie.munit.analysisspec$Checker$ErrorItems$.apply(analysisspec.scala:61)
at doobie.munit.analysisspec$Checker.checkImpl(analysisspec.scala:54)
... 4 more
I reaaaaallly wan tto see those "4 more". Can I tell scala-cli not to truncate them somehow? I tried -v -v -v but to no avail. | 08:12:47 |
armanbilge#6192 | I'm not sure but it's possible the ... 4 more is the JVM truncating, not a scala-cli thing | 14:26:34 |
armanbilge#6192 | might be -XX:MaxJavaStackTraceDepth | 14:27:37 |
Quafadas#7582 | Well, I tried the stack trace flag, but didnt change anything get it to work. I'll pause this for now. | 20:23:57 |