При сборке Python биндинга крутой библиотеки StarSpace получил такую ошибку:

Traceback (most recent call last):
  File "test.py", line 1, in 
    import starwrap as sw
ImportError: /www/home/mntlp/Starspace/python/test/starwrap.so: undefined symbol: _Py_ZeroStruct

Возникает она потому, что я в данный момент работаю под anaconda, а биндинг собрался под другую версию Python. Пофиксить несложно. Открываем CMakeLists.txt и в начала файла, после строки

project(starspace)

устанавливаем пути к библиотекам и инклудам нужного нам питона:

set(PYTHON_LIBRARY "/home/user/anaconda3/lib")
set(PYTHON_INCLUDE_DIR "/home/user/anaconda3/include/python3.6m/")

А если работаем под виртуальной средой в anaconda, то вместо предыдущих путей нужно указать путь через нее:

set(PYTHON_LIBRARY "/home/user/anaconda3/envs/env_name/lib")
set(PYTHON_INCLUDE_DIR "/home/user/anaconda3/envs/env_name/include/python3.6m")

Дальше:

cd ./build
cmake --build .
cd -
cp ./build/starwrap.so ./test
cd test
python3 test.py

В общем, все как было в build.sh до возникновения ошибки.

Забавная опечатка в официальной инструкции Nvidia по сборке ffmpeg для работы с CUDA.

Пишут, что для конфигурации надо сделать:

./configure --enable-nonfree -–enable-cuda-sdk –enable-libnpp --extra-cflags=-I/usr/local/cuda/include --extra-ldflags=-L/usr/local/cuda/lib64

Если это нагло скопипастить и выполнить, то получим такую вот ошибку:

Unknown option "-–enable-cuda-sdk".

Молодцы они эдакие, в своем копипастном примере взяли и поменяли знак минуса на дефис. Я почти уверен, что текст верстали под macOS, она любит такие автозамены проворачивать.

Надо вот так:

./configure --enable-nonfree --enable-cuda-sdk --enable-libnpp --extra-cflags=-I/usr/local/cuda/include --extra-ldflags=-L/usr/local/cuda/lib64

А если получим варнинг:

WARNING: Option --enable-cuda-sdk is deprecated. Use --enable-cuda-nvcc instead.

То вообще вот так:

./configure --enable-nonfree --enable-cuda-nvcc --enable-libnpp --extra-cflags=-I/usr/local/cuda/include --extra-ldflags=-L/usr/local/cuda/lib64

Ну все, теперь можно компилить и пользоваться.

P.S. Забавно, движок блога Эгея тоже сливает два минуса в дефис, если они находятся вне тэга «код», поэтому в заголовке я их разделил пробелом нулевой длины.

Допустим, вам, как и мне сейчас, потребовалось перекинуть пару сотен тысяч картинок с одного сервера на другой. Передача файлов по одному займет неадекватное количество времени. Хочется как-то их все собрать в один файл и передать уже его разом по сети.

Кажется, что для этого может подойти создание архива из всех доступных файлов. Однако, для картинок, в отличии от текста, это не будет иметь особого смысла, т. к. сжать их еще сильнее не получится, а времени на попытки уйдет уйма.

Какой есть выход из этой ситуации? Верно, создать архив без сжатия:

Вот так, если предпочитаете tar:

tar -cf ./archive.tar /path/to/folder

И так, если больше нравится zip:

zip -qq -0 -r ./archive.zip /path/to/folder

Но как показывают замеры времени, tar справляется с задачей простой сборки файлов в один в разы быстрее.

После передачи файла по сети распаковать его можно так:

Для tar архива:

tar -xf ./archive.tar

И для zip архива:

unzip -qq ./archive.zip

С месяц назад, при записи JSON данных в лог, забыл отформатировать их json.dumps из питоновского dict’a в нормальный вид, а просто записал его при форматной печатью, преобразовав dict в str. Само собой, получил кучу данных в неудобоваримом виде, эх.

Как исправить? Стандартный json.loads теперь не воспримет такую строку как корректный JSON, т. к. с точки зрения формата она не валидна. Можно решить эту проблему при помощи функции ast.literal_eval.

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

Пример работы:

import ast
import json

# Наш преобразованный в строку dict()
s = "{'a': 'Text with \\'quotes\\''}"
j = json.loads(s)
# Получаем ошибку парсинга из-за одинарных кавычек
>> json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 1 column 2 (char 1)

# Парсим строку в dict
j = ast.literal_eval(s)
print(j)
>> {'a': "Text with 'quotes'"}
# Теперь уже дампим данные корректно
print(json.dumps(j))
>>{"a": "Text with 'quotes'"}

Знакомые часто говорят, что налоговая, якобы, «сливает» данные новых ИПшников, т. к. им сразу же после регистрации начинают обрывать телефон банки, предлагая подключить у них услугу РКО. Я вот, несколько лет назад, вообще узнал об успешности регистрации своего ИП не из налоговой, а от колл-центра Тинькова, хехе.

На самом деле, эта информация официально доступна через API налоговой за некоторую сумму денег, так что юридически тут все чисто. А банки просто грамотно используют подвернувшуюся возможность.

Так вот, три года была тишина, никто мне не звонил и не надоедал. Недавно сходил, открыл себе дополнительный счет в ВТБ. Ибо комиссии пониже, год бесплатного обслуживания и все такое. И практически сразу же получил предложения открыть р/с еще от пары банков. Возникает закономерный вопрос, а не сливает ли кто-то в ВТБ данные новых клиентов другим банкам?