дуров вам не майкрософт окоянный со скайпом

эх

если бы)

todo лист ?

уже сделан)

зачем реверсить? у телеграма апи не открытое чтоль?

Открытое то оно открытое, только вот документация там уже как года 3 не обновлялась

Для golang'а сейчас пишу либу(на самом деле форк другой либы) по 65-й версии протокола. Большую часть инфы подчерпнул именно из чужих клиентов и других библиотек.

Паше видимо просто в лом документацией заниматься. Ну хотябы основная суть API - комуникация с сервером не изменилась.

Открытое то оно открытое, только вот документация там уже как года 3 не обновлялась

С - стабильность

С - стабильность

Зато какой потрясающий квест. Я за месяц успел полазить в PHP, C#, C++, nodejs клиентах и даже в ObjectiveC.

Пока разберешься что как работает кучу всего перекопаешь.

ну можно смело писать в резюме "Fluent php, c#, c++ и вот это все"

?

в голос

а зачем своя либа понадобилась?)

других нет(

Есть

Но я не могу об этом говорить

До сих пор глаз дёргается((

Но я не могу об этом говорить

лол

а зачем своя либа понадобилась?)

Ну на Go была только одна нормальная, но она не поддерживала каналы и мегагруппы. А я только Go месяц назад начал учить и ради fun'а решил её форкнуть и запилить всё по-нормальному. Не уверен, что получилось.

Короче это была моя попытка в Golang разобраться. Итог: https://github.com/shelomentsevd/mtproto

Пока разберешься что как работает кучу всего перекопаешь.

Я изучил оптимизацию в V8, нестандартную криптографию, бинарные протоколы, воркеры, TypedArrays, asm.js и жутко упоротый функциональный язык от братана дурова, матемматика, который посчитал, что описывать api на самоделе с dependent types — это хорошая идея

На самом деле просто в телеграмме не хватает спам-ботов которые будут читать переписку в каналах и стучаться тебе в личку с абсурдными объявлениями по увилечению всего и вся?

На самом деле просто в телеграмме не хватает спам-ботов которые будут читать переписку в каналах и стучаться тебе в личку с абсурдными объявлениями по увилечению всего и вся?

ещё как хватает

только они в чаты ходят

На самом деле просто в телеграмме не хватает спам-ботов которые будут читать переписку в каналах и стучаться тебе в личку с абсурдными объявлениями по увилечению всего и вся?

Я наоборот сразу решил, что раз такая либа нарушает баланс сил, то первым же делом надо выпустить на её основе бота, который будет банить всю эту чернь прямо пачками ?

только они в чаты ходят

А чего не ходят?

Я наоборот сразу решил, что раз такая либа нарушает баланс сил, то первым же делом надо выпустить на её основе бота, который будет банить всю эту чернь прямо пачками ?

Я вот думаю может замахнуться на самописный сервак телеграмма на go, но это же ппц задача

Хотя протокол вроде уже разобран

Я наоборот сразу решил, что раз такая либа нарушает баланс сил, то первым же делом надо выпустить на её основе бота, который будет банить всю эту чернь прямо пачками ?

+

А чего не ходят?

а блин. частицу "не" упустил

Я вот думаю может замахнуться на самописный сервак телеграмма на go, но это же ппц задача

Ооо это как надо упороться чтобы писать сервер телеграма

Ооо это как надо упороться чтобы писать сервер телеграма

Ну это на крайний случай задача. Когда делать совсем нечего будет. Подозреваю, что там надо всю библиотеку перелопачивать для написания сервера.

Сериализацию с dependent types на языке без дженериков)

Сериализацию с dependent types на языке без дженериков)

лол

Сериализацию с dependent types на языке без дженериков)

А нах тебе дженерики, если интерфейсов достаточно? в целом это те самые дженерики и получаются

Кастанёшь зависимые типы через interface{}?)

type Serializer interface { Serialize() string } и просто для своих типов переопределяешь Serialize() и потом пишешь в своей либе сериализации что она на вход Serializer принимает. конец

Погоди, это типы

Они объединяются в тайп классы

Всё это создаётся каррированными конструкторами типов

Перегруженными, разумеется

ну так, ты потом делаешь типа type MyType struct {...} func (m *MyType) Serialize() string {...} и все, его уже спокойно сериализовать можно чем хочешь

или я тебя не понимаю

ну то есть

я бы понял, если бы ты сказал, что dependent types без генериков охуеешь делать

А над всем этим уже находятся зависимые типы, которые декларируют, что отношение между этими сущностями — тоже отдельный тип

но если ты их уже сделал, то сериализовать их не проблема

я бы понял, если бы ты сказал, что dependent types без генериков охуеешь делать

Нет конечно.

