haskell-jp / random #62

いまいち INLINE 付けるべき勘所が分からない
INLINE 付けないとモジュールを越えた融合変換が効かないというのは users' guide で知ったけど

Haskell.org committeeのメンバーを募集しています
https://www.reddit.com/r/haskell/comments/e6qcsf/call_for_haskellorg_committee_nominations/

お疲れ様でした！ :tada:
単純な興味本位で恐縮ですが、maoeさんはやってみてどうでした？

一番大がかりな仕事はGoogle Summer of Code/Summer of Haskellなんですが、初年度は引き継ぎのタイミングで上手くいかなかったのを反省して、ここ数年は上手くいくようになったのは良かったです。コミュニケーションもIRCだったのをSlackに変えたり、ドキュメントやGSoC関連のタスクをGitHub for non-profitに移したり環境も整備され快適になっています。
当初は日本のコミュニティと英語圏のコミュニティの架け橋になるような活動をもっとしたかったんですが、プライベートが忙しくなって全然時間が割けなくなったので結局あまり出来なかったのが残念です。

すみません、どんなお仕事なのか、まだ完全にイメージがわかないです。
https://wiki.haskell.org/Haskell.org_committee を読む限り
haskell.org の運営が主なところなんですかね？

https://github.com/sol/doctest/issues/245 doctestはcabal v2-buildに対応してない（？）みたいですね

• GSoC/HoSの運営
• haskell.org配下のサービスの運用ポリシーを決める（e.g. <http://discourse.haskell.org|discourse.haskell.org>）
• 寄付金の受領・管理・効果的な使途の模索
• 会計報告
• コミュニティ内の問題解決
• オフライン(ICFP etc)・オンラインでのミーティング

あたりでしょうか

仕事量的にはGSoCがメインになります

これ doctest だからか
v2-build では cabal-doctest を使うと聞きましたね

GSoCの運営っていうのは、参加者のmentorとかですかね？

メンターは別に募集します。運営側はアイデアを募集してプロジェクトのリストとしてまとめgoogleに提出して審査が通ると始めて組織としてgsocに参加できるようになります。その後、参加者を募集して選考を行い、メンターともマッチングさせた後、実際のプロジェクトが始まります。
その後も中間報告のとりまとめと、中間評価でpass/failの判断をしたり、最終報告と評価のとりまとめ等もします。

組織としてgsocの選考に落ちるとsummer of haskellとして自分たちで金策等もするのでさらにやることが増えます

ありがとうございます！割とイメージがわきました！

<https://google.github.io/gsocguides/mentor/> ここのOrg Admin のところが <http://Haskell.org|Haskell.org> committeeの担当に相当します

ディレクトリのパスとファイルのパスを受け取って、前者の下に後者が含まれているかどうか判定する (foo “foo/“ “foo/baa/a.txt” の時も True) 、絶対パスにも対応している関数って意外とないんですね

昔他のslackで見たのですが、「URL紹介に特化した"share"というチャンネル」を作ることについてどう思いますか？
懸念としては、以下あたりです。
 * Redditにリンクを貼ることと、趣旨がかぶる
 * ここのrandomチャネルと、趣旨が一部かぶる
 * URL貼るだけならtwitter(?)とか充分？
 * そもそも、そんな需要（貼る側、読む側）ある？
ただ、現状のRedditやrandomチャネルは、どうも遠慮があるのか、書く人がある程度限られるようです。
URLを貼るだけの専用チャンネルなら、心理障壁も低く誰でも気軽に情報共有できると思いますがどうでしょう。
（とりあえず試しに作ってみて低調なら閉じてしまっても良いですし、そもそも作らなくても良いです。）

そういうチャンネルがあったら見るぞ・投稿するぞという需要があるかリアクションなりで聞いてみるのはどうでしょう

haskell-jpのRedditをtt-rssに登録して更新通知受け取ってるので1つにまとまってる方が読む側としては便利かなという感情はありますね

なるほど、リアクションで聞く方法とはスマートですね。Slack便利。
では、以下のいずれかを教えてもらえますか、興味ある皆さん。
:hoshii:: そんなチャンネルがあれば投稿するor読む
:no_entry_sign:: 特に要らない（あるいはむしろ不要）

/pollあるので集計するならそちらの方が良さそうな気が…

Reddit の現状の扱いがよく分かってないのですが，特にコメントのしようがなくて，でも読んでみて有用だと感じたものをシェアしたいと思うことはあるので，それ用の何かは欲しいですね．投稿する側になるかは分かりませんが，少なくともそういう目的のものならある程度フィルターがかかってる有用なものとして読む側にはなります．

ただ懸念は二つあって，
* 同じ文献かがパッと見判別つかないので， Slack でやるとノイズが多くなるかも
* ノイズが多くなった場合にフィードなどがないので，自分が購読したい分野でフィルターがかけにくい

という感じですね．

そんな便利なものがあったのですね、次回ためしてみます:slightly_smiling_face:

英語版のRedditのHaskellページと違って、現状の日本語版のRedditの方は情報共有機構としてあまり機能してないんですよね、、、
例えばtwitterでの情報共有のみだと届く範囲が限られるので、せっかくの情報が埋もれていってもったいなぁと思うのですけれども、その方が皆うまく情報にリーチできてる感じですかね、もしかすると。
特に現状で問題なさそうなら、あえて"share"チャンネルは不要かなぁ:thinking_face:

