scala/scala

Discord is now Scala’s main chat platform. Please join us at https://discord.com/invite/scala

zygfryd

@zygfryd

Pretty sure a fair bit of crypto is simply built into the JDK

Côme

@come_744:tedomum.net

Hello,

I would like to put Wavedrom diagrams in Scaladocs. Wavedrom can be run on page generation ("server" side) or on page rendering (client side).

My first simplistic approach was to add some html code to render it on client side, but it does not seem possible because html tags are escaped (scala/bug#11137). What I would need:

<!DOCTYPE html>
<html>
  <head>
    <title>Wavedrom test</title>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/wavedrom/2.6.8/skins/default.js"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/wavedrom/2.6.8/wavedrom.min.js"></script>
    <script type="text/javascript">
        function init() {
            WaveDrom.ProcessAll();
        }
        window.onload = init;
    </script>
  </head>
  <body>
    <p>Some diagram:</p>
    <script type="WaveDrom">
{ "signal": [
  {"name": "clk",     "wave": "p........."},
  {"name": "valid"  , "wave": "0101..01.0"},
  {"name": "ready"  , "wave": "x1x0.1x1.x"},
  {"name": "payload", "wave": "x=x=..x==x","data":["D0","D1","D2","D3"]}
]}
</script>
  </body>
</html>

Is there a way to bypass this?

The other option is to render it on "server" side. Is scaladoc or sbt-unidoc extensible so that we could add an extension to manage Wavedrom code?

Seth Tisue

@SethTisue

@come_744:tedomum.net that ticket says the opposite — it says "we simply pass through any html tags from source to the documentation"

9 replies

Côme

@come_744:tedomum.net

[m]

So it seems it is just script which is escaped, which anyway is blocking for Wavedrom?

Seth Tisue

@SethTisue

I replied on the thread before seeing this remark outside of the thread

you may need to postprocess the output of Scaladoc

1 reply

Côme

@come_744:tedomum.net

[m]

Thanks, I'll follow the ticket then 😃

Seth Tisue

@SethTisue

if I were you, I would not assume that there is any special handling of script tags per se unless you're sure of that

Raileanu Marius

@MariusRaileanu_twitter

Hi, I have this piece of code and trying to get it as a Map[String, String] currently it is Map[String, Any]

val rawFullFilePath = "some.csv"  
val df = spark.read.option("header", true).csv(rawFullFilePath)

// define some way to generate a sequence of workloads to run
val jobArguments = df.collect.map(r => Map(df.columns.zip(r.toSeq):_*))

vitthal ingle

@vitthalpatil:matrix.org

[m]

how to fetch youtube video id in google youtube api please give mi code

fetch the single video details

Isaac Zeng

@gfZeng

Idea + bsp(with sbt) dev scala 3, CPU always high. very bad experience. how about you?

Hanns Holger Rutz

@Sciss

Did something change in Scala 3.2 vs 3.1?

[error] -- [E050] Type Error: /project/core/shared/src/main/scala/de/sciss/fscape/graph/IfElse.scala:184:9 
[error] 184 |    Then.SourceUnit(cases)
[error]     |    ^^^^^^^^^^^^^^^
[error]     |    object SourceUnit in object Then does not take parameters
[error]     |

with

object Then {
   case class SourceUnit protected(cases: List[UnitCase])
}

and invocation

Then.SourceUnit(cases)

Is protected interpreted differently now?

Are we not source and binary compatible in Scala 3.x ?

Guillaume Martres

@smarter

protected means the apply methosd is protected too

but also this channel is deprecated, please use discord

Hanns Holger Rutz

@Sciss

yes, I don't like discord :) so you answered already :) So I need to lift the visibility? (because the constructor is also not accessible).

Guillaume Martres

@smarter

I'm surprised this work before, and yes we should be binary compatible at least, so I don't know what's going on

Hanns Holger Rutz

@Sciss

This worked throughout 2.12, 2.13, 3.0, 3.1...

I change to protected[graph] which is my package. Now it compiles

oof, I got a ton of these

Hanns Holger Rutz

@Sciss

plus unit test failures for something something akka, I'm reverting to 3.1.3 :-|

Joan Goyeau

@joan38

Hi,
I'm trying to upgrade from 2.13.8 to 2.13.9 or 2.13.10 but it's not compiling:
joan38/kubernetes-client#169

Error:  /home/runner/work/kubernetes-client/kubernetes-client/kubernetes-client/test/src/com/goyeau/kubernetes/client/api/ConfigMapsApiTest.scala:26:16: incompatible type in overriding
Error:  def api(implicit client: com.goyeau.kubernetes.client.KubernetesClient[cats.effect.IO]): com.goyeau.kubernetes.client.operation.Listable[cats.effect.IO,io.k8s.api.core.v1.ConfigMapList] (defined in trait ListableTests);
Error:    <none>
Error:    override def api(implicit client: KubernetesClient[IO]) = client.configMaps
Error:                 ^

Do you know why? Because any Scala 3 or Scala 2 works.

Joan Goyeau

@joan38

So I have a class implementing multiple functions with different return types into one that implements it with a result that implements both return types:

def api(implicit client: KubernetesClient[F]): Watchable[F, Resource]

def api(implicit client: KubernetesClient[F]): Listable[F, ResourceList]

def api(implicit client: KubernetesClient[F]): ConfigMapApi = ...

Where ConfigMapApi implements both Watchable and Listable.

Sounds like if I specify the type : ConfigMapApi on the overriding function it compiles.

Sounds like a regression in the type inference introduced in 2.13.9

Joan Goyeau

@joan38

Here is the failing build: https://github.com/joan38/kubernetes-client/actions/runs/3459273993/jobs/5774498922

Seth Tisue

@SethTisue

@joan38 if you're using -Xsource:3, scala/scala#10012 seems like a possible culprit. you might also take a look at scala/scala#9891 . but if you want to discuss further, let's follow up somewhere other than this abandoned Gitter room

I hope you already looked at https://github.com/scala/scala/releases/tag/v2.13.9 for likely culprits? that's all I did myself, here

Florian Schmaus

@Flowdalic

Could someone explain to me how https://github.com/scala/scala/blob/bce7748219d547dd73ef862e049114aafd221d94/src/library/scala/concurrent/impl/Promise.scala#L458-L460 allows for garbage collection, given that the reference appear to be in scope till the end of the method?

Côme

@come_744:tedomum.net

[m]

Is it possible that the goal is to allow GC at the end of the method without waiting for this: Transformation to be garbage-collected?

Florian Schmaus

@Flowdalic

@come_744:tedomum.net that was also my thought, but then I would perform the null'ing of the fields in a finally block at the end of the method, as it would be more readable IMHO

Florian Schmaus

@Flowdalic

Ahh ok, it's because of handleFailure() in the catch block

Côme

@come_744:tedomum.net

[m]

Also it would require to store the returned value to return it after the = null, and it would break in case a return statement is used somewhere.
Here it moves things to local scope at the beginning, seems safer.

Florian Schmaus

@Flowdalic

@come_744:tedomum.net it would not break if the return statement is used within the try/finally block, or am I missing something?

Côme

@come_744:tedomum.net

[m]

Ah possible 😃

Florian Schmaus

@Flowdalic

I would be happy if someone had suggestions on how to improve my "happy eyeball" implementation at https://codereview.stackexchange.com/questions/281587/happy-eyeballs-with-scala-futures :)

Joshua K. Farrar

@joshuakfarrar

I have a PR open bump scala/scala-seed.g8 to Scala 3.1.0: https://github.com/scala/scala-seed.g8/pulls

Is anyone still looking at this project?

Seth Tisue

@SethTisue

@joshuakfarrar I look it at monthly or so. I'll take a look right now

rom1dep

@rom1dep:kde.org

[m]

hi there!
I was curious about how the scala compiler handles/optimizes something like that, I often have data processing steps which I like to decompose into individual map for clarity:

val input: List[Something] = […]
input
  .map(do something)
  .map(do something else)
  …
  .finish

but in theory, this could be rewritten as

input
  .map{val a = do something ; do something else(a) ; …}.finish

Is there a performance penalty or downsides to using the former style instead of the latter?

Matthew Rooney

@javax-swing

the biggest performance penalty will be that map produces a new List. You can circumvent this by doing your operations on a view or iterator and converting back to a list as the final step.

rom1dep

@rom1dep:kde.org

[m]

thanks, that was my impression as well and it's a bit unfortunate if stuff like that isn't optimized away and expressiveness has to be thrown away for performance

Seth Tisue

@SethTisue

@rom1dep:kde.org seconding the recommendation to use .view if you care

(.view exists in Scala 2.12 and earlier, but the design/implementation was kinda janky. since Scala 2.13, it's totally solid. so on earlier Scala versions, I'd prefer .iterator)

code in which any performance difference here is actually a bottleneck is likely to be rare

so you should feel free to go with the more expressive version nearly all of the time

rom1dep

@rom1dep:kde.org

[m]

@SethTisue: thanks! So, just to make sure, it'd turn into something like:

val input: List[Something] = […]
input
  .view
  .map(do something)
  .map(do something else)
  …
  .finish

Luis Miguel Mejía Suárez

@BalmungSan

@rom1dep:kde.org .finish will probably be a .toList

rom1dep

@rom1dep:kde.org

[m]

👍️

Where communities thrive

People

Repo info

Activity