vladislav
игрушечный язык для игрушек
vladislav
всё логично
kitsu
плагины точенные или стабилити хваленая
kitsu
Stable or Nightly? nightly – 39 👍👍👍👍👍👍👍 74% stable – 14 👍👍👍 26% 👥 53 people voted so far.
ㅤ
Найтли не так страшен, как его малюют
Alexander
Смотря для чего конечно наверное.
kitsu
конечно наверное
Alexander
Вопрос по расту можно?
Alexander
Есть serde, есть chrono есть bincode. Serde имеет свои какие-то сериализации, бин-код свои и serde ещё свой реализует.
Alexander
Я через бин-код сеарилизую datetime из chrono, и, похоже, он сериализуются как строка, как это описано в самом chrone.
Alexander
Вопрос, или я не понимаю: как его заставить сериализоваться не через свой метод, а в бинарный формат из структуры? как это bincode по идее и делает для обычных структур.
でゲソ
to_bytes?
Andrey
https://github.com/chronotope/chrono/blob/master/src/datetime.rs#L942 это воля chrono сериализоваться как строка.
Alexander
Chrono его вроде не реализует.
Alexander
Ещё не пойму зачем в chrono упоминается bincode, с какой стати тогда.
Andrey
ну так serde устроен. сериализатор конкретного типа не знает о формате. он как бы описывает из каких примитивов он состоит. в chrono решили, что это строка. но если поменять эти impls на что-то другое, то будет беда. для всяких json, yaml и прочих поменяется представление.
Alexander
Ок, а можно как-то не долго мучаясь bincode натравить на структуру да ещё с приватными полями?
Alexander
По факту naivedatetime это три числа + зона ещё одно. Оно даже внутри так описано.
Alexander
Наверное хотел бы подчеркнуть _не долго мучаясь_ потому как понятно что можно сделать свою структуру, перетащить туда и т.д.
Andrey
если фиксить chrono, то нужно добавлять дробные секунды. если чисто у себя в приложении завести, то можно сделать свой тип struct ProperDateTime<Z > ( DateTime<Z>); и уже для него самостоятельно сделать реализации Serializer и Deserializer
Cuno
учитывая, что эти поля на самом деле доступны (через функции)
Andrey
оно сохранится так как будет сказано в Serialize
Andrey
ну и для de лучше брать DeserializeOwned а не Deserialize чтоб ещё не заблудиться в лайфтаймах
Alexander
Но если ничего не добавлять - то bincode структуру сохранит норм, но сама дата уже через хроновский сериализер пойдёт?
Andrey
если сделать свой тип, то сериализация "сломается".
Alexander
Т.е. свой сериализер писать :(
Andrey
ага
Alexander
если сделать свой тип, то сериализация "сломается".
Я понял, только извиняюсь, не понял почему.
Ilya
почему мне кажется что вы какие-то тяжелые наркотики обсуждаете? В чем вообще проблема?
Alexander
newtype
Пойду почитаю про это.
Andrey
потому что трейты Serialize и Deserialize для него не реализованы
Andrey
newtype это и есть struct ProperDateTime<Z > ( DateTime<Z>)
Cuno
почему мне кажется что вы какие-то тяжелые наркотики обсуждаете? В чем вообще проблема?
В том, что дата сохраняется как строка, когда можно как 3 числа (короче, проще, быстрее).
Alexander
потому что трейты Serialize и Deserialize для него не реализованы
Но я из задеривлю как и для любой своей самописной структуры.
Andrey
... и получится та же строка :)
Alexander
Потому что bincode дёрнет сериализер хроновский. Ясно-понятно. Спасибо.
Andrey
В том, что дата сохраняется как строка, когда можно как 3 числа (короче, проще, быстрее).
если не строка, то в какой-нибудь json попадало бы [1234, 12345, 123456
Alexander
Ну просто не очевидно почему строка - это дефолтное, а не наоборот. Хотя конечно более универсально.
Cuno
Потому что при сериализации даты ты ожидаешь увидеть дату, а не какие-то 3 числа.
Cuno
serde абстрактен по формату
Αλεχ
В json да, не в json - нет.
512 56782 282 - это какая дата?
Andrey
кому-то приходится подвинуться. json нужнее. а bincode это только для Servo
Alexander
512 56782 282 - это какая дата?
Какая-то распарсить и посмотреть.
Alexander
кому-то приходится подвинуться. json нужнее. а bincode это только для Servo
Да, причина в общем-то понятно. Абстрактные надо бы разные сериализация иметь глобально - для json и для bin.
Alexander
Или в bincode реализовывать.
պլհկ
что реализовывать
Alexander
Бинарный сериализтор для хрона
պլհկ
он не знает ни про какой хроно
Andrey
как и хроно про бинари
Alexander
Ну да, но мог бы по идее и знать.
Alexander
Ладно, это не важно.
պլհկ
у хроно есть метод serialize(ser: S) where S: Serializer
Αλεχ
Какая-то распарсить и посмотреть.
А какая дата 2016-01-01T12:24:45+03:00?
պլհկ
и он вызывает ser.serialize_str(..)
Alexander
պլհկ
ну а зачем чушь говорить тогда
պլհկ
если все ясно
Cuno
у хроно есть метод serialize(ser: S) where S: Serializer
Хм, кажется специализация может помочь.
Andrey
нет. нелься реализовать чужой трейт для чужого типа
Andrey
они в разных крейтах же.
Alexander
ну а зачем чушь говорить тогда
Я о том же о чем sad cat сейчас написал - не очевидно почему тестовый формат дефолтное и нет специализации. Т.е. оно могло бы быть и по другому, но как есть так и есть. Так что я не согласен что прямо уж чушь.
Alexander
Ок, я обратно. Вопрос: может есть не особо unsafe метод чтобы просто это приватное всё через bincode прогнать и не использовать хроновский сериализатор?
Маjко
Товарищи, помню, была статья, объясняющая почему закинули старую систему расширений в пользу WebExtensions
Andrey
не использовать chrono::DateTime a f64 ?
Маjко
Можете кинуть?
պլհկ
https://gist.github.com/polachok/fa66e69b528a70a589feea62b4f10b58
Andrey
offset: i32 что за расточительство? :)
Alexander
не использовать chrono::DateTime a f64 ?
Ну просто Хроно удобный. Думаю может timestamp_millis поможет. + offset
Andrey
ну не выйдет без нового типа чтоб и serde и компактная сериализация. уже два варианта предложили.
Andrey
осталось выбрать
Alexander
https://gist.github.com/polachok/fa66e69b528a70a589feea62b4f10b58
Тут миллисекунды потеряны.
պլհկ
ну добавь, мне не нужны они
Alexander
Да, ну в общем понятно. Надо специализировать сериализаторы для него. И посколько оно не даёт доступ к внутренним представлениям - то использовать timestamp_millis + offset.