twitter は後からあのリンク何だったかなあと探すのも大変なので，その意味でも情報失いがちなんですよね…

Reddit の現状の扱いがよく分かってないのですが，特にコメントのしようがなくて，でも読んでみて有用だと感じたものをシェアしたい

そういうのrandomに共有してくれるとありがたいんですが、randomやredditだとやらない理由ってありますか？

個人的には、バンバン random を使って、流れが速すぎるし複数の話題が混ざって困るなとなってから分ければいい、という意見です

https://www.slideshare.net/TokorotenNakayama/veinpsychological-safety-and-introduction-of-vein みたいにとにかくURLだけでいいことにすることで障壁を下げる、という意味であれば個人的にはありかなぁと思ったんですが、果たして本当に random では不十分だろうか、という点で懸念を感じています。

個人的には，今 random は割とノイズが多いので半分ミュートしてるというのがあります

randomチャンネルが充分に使われれば一番良いとは思うのですが、今の所、randomチャンネルで情報共有してくれるケースは限られているようです。（Reddit側はなおさら情報量が少ないです。この２か月で15件程度。）
twitterでの情報共有は多いだろうなと思うので、各々、共有すべき情報自体が無いわけではないのだろうなと想定しています。
とすると、randomで情報共有するのに遠慮なりがあるのかなと思いました。もちろん、shareをつくればそれで解消するとは限らないのですが、URL貼るだけでOK、なら心理障壁を下げられるのかなと思った次第です。

そうか... 今のrandomの流速ですでにノイズと感じるのか... であれば分けるべきなのかも

別にrandomにURL貼るだけでも全然かまわないし、私もほぼそうしているつもりなんですが... :confused:

私はrandomに気軽にURLを貼ってるので、私自信の使い方としては今のrandomでも問題はないです:slightly_smiling_face:
ただ、個別には情報発信してるけれども、slack上では情報共有しにくいという人が居れば、shareで救済できるかなと思ったわけでした。 twitter等にはURLを貼れるけれども、slackには貼りづらいという理由は、それぞれに聞いてみないとわからないのですけれども。今のままで置いときましょか。

twitter等にはURLを貼れるけれども、slackには貼りづらいという理由は

そこなんですよねぇ、:confused: それが決定的に share チャンネルで解決できるものであれば是非作りたいのですけども、個人的には今のrandomの使われ方で敢えて分けるのもなー、と思い微妙な気持ちです。

だからこそ試しに作るのはありなんですが、残る懸念は
• 既存の人に見てもらえるようにするのが面倒（まぁたくさんinviteすればいいだけですけど）
• 分散されることで、過去を遡って探すのが面倒になる？
といったところでしょうか。

別にrandomにURL貼るだけでも全然かまわないし、私もほぼそうしているつもりなんですが...

random ってURLだけの投稿でも良いんですね。今まで良くわかっていなかったので使ってなかったんですが、これから使ってみます。

言われてみれば純粋にURLだけっていうのはこれまでしてませんでしたね... （絵文字だけは過去やりましたが）でもHaskellerにとって有益なら全然かまわないと思います！ :+1:

Blockly for Haskell
https://guppy.eng.kagawa-u.ac.jp/~kagawa/Members/Sano/haskell.html

そうなんですよね、悩ましいんですよね。 分けることによるデメリットもあるんですよね。
inviteの問題については、shareもデフォルトで全員が入るチャンネルにしてしまう手もありますね。
shareを作るのが良いのか、randomの障壁を下げる策が良いのか、、、
slackに書きにくいと思ってる人からの改善意見があれば良いのですけども。

Keeping Compilation Fast
https://www.parsonsmatt.org/2019/11/27/keeping_compilation_fast.html

記事の最後で紹介されているコンパイル方法を最近ちょくちょく試してて、確かに速い気がする。
$ stack build --fast --file-watch --ghc-options "-j4 +RTS -A128m -n2m -qg -RTS"

Blockly for Haskell 知らなかった（OCaml しか

7日目のアドベントカレンダーがないぞい

まぁ急かさずともw
それより14日が空いてるぞい

あれ、ほんまや

@ has joined the channel

では、shareチャンネルの件は、一旦、寝かせておきましょう:slightly_smiling_face:
（別件でbeginnersについて、この後尋ねてみます。）

Haskellに新しく触れようとして、せっかくhaskell-jpのslackに来てくれる人を、Q&Aサポートしやすいように、beginnersチャンネルを作ろうかと思います。 questionsチャンネルよりも心理障壁を下げるものです。
beginnersチャンネルの設計は以下の感じです。 どう思います？

--------------------
beginnersチャンネルは、新しい人がスムーズにHaskellに慣れるための質問を歓迎するチャンネルです。
Haskell-Beginners ML や IRCの#haskell-beginners や RedditのMonthly Hask Anythingのような位置づけを意図しています。

beginnersチャンネルでの回答側は、以下の左側ような応答を厳禁とする運用です。
* それはくだらない質問だ → くだらない質問など無い
* その質問は以前にもあった → 質問者はそんなこと知らない
* Google検索せよ → 検索できないから質問している

beginnersチャンネルでは、例えば以下のレベルの質問から歓迎します。
* `:` とは何のことですか。
* タプルとは何ですか。
--------------------

Haddock ってCPP 使えるんですかね？

OGP 出ないのでコピーすると

Windows で最新の ThreadScope ビルドできた