От такого количество новых вещей голова разрывается

а откуда инфа? я когда проверял этого не заметил

Тестировал. Если сервер поддерживает Keep-Alive, то соединение остаётся живо в течение минуты, по нему продолжают приходить апдейты.

ну так телеграм не шлет 'keep-alive' в хидерах

как?

Не шлёт, но и не должен. В HTTP/1.1 keep-alive по умолчанию включен и заголовок нужно добавлять, только если keep-alive не поддерживается.

Да, но когда я проверял, телеграм слал хидер "close"

сегодня перепроверю и отпишусь

хэдер*

Много кто говорит «хидер»

От слова "head"

Заголовок

Нескромный вопрос, чем getUpdates лучше вебхуков?

М, cloudflare?

?

Я просто ниразу ничего не делал с getUpdates, только с хуками, вот и вопрошаю)

хэдер*

хуедер )

Я просто ниразу ничего не делал с getUpdates, только с хуками, вот и вопрошаю)

Я часто перезагружаю сервер, и после этого приходилось перезапускать ботов, которые на getUpdates работали И они там через while(1){ работали } А теперь не перезапускаю Но это наверно глупо было, возможно можно было один раз настроить включение ботов при ребуте, но я не знаю как И тогда не гуглил

)

хуедер )

Он сам перезапускается

Ну это да

Поэтому я его и перезапускал

а правда, что боты на поллинге пизже тех, что на веб-хуках?

А я могу как-то со стороны бота заблокировать юзера? Чтобы он вообще писать не мог

А я могу как-то со стороны бота заблокировать юзера? Чтобы он вообще писать не мог

не отвечать ему, как вариант

а правда, что боты на поллинге пизже тех, что на веб-хуках?

если они на php, то нет Мой обрабатывал всех по очереди, используя чужое апи, и при очереди в 100 человек последний в очереди получал сообщение через 50-100 секунд

А если на node то быстро все

Не шлёт, но и не должен. В HTTP/1.1 keep-alive по умолчанию включен и заголовок нужно добавлять, только если keep-alive не поддерживается.

Странно, может я прошлый раз не так проверял, но хуки умеют в keep-alive Хидеры телеграма 'content-type': 'application/json', 'content-length': '388', connection: 'keep-alive', 'accept-encoding': 'gzip, deflate'

Лол

Доброе утро, народ! Есть кто знакомый с telegram-cli тут? Кто имеет возможность подсказать там по коду, или взяться сделать одну небольшую правку в нем? Нужно самую малость поковыряться в коде и переписать формат в котором приходят сообщения, изменив чуть-чуть schema.tl. Подробнее в личку, спасибо!

Доброе утро, народ! Есть кто знакомый с telegram-cli тут? Кто имеет возможность подсказать там по коду, или взяться сделать одну небольшую правку в нем? Нужно самую малость поковыряться в коде и переписать формат в котором приходят сообщения, изменив чуть-чуть schema.tl. Подробнее в личку, спасибо!

так спросите здесь

Тогда с вашего позволения кратко здесь опишу суть вопроса. https://github.com/vysheng/tgl/blob/ffb04caca71de0cddf28cd33a4575922900a59ed/scheme.tl - вот что использует оригинальный telegram-cli. Собственно интересует нас здесь вот какой кусок: message#c992e15c flags:# unread:flags.0?true out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true id:int from_id:flags.8?int to_id:Peer fwd_from_id:flags.2?Peer fwd_date:flags.2?int via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int = Message; а если быть точным то даже вот этот: fwd_from_id:flags.2?Peer fwd_date:flags.2?int К сути проблемы. Как мы видим, забирая пересланное сообщение telegram-cli видит от кого оно, и забирает данные о том когда был опубликован оригинал, но при этом он не забирает никакого id оригинального сообщения. Что по сути делает невозможным идентифицировать как-либо оригинал. Однако такая возможность есть - так например если вы нажмете в своем клиенте на любой пост который вам переслали из канала, вы перейдете в канал именно к этому посту. Покопавшись я обнаружил вот что: https://raw.githubusercontent.com/telegramdesktop/tdesktop/master/Telegram/SourceFiles/mtproto/scheme.tl это версия schema.tl которая используется в tdesktop, и в ней message выглядит иначе: message#c09be45f flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int = Message; как видим тут уже забирается оригинальное сообщение в некий MessageFwdHeader которого вообще в telegram-cli нет. Выглдит он так: messageFwdHeader#c786ddcb flags:# from_id:flags.0?int date:int channel_id:flags.1?int channel_post:flags.2?int = MessageFwdHeader; и в нем как мы видим есть заветный channel_post -> который по всей видимости и хранит тот заветный id оригинального сообщения. Собственно, задача сделать так, чтобы этот channel_post для пересланных сообщений в итоге отдавался в json'е при запросе history, get_message и т.д. вместе с остальными данными. Как-то так.

