
Chikiro
11.08.2017
09:42:39
Нас в школе на Лого учили программировать. Рисовать на экране по координатам с помощью заранее написанной программы. Тогда это казалось невероятно крутым. Но в Лого, если правильно помню, не надо команду завершать точкой с запятой.

Sergey
11.08.2017
09:43:32
https://ru.wikipedia.org/wiki/Рапира_(язык_программирования)

b0g3r
11.08.2017
09:44:05
поплан

Dmitry
11.08.2017
09:45:04

Google

Sergey
11.08.2017
09:46:59
Вспомнились "нарисованные" на Pascal новогодние открытки с анимацией и мелодией на PC-спикере ?

Chikiro
11.08.2017
09:55:28

Dmitry
11.08.2017
09:57:42
там значёк python
и вообще это pycharm?)

Ruslan
11.08.2017
09:58:04

Dmitry
11.08.2017
09:58:26
угу

Ruslan
11.08.2017
09:58:27
а хотя и питона
и css

Roman
11.08.2017
10:14:26
Пятничный вопрос: в tcp сокет записали 4 раза по 256 байт. Сколько будет прочитано на другой стороне?

Dmitry
11.08.2017
10:17:56
)))
Алгоритм Нейгла все дела

Roman
11.08.2017
10:19:20

Dmitry
11.08.2017
10:21:34
думаю в большинстве случаев прочитаешь 1024 :)

Google

Roman
11.08.2017
10:21:59

Dmitry
11.08.2017
10:22:29
)) по сколько приходит?

Roman
11.08.2017
10:23:49
Ты же не знаешь сколько места в буфере на той стороне

Dmitry
11.08.2017
10:24:57
у нас для гарантии прихода определённого количества байт использовался RUDP.

Roman
11.08.2017
10:55:11
хехе ))

Александр
11.08.2017
10:56:18
Такой вопрос, как лучше сделать? Что удобнее на практике?
Есть некоторая структура, которая определяет как-то найденный диапазон видео кадров. begin-end
class FrameRange(typing.NamedTuple):
begin: int
end: int
begin_time: float
end_time: float
end лучше задавать как последний кадр + 1 (как в итераторах) или как просто последний кадр?
Например, SRE_Match из re определяет span как (start, end+1), чтобы удобно было брать срез: s[match.start():match.end()].
Мне кажется, что сперва нужно понять как раз, как это должно на практике использоваться.
На данный момент я не вижу смысла делать + или -.
Если мы разобьем видео на блоки, то более очевидно, если мы конец блока считаем именно эту позицию, а не другую.
Тогда второй блок, следующий за данным, будет идти с +1.


Eugene
11.08.2017
11:04:35
Да, тут мы получаем диапазон кадров, который удовлетворяет каким-то параметрам, например там какая-то сцена или ещё что-нибудь. Нам не нужно потом итерироваться по этим кадрам. Мне кажется, разумнее конец блока задавать именно как конец блока, а не последний кадр + 1.

Александр
11.08.2017
11:05:56

Юра
11.08.2017
11:21:42
Всем доброго времени суток. Подскажите, как можно получить объект datetime (py3) из строки в формате типа 'August 10, 2017'?

b0g3r
11.08.2017
11:22:05
strptime в такое не умеет?
%B %d, %Y
https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior

Юра
11.08.2017
11:23:21
попробовал datetime.strptime('August 10, 2017', '%b %d, %Y') - не работает

Sergey
11.08.2017
11:23:22

b0g3r
11.08.2017
11:23:49
юзай %B

Dmitry
11.08.2017
11:24:04
strftime.org

Юра
11.08.2017
11:24:08
спасибо, попробую

Google

b0g3r
11.08.2017
11:25:44
%d это не zero-padded?
таки zero-padded, но в тз про это ни слова
если нужно ещё обрабатывать типа August 1, то %d -> %-d

Sergey
11.08.2017
11:26:59
таки zero-padded, но в тз про это ни слова
если нужно ещё обрабатывать типа August 1, то %d -> %-d
А кстати с %d тоже работает, потестил
>>> datetime.strptime('August 1, 2017', '%B %d, %Y')
datetime.datetime(2017, 8, 1, 0, 0)

b0g3r
11.08.2017
11:27:06
Хотя вот гугол говорит что будет работать
https://stackoverflow.com/a/25280059/8324474

