いつもの31倍の尺の動画だぞ!
原作ウイルス【VOICEROID劇場】 - ニコニコ動画
https://www.nicovideo.jp/watch/sm38285822
shibafu528(@shibafu528@social.mikutter.hachune.net)の投稿
ボンクラプログラマー
頭とお腹が弱い。
最近は個人鯖の @shibafu528 がメインです。
⚠️ CW設定のない下品な発言が非常に多いです。これは仕様ですのでご了承下さい。
ℹ️ spam対策でフォロー承認制にしています。上の一文が構わないという方ならお気軽にどうぞ。
FINAL FANTASY XIV 関連の著作物は
(C) SQUARE ENIX CO., LTD. All Rights Reserved.
いつもの31倍の尺の動画だぞ!
原作ウイルス【VOICEROID劇場】 - ニコニコ動画
https://www.nicovideo.jp/watch/sm38285822
Mastodonのcontent htmlで書いちゃうと他のシステムから来たやつで壊れがち (y4aでも似た経験をした)
よくわからんからみうぱよの投稿をテストコードに貼るか
parseがコケてるということはNSXMLParserの怒りを買ったな さてどこだ
あー… これはあれやな Ono使うしかねえな NSXMLParserはXMLのパーサやし
でもActivityPubの投稿本文のパースのDOMパーサは無駄なんだよなー 無駄というか余計な手間がかかる
Mastodon WebUIで返信しようとして投稿欄にセットしたツーツが消えた場合、reply toの表示は消失するが入力中の本文は残る。この場合、そのまま送信したらin-reply-toは……まあ無いから全TLに配信される通常投稿になるのかな?
無効でもややreplyっぽい振舞いするのね 半端だな
あーなんか腹立ってきた もうlibxml2勉強するか?
XmlPullParserが素で入ってるAndroidが神システムであることが分かってしまったな
DOMパーサ入れるんだったらなんかNSXMLDocumentでもええんちゃうかみたいな気がしてくるな
あーでもlibxml2/HTMLparserってHTML4か
えっ libxml2ってSAXパーサーをツリーの上に作ってんの? アホじゃん
reader apiが後付けで生えてることから解決済みの問題ではあるが、当初設計はあまりにもアホであることが分かる どこに優位性があるんだよ、要素単位の解析イベント取れるだけじゃん
でもHTMLパーサのreader api用意されてねえ やっぱりアホじゃん
StAXなAPIを用意すれば、それをベースにDOMを構築することは理屈の上ではできるはずなんだが、なんでそういう組み立て方をしてないんだろう。
まあどうせ内部的には近いことになってる気がするが、StAXが"発明"されたのがけっこうXML黄金時代の後半だからか?
やはりXMLを扱うには大XML帝国の跡であるJava界隈は頭一つ出てるな… 他の言語は…って感じする。
あ、今自分がかなりごっちゃりと混同した言及をしてそうって感じになった。disはもう止めよう。
jmp、仕方ないような、ライブラリでやるのはなかなかビビるような
SAX, StAXは後者が後発なんだけど、オブジェクト指向に囚われた時代を踏まえるとStAXのような単純なものが後発なのも仕方なかったりするのかな？などと思いを馳せてしまう所がありますね。
（どう単純かはJava6出た頃のStAX解説記事とか見れば一発でわかる）
他の言語では普通に別の名前でありそうな気がするけど、少なくともJavaではSE6を待たねばならなかったらしい。
StAXは結構いろいろ入ってるか。もっと原始的なのはorg.xmlpullか。
うーん結局なんかしょうもなく発散してきた。だめですね
うわ昨日本当にだめだめだったんだな、filter関数書き忘れてデータ壊れてんじゃん
休憩に入った瞬間にMac起こしてXcode起動してるの、境界が無くてアカン
とりあえずクソアホlibxml2.HTMLparserでも使えばみうぱよのツーツもちゃんとパースできるか。
libxml2.xmlreaderは流石にXML用なのでHTMLパースさせたら死んだ
冷静に考えるとrelaxedオプションとかいうHTML読めるようになるフラグが生えてるkXMLみたいなライブラリのほうが変なのかも
kXMLは神なのでHTMLも頑張ってパースできるし、PullParserなので軽いし、なにより全てのAndroidシステムにバンドルされている
libxml2にもHTMLが読めるPullParser入ってほしいよ〜〜〜〜〜〜〜〜(自分で書きたくはない)
えせけん人のせいにするのは良くないですよ あ、でもみたらしは仕方ないか
エラー処理省いてこんくらいでstart elem/end elem/textは読めるんだったら、まぁ悪くは無いけどやっぱり全てのロードが終わるとDOMがメモリ上に完成する仕様が許せねえ
これくらいで済むなら、なんかライブラリをPodから食うんじゃなくてシステムのlibxml2にリンクするだけでちょっと頑張ってもいいかな〜みたいな気持ちにはなれる
これでも結果に不満があったらJ2ObjC勉強してkXMLを変換する所だったので、危ない (それはそれで一度やってみたい)
このアカウントは、notestockで公開設定になっていません。
全く関係ないモデルにコールバック書いて走らねえとか寝言言ってたわ、マジか…
Macのアプリの販売モデルに昔ながらのパッケージ製品を思い出したが、これは別に界隈的なものではなくて、単にWindowsで有償製品買わなすぎるだけかもしれない
このアカウントは、notestockで公開設定になっていません。
おお、あかんな。マイグレで本番を殺しかねないことを考えていた…
macOS版iMastのβ版を公開しました！
まだ現時点では機能がかなり不足していますが、これからバグ修正や機能追加をしていき、8月ごろに正式リリースの予定です。
ダウンロードはこちら → https://github.com/cinderella-project/iMast/releases/tag/5.6b235
(iMast_beta_*****.tgzを展開後、/ApplicationsにD&Dしてから起動してください)
仕事おわったら触ろ、Cocotodonはクソプラグインランタイムとしてしか必要なくなるかもしれん
確かにmikutter利用者が近くにいたら危険だけど、そんな機能ねえよ！
Cocotodon元々mrubyのプレイグラウンドとして書いたものだから実用考えてなかったし、ちゃんとしたプロダクトが出てくるのは待ち望んでいた
このアカウントは、notestockで公開設定になっていません。
デカサーと語りを両対応するのだるい気がするし多少はね
CocotodonのNSTableViewで悩みながら、たびたびYoruFukurouはどうしていたんだろう？って思うんだけど、でもあれって多分Cell basedだからあんまり参考にならない
Krile2使ってた頃までは単行表示に慣れてたはずなのに、今はフルサイズの表示のほうが読みやすいな。
StarryEyesよく考えたら常にフル表示にしてたような気もする
libxml2のvoid*に__bridge void*でObjCの何かしらを投げつけることでやりたい事が簡単にできて便利
気づいたんだけど、Cocotodonもしバイナリ頒布したい場合はライブラリのリンクがむちゃくちゃなことになってるのとアーキの問題を解決しないといけないっぽい
libmrubyをどうやってUniversal対応にするかみたいな
とりあえずCrossBuild定義で2アーキ分つくってあとでがっちゃんこできるのかなあ?
Cocotodonめちゃくちゃ深刻な機能不足を発見した
いちいち右クリックでふぁぼるの非効率、右手で選んでふぁぼらねば
XML_PARSE_NOENTは名前に反してEntityを展開するとかいうクソ脆弱性トラップに引っかかった
What does LIBXML_NOENT do (and why isn't it called LIBXML_ENT)? https://stackoverflow.com/q/38807506?stw=2
自分をNSXMLParserだと主張してNSXMLParserDelegateで結果を通知するSAXパーサーラッパー書いた