Тогда с вашего позволения кратко здесь опишу суть вопроса. https://github.com/vysheng/tgl/blob/ffb04caca71de0cddf28cd33a4575922900a59ed/scheme.tl - вот что использует оригинальный telegram-cli. Собственно интересует нас здесь вот какой кусок: message#c992e15c flags:# unread:flags.0?true out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true id:int from_id:flags.8?int to_id:Peer fwd_from_id:flags.2?Peer fwd_date:flags.2?int via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int = Message; а если быть точным то даже вот этот: fwd_from_id:flags.2?Peer fwd_date:flags.2?int К сути проблемы. Как мы видим, забирая пересланное сообщение telegram-cli видит от кого оно, и забирает данные о том когда был опубликован оригинал, но при этом он не забирает никакого id оригинального сообщения. Что по сути делает невозможным идентифицировать как-либо оригинал. Однако такая возможность есть - так например если вы нажмете в своем клиенте на любой пост который вам переслали из канала, вы перейдете в канал именно к этому посту. Покопавшись я обнаружил вот что: https://raw.githubusercontent.com/telegramdesktop/tdesktop/master/Telegram/SourceFiles/mtproto/scheme.tl это версия schema.tl которая используется в tdesktop, и в ней message выглядит иначе: message#c09be45f flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int = Message; как видим тут уже забирается оригинальное сообщение в некий MessageFwdHeader которого вообще в telegram-cli нет. Выглдит он так: messageFwdHeader#c786ddcb flags:# from_id:flags.0?int date:int channel_id:flags.1?int channel_post:flags.2?int = MessageFwdHeader; и в нем как мы видим есть заветный channel_post -> который по всей видимости и хранит тот заветный id оригинального сообщения. Собственно, задача сделать так, чтобы этот channel_post для пересланных сообщений в итоге отдавался в json'е при запросе history, get_message и т.д. вместе с остальными данными. Как-то так.

заведите багу ни гитхабе, может кто сделает

заведите багу ни гитхабе, может кто сделает

Да там проект скорее мертв чем жив, абсолютно бестолку :(

import schedule

Можно ли на python написать что-нибудь на linux и запустить без изменений и установки пакетов через pip на macos?

Да

Можно

даже если надо делать http-request?

Если использовать стандартные либы

UrlLib гапример

если нужны пакеты, то их скорее всего можно поставлять с комплекте с программой

если нужны пакеты, то их скорее всего можно поставлять с комплекте с программой

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

да так, чтоб оно запустилось

если они чисто на питоне, без нативных расширений - то их можно тупо скопировать, иначе придется кросс-компилировать расширения

а на macos так туго с pip ?

ах да, можно еще скомпилировать расширения на самой macos

я хочу упростить клиенту жизнь, и усложняю ее себе

клиенту же еще питон надо ставить :D

хотя да, *установите питон3 с сайта питона, пропишите в консоли pip install a b c d e, и python *путь к файлу**

в макоси какой-то питон вроде даже есть, но по-моему не тот, что я хочу иметь

можно bash-скрипт написать, который сам все устанавливать будет

а как там в макоси путь к башу? #/bin/env bash ?

опять-таки, чтобы установить python автоматически через bash, этот скрипт надо будет тестировать :< аррр

а как там в макоси путь к башу? #/bin/env bash ?

#!/bin/bash должно сработать

Но есть же готовые тулзы, типа pex. https://github.com/pantsbuild/pex

A DDoS attack on the Bot API is in progress. Hang on tight, we're fighting back.

Но есть же готовые тулзы, типа pex. https://github.com/pantsbuild/pex

Мои проблемы с pip и python превратятся в проблемы с pex и tox

Решил просто использовать по-максимуму стандартный питон без дополнительных пакетов

Не, ну если вы так заранее все знаете... то зачем спрашивать? )

Не, ну если вы так заранее все знаете... то зачем спрашивать? )

я не знаю, я проанализировал pex после того, как вы его предложили

хотя... Надо поглубже покопать на самом деле, вроде после танцев с pex и tox в продакшн не надо их ставить. Но про продакшн на macos при хосте на linux не уверен

Из стандартной поставки можно попробовать упаковать все в https://docs.python.org/3/library/zipapp.html. Но интерпретатор все равно придется тянуть.

> You can also build pex in a git clone using tox: Никто ж не обязывает.

> Build a standalone pex binary into pex.pex using the pex console_scripts entry point: > $ pex pex -c pex -o pex.pex Я бы сказал, что сам pex на проде тоже не нужен.

Ибо standalone.

интерпретатор у клиента есть, python2.7 по умолчанию в макоси стоит. Я просто не уверен, насколько можно издеваться над клиентом требованиями что-то ставить и консолить

А в своем умении написать bash-скрипт, который безошибочно и 100% запустится на макоси, не уверен

Тогда с минимальными потерями можно попробовать все запаковать в zipapp.

Там идея такая. ZIP-формат пропускает все, что расположено до заголовка ZIP. В начало пишется что-то вроде #!/usr/bin/env python; exit 0, затем все модули, запакованные в ZIP. Интепретатор умеет запускать пакет из архива. Если там будут все зависимости, то скорее всего, прокатит.

Ну и на архив ставится chmod +x.

Тогда оно типа само запускается как бинарник.

ну и linux с макосью бинарно несовместимы

А это к чему?

Тогда оно типа само запускается как бинарник.

если бинарные пакеты вставить в архив, они не станут совместимы со всеми осями

Это да, но без использования сторонних утилит или вынуждения юзера консолить вы кроссплатформенность вряд ли получите.

мда... Значит, только KISS, только хардкор, только (хорошо хоть) установленный у клиента python2.7, установленный у него же pip и всё. А лучше даже без pip

А почему все-таки не pex/py2exe/whatever?

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

интерпретатор у клиента есть, python2.7 по умолчанию в макоси стоит. Я просто не уверен, насколько можно издеваться над клиентом требованиями что-то ставить и консолить

Может быть просто всё упаковать в пакет и воспользоваться модулем setuptools

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

бинарная часть читстого питона и его стандартной библиотеки есть у клиента

pex не кросскомпилирует