Ты офигеешь делать их и с ними

Кастанёшь зависимые типы через interface{}?)

https://github.com/shelomentsevd/mtproto/blob/master/types.go#L5 - интерфейс https://github.com/shelomentsevd/mtproto/blob/master/api.go#L274 - пример сериализации https://github.com/shelomentsevd/mtproto/blob/master/api.go#L20831 - пример десериализации файл api.go генерируется скриптом на python: https://github.com/shelomentsevd/tl2go

)))

ну короч тут я согласен

всё работает, но есть заебы кое-какие

я про сериализацию несогласен был

всё работает, но есть заебы кое-какие

С выходом новой версии API все заново генерировать. Я сейчас думаю, что лучше отказаться от идеи описания всего API, оставить структуры и минимальную документацию как этим пользоваться и всё.

С выходом новой версии API все заново генерировать. Я сейчас думаю, что лучше отказаться от идеи описания всего API, оставить структуры и минимальную документацию как этим пользоваться и всё.

описание всего API всмысле документация?

С выходом новой версии API все заново генерировать. Я сейчас думаю, что лучше отказаться от идеи описания всего API, оставить структуры и минимальную документацию как этим пользоваться и всё.

Оно всё обобщается, но какая-никакая мощность языка для этого всё равно нужна

описание всего API всмысле документация?

Не. https://github.com/shelomentsevd/mtproto/blob/master/mtproto.go#L356 - вот типичный вызов метода для API телеграмма который я уже сделал. По сути они все одинаковые, ты просто передаешь в канал m.packetToSend определенную структуру с параметрами и на выходе получаешь другую структуру. Вот думаю просто показать в README как это делать а методы типа выше удалить оттуда.

Иначе просто замучаешься всё это делать. Там например от версии к версии ещё порядок полей может измениться или их кол-во и придется всё переписывать заново, т.к. (де)сериализация зависит от порядка и их кол-ва.

короч пора в чатик про го идти реакт обсуждать

Иначе просто замучаешься всё это делать. Там например от версии к версии ещё порядок полей может измениться или их кол-во и придется всё переписывать заново, т.к. (де)сериализация зависит от порядка и их кол-ва.

генерируй из схемы

генерируй из схемы

Ну вот да. Это как вариант, сделать генерацию получше

Иначе просто замучаешься всё это делать. Там например от версии к версии ещё порядок полей может измениться или их кол-во и придется всё переписывать заново, т.к. (де)сериализация зависит от порядка и их кол-ва.

Из схемы можно вообще кучу информации извлечь, я сделал автоматическую сортировку полей по схеме, сделал defaults значения для типов, можно опускать ненужные поля, теперь работаю чтобы париться о типах ещё меньше)

Из схемы можно вообще кучу информации извлечь, я сделал автоматическую сортировку полей по схеме, сделал defaults значения для типов, можно опускать ненужные поля, теперь работаю чтобы париться о типах ещё меньше)

А зачем сортировку?

ERROR: S client not available

Затем чтобы юзер не парился, в каком порядке там поля в схеме)

Модуль сам расставит как надо, да ещё и пропущенные аргументы заполнит

Это я в час Go lang попал? ))

Затем чтобы юзер не парился, в каком порядке там поля в схеме)

Всё понял?

Сорян за Golang. Я просто увидел что тут тему telegram api обсуждают

Это я в час Go lang попал? ))

го Clojure обсуждать параллельно, пусть им обидно будет

Будем Idris с TL обсуждать тогда ? @ZeroBias

можно еще шлюх тамбовских, но кажется, это уже совсем оффтопик

с другой стороны что угодно лучше, чем очереное jss vs styled components

с другой стороны что угодно лучше, чем очереное jss vs styled components

теперь уже styled-jss vs styled-components ?

а, да, было тут что-то такое

точно

jss-components vs styled-styled

prejss-components vs styled-prejss

jss vs components

теперь уже styled-jss vs styled-components ?

Чё?

Чё я снова пропустил?

кто-то написал либку, чтобы jss как styled components писать

и кинул сюда репку

Но зачем?

вопросы к сове и ко

мб они еще объяснят зачем jss вообще нужен

но пока у них ниоч выходит

Они настолько по-разному работают, чтобы это имело смысл?

смысл насколько я понял в инкапсуляции

но мб нет

мб они еще объяснят зачем jss вообще нужен

Не, ну JSS — тема.

всем привет) зарелизили styled-jss - интерфейс styled-components, скорость и фичи jss)) буду рад фидбэку)) https://github.com/cssinjs/styled-jss

на втыкай

Вот был бы автокомплит для JSS.

никто тебе не мешает плагин свой для VSCode и идеи написать с автокомплитом =))

Мешает.