Hypercube
Hypercube
当前的生成算法是有意设计的,采用了 [CIELUV](https://en.wikipedia.org/wiki/CIELUV) 色彩空间。HSV 或 HSL 色彩空间没有考虑人眼对色彩的感知,固定 L 分量生成的颜色的亮度并不是相同的。[color.js](https://github.com/Smart-Hypercube/color) 依赖就是用于计算 CIELUV 色彩空间与 sRGB 色彩空间转换的。 之所以没采用把亮度固定为常数的做法,而是在 0% ~ 50% 随机生成,是因为同一个视觉感受亮度下存在的颜色实在太少了,无论如何生成都不会显得丰富。下图展示了将视觉感受亮度(L* 分量)固定在 35% 时,可以使用的所有颜色(横纵轴分别是 u* 和 v* 分量):  如果像示例中那样,不仅固定亮度,还固定饱和度,可用的颜色就更有限了(相当于图上一个以中心为圆心的圆)。 另外,红色盲用户感知不到 u* 分量,如果...
> 另外在 0 到 50 之间随机亮度还可能导致一些对比度更高的类别比其他类别更 “显眼”。这在视觉设计上比较奇怪,相当于把语义相同的badge赋予了不同的优先级。 我倒是认为这种标签完全可以亮度和对比度不同。其实 HSL 生成的结果(原文的那个最终结果图)看起来亮度和对比度就是不同的,有一些标签明显比别的更“突出”,但五颜六色的感觉还不错啊。另一个参考:GitHub 上 issue labels 的颜色,默认用户头像的颜色,以及其他一些这样随机生成颜色的系统,其实也不固定亮度和对比度的。 > 而且调整题目顺序并不经常发生 啊这,科大的 hackergame 虽然尽了很大努力不在题目公开后调整顺序或增减题目,但这个项目希望尽量写得通用一些,不要假定这种情况不会发生。目前这个项目的一个 fork 就被用来提供一个长期存在的网站,会不断调整题目和分类的。 所以,如果类别名能被事先确定,保证不增减,并且可以枚举,整个问题都很好办。现在的难点主要还是来自于上游这个代码要写成通用的,应当可以妥善应对各种情况。在这个前提下我感觉选择很少。。。建议下游如果符合“类别名可以确定 + 可以枚举”这个使用场景的话,自行把 JS 中“类别名 -> 颜色”的算法改成一个 switch 语句(或者查表)即可😂
Yes. This won't compile: ```haskell a = do let b = do pure () ``` `pure ()` needs to be indented one more level. Currently, after hitting enter, the cursor...
`stack exec ghc-pkg` or set the search path for all tools to the output of `stack path --bin-path`?
Strange... According to the code, kernel will try to run `stack`, and check whether `The Haskell Tool Stack` is printed. If so, it will run `stack exec env`. I checked...
Sorry, my mistake. After edited `~/.stack/global-project/stack.yaml` to match the LTS version (18.28), I re-tested these: 1. `stack exec env`, find the `PATH=...` line. 2. `export PATH=...` 3. Confirm that `ghc-pkg`...
Yes. This is the content of `~/.local/share/jupyter/kernels/haskell/kernel.json`: ```json {"display_name":"Haskell","language":"haskell","argv":["/home/app/.local/bin/ihaskell","kernel","{connection_file}","--ghclib","/home/app/.stack/programs/x86_64-linux/ghc-tinfo6-8.10.7/lib/ghc-8.10.7","+RTS","-M3g","-N2","-RTS","--stack"]} ```
https://github.com/commercialhaskell/stack/commit/49bf07ce76e6c8e9e63a0a582e8a2ae0078e93b3 `stack` changed behavior in this commit. Before: Print on stdout and exit with 0. After: Print on stderr and exit with 1.
I made a PR for this. However, I also wish that when `--stack` is used, and `stack` detection failed, kernel would report an error and crash, instead of silently ignoring...
I would like to know the opinions of current maintainers on this issue. If you think it's a good idea but don't have time, I'm willing to help by submitting...