| 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 \
myscript.sc
| 17:37:48 |
| 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 | seems like it should just work | 17:43:54 |
| armanbilge | 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 | https://github.com/VirtusLab/scala-cli/issues/2621 might have relevant info? seems like --server=false might be worth trying? | 17:51:59 |
| sethtisue | * https://github.com/VirtusLab/scala-cli/issues/2621 might have relevant info? seems like --server=false might be worth trying? | 17:52:06 |
| sethtisue | * https://github.com/VirtusLab/scala-cli/issues/2621 might have relevant info? seems like --server=false might be worth trying? | 17:52:08 |
| sethtisue | * https://github.com/VirtusLab/scala-cli/issues/2621 might have relevant info? seems like --server=false might be worth trying? | 17:52:25 |
| armanbilge | does it work if you do //> using directives instead? | 17:55:45 |
| sethtisue | 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 | 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 | I think the standard way is to just put all the directives in a project.scala | 20:10:32 |
| jd557 | Yeah, not really 🫤 | 20:12:42 |
| jd557 | I guess you could use the using-directives lib to parse it | 20:13:04 |
| jd557 | Or export the build | 20:13:38 |
| jd557 | (give me a minute, let me just order dinner) | 20:13:53 |
| jd557 | I meant this https://github.com/VirtusLab/using_directives | 20:18:58 |
| jd557 | 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 | 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 | I'm not sure but it's possible the ... 4 more is the JVM truncating, not a scala-cli thing | 14:26:34 |
| armanbilge | might be -XX:MaxJavaStackTraceDepth | 14:27:37 |
