Под ci я подразумеваю всю ферму, а не только гитлаб )

Все , догнал) начинали вроди про приватные репозитории вот и осталось а голове )

Все , догнал) начинали вроди про приватные репозитории вот и осталось а голове )

Приватные репы легко получить из Github: Students pack

Приватные репы легко получить из Github: Students pack

Ну да, если ты студент

Приватные репы легко получить из Github: Students pack

Битбакет )

Битбакет )

*Бичпакет

Снова ты

Что не так?)

Просто я уже слишком много бичпакетов сожрал

ыл

Ну да, если ты студент

Или школьник

Объясните в чём суть таких сообщений: /me и других после слеша, я прост с вконтакте)

Объясните в чём суть таких сообщений: /me и других после слеша, я прост с вконтакте)

/me > я "выполняю какое то действие"

допустим

/me взял камушек

А зачем это надо?

ПРОСТО ТАК

В основном используется для отыгровки внутри-игрового персонажа если нет анимаций данного действа

/me взял камушек

/me это из ирки пошло

/me это из ирки пошло

¯\_(ツ)_/¯

А тут эти команды используются для обращения к ботам

В основном используется для отыгровки внутри-игрового персонажа если нет анимаций данного действа

>Игрового" , тут есть игры???

Не тут, а вообще

Например те-же RP сервера игр(Arma 3, SAMP/MTA)

>Игрового" , тут есть игры???

А вообще - в любом мессенджере можно сделать чат-игру

более чем

А вообще - в любом мессенджере можно сделать чат-игру

Можно поподробней об этом?

Бля, обьясните ему

я тут сериал смотрю(

Это дохуя времени проебется

Можно поподробней об этом?

Извини, он сериал смотрит, пока не может объяснить

Бля, обьясните ему

Сделано

Тут нельзя стикеры вроди

Так что осторожнее)

Я ж без флуда.

Объясните в чём суть таких сообщений: /me и других после слеша, я прост с вконтакте)

в irc так можно было писать от третьего лица, в телеграме со слеша начинаются команды ботов

да не только в irc

да не только в irc

Помню времена xmpp

йеп

создал канал по фласку @pyflask

создал канал по фласку @pyflask

и по бутылке @pybottle )))

https://github.com/KeepSafe/aiohttp/issues/858#issuecomment-217753659

https://goo.gl/nsxabH

https://www.youtube.com/watch?v=BFZdBaIO0ac

https://www.youtube.com/watch?v=BFZdBaIO0ac

баянище

Всем привет! Делаю одно сетевое приложение, все на UDP Протокол такой: хэдер 50 байт потом данные Когда писал через TCP читад хэдер, оттуда узнавал сколько байт надо еще считать Сейчас при втором recvfrom() программа блочиться Как быть?

через ioctl с FIONREAD узнавать, сколько доступно на чтение. Или читать неблокируемо

через ioctl с FIONREAD узнавать, сколько доступно на чтение. Или читать неблокируемо

Я отправляю одни пакет в 100 байт Читаю 50 - все ок Читаю еще 50 - не работает Куда-то пропадают 50 байт

А трафик сниферили? Всё проходит?

ERROR: S client not available

эм

А трафик сниферили? Всё проходит?

Ага, все проходит внутри одной машины

If a message is too long to fit in the supplied buffer, excess bytes may be discarded depending on the type of socket the message is received from.

э

это из man recvfrom

100 байт)

поэтому "куда-то" это вполне задокументированное "выброшено нафиг"

нет, "читаю 50"

это и есть - передан буфер в 50 байт

остальное может быть выброшено

а как тогда считать сначала хэдер и потом считать еще кусок пакета?

http://stackoverflow.com/questions/675812/successive-calls-to-recvfrom-loses-data

считать все, потом в считанном взять хэдер, потом остальное

это примерно как вместо scanf для заполнения кучи переменных делать сначала считывание всей строки, а потом sscanf по ней

считать все, потом в считанном взять хэдер, потом остальное

но так можно считать лишнее?

лишнего не будет. Все, что не считано, будет потеряно

значит добавлю еще один внутрений буфер спасибо!

или точнее "может быть выброшено"

собственно с UDP все реально не так сложно

один recvfrom читает 1 пакет. Сколько буфера дали, столько читает, остальное выбрасывает

... кстати полезно знать, потому что мне после праздников предстоит плотно заниматься UDP

http://stackoverflow.com/questions/2862071/how-large-should-my-recv-buffer-be-when-calling-recv-in-the-socket-library

SOCK_DGRAM: Use a buffer large enough to hold the biggest packet that your application-level protocol ever sends. If you're using UDP, then in general your application-level protocol shouldn't be sending packets larger than about 1400 bytes, because they'll certainly need to be fragmented and reassembled.

один recvfrom читает 1 пакет. Сколько буфера дали, столько читает, остальное выбрасывает

recvfrom вроде не пакеты читает а данные что пришли и я имел ввиду свой пакет который поверх UDP

SOCK_DGRAM: Use a buffer large enough to hold the biggest packet that your application-level protocol ever sends. If you're using UDP, then in general your application-level protocol shouldn't be sending packets larger than about 1400 bytes, because they'll certainly need to be fragmented and reassembled.

ага) я уже попался на этом :D