amureki
11.08.2017
11:30:01
я https://github.com/kennethreitz/maya использовал в последнем проекте для парсинга
что-то вроде maya.parse(date)

Aleksander
11.08.2017
11:32:13
https://www.codota.com/
Пока что для джавы только

amureki
11.08.2017
11:33:04
питонисты еще пока достаточно умны писать самостоятельно?)

b0g3r
11.08.2017
11:34:44
умных парсеров для времени много)

Sergey
11.08.2017
11:43:18
Stack Overflow Driven Development выходит на новый уровень

Andrey
11.08.2017
12:00:48
Пятничное
https://twitter.com/i/moments/871564334832304128

Serge
11.08.2017
17:28:20

Dmitry
11.08.2017
17:30:05
почему не C++?) с крестами)

Serge
11.08.2017
17:30:44

Chikiro
11.08.2017
17:33:48

Dmitry
11.08.2017
17:34:47
C#?

Google

Mikhail
11.08.2017
18:34:17
А что с bar hopping?

Vitali K.
11.08.2017
18:35:04
Сегодня?
Я на Невском
Если че

Aleksander
11.08.2017
18:39:10
Мы идём на Рубика

Dmitry
11.08.2017
18:48:20
рубинштрассе, 24

Aleksander
11.08.2017
18:52:53
Если это панк брю то да

Dmitry
11.08.2017
18:53:15
это бар.слона

Admin
ERROR: S client not available

Sergey
11.08.2017
18:54:19
Черт

Aleksander
11.08.2017
18:57:09
А что в баре слона ?

Vitali K.
11.08.2017
18:57:30
Так куда идти?))
Есть какой-то алколидер?

Dmitry
11.08.2017
19:06:41

Michael
11.08.2017
19:44:10
Эээээ а вы где?
Бухаааетеее?

Aleksander
11.08.2017
20:40:48
Панк брю
Теперь уже в крабсбургере

Roman
11.08.2017
21:39:11

Gregory
11.08.2017
22:02:57
http://us.battle.net/sc2/en/blog/20944009

Google

Gregory
11.08.2017
22:03:26
Покруче будет чем скриптовать майнкрафт.
https://github.com/deepmind/pysc2

Dmitry
11.08.2017
22:06:55

Eugene
11.08.2017
22:12:06
Есть знатоки ffmpeg? Декодер H.264 там многопоточный?
Ковыряюсь тут с одной задачкой обработки видео. Попробовал заюзать мультипроцессинг и... ничего. :)
Однопроцессорный код:
3836 tests/data/Test_30.mp4 7.01s
3836 tests/data/Test_31.mp4 5.89s
3836 tests/data/Test_32.mp4 7.69s
3836 tests/data/Test_33.mp4 7.55s
28.64s
Многопроцессорный код (4 воркера):
7204 tests/data/Test_31.mp4 13.34s
7548 tests/data/Test_30.mp4 19.32s
7228 tests/data/Test_33.mp4 21.22s
3580 tests/data/Test_32.mp4 21.29s
22.21s
То есть совершенно бесполезно использовать мультипроцессинг в данном случае :(.

Dmitry
11.08.2017
22:16:26
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/utils.c#L2970
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/utils.c#L3584
похоже они форсят 1 поток.

Gregory
11.08.2017
22:16:44

Eugene
11.08.2017
22:18:45

Roman
11.08.2017
22:44:58
Оно ж dso и плодить процессы смысла нет

Eugene
11.08.2017
22:46:48

Roman
11.08.2017
22:50:11
Декодировать можно и на gpu(они делают это очень быстро)

Eugene
11.08.2017
22:52:16
Думаю, что декодирование. Чтение не должно занимать много времени на SSD.
По крайней мере сейчас процессор на 100% нагружает ffmpeg. Значит декодирование.
Тоже думал про GPU

Roman
11.08.2017
22:53:05

Eugene
11.08.2017
22:53:36
Под 90%.

Roman
11.08.2017
22:53:36
Короче, лучше gpu
Ну и профайлер :)

Eugene
11.08.2017
22:55:05
Я сейчас использую вот это для чтения
http://www.scikit-video.org/stable/index.html
Оно просто дёргает ffmpeg через subprocess. Возможно, какое-то время тратится на конвертацию в numpy.