[>]
LISP
develop.16
Difrex(mira, 14) — All
2015-12-02 08:47:21
Я тут подумал, что надо бы написать что-то на чем-то отличном от перла или питона.
Руби не хочу, ноджс тащить в систему ваще не хочется, С не люблю с института.
Глянул на CL -- это прямо то, что нужно! Синтаксис еще долбанутей перла, я такое люблю! Начал читать Practical Common Lisp. Но это все нудно. Я люблю учить что-то новое через реальные задачи, а не базу ЦД.
Такой вот очень нубский вопрос: как скомпилить файл в нативный бинарь? Как запустить файл в интерпретаторе(не в REPL (load "filename"))?
:D
[>]
Re: LISP
develop.16
Andrew Lobanov(station13, 1) — Difrex
2015-12-02 09:39:26
Difrex> Глянул на CL -- это прямо то, что нужно! Синтаксис еще долбанутей перла, я такое люблю! Начал читать Practical Common Lisp. Но это все нудно. Я люблю учить что-то новое через реальные задачи, а не базу ЦД.
Базу ЦД из PCL рекомендую всё таки разобрать. Хорошее погружение, так сказать.
Difrex> Такой вот очень нубский вопрос: как скомпилить файл в нативный бинарь? Как запустить файл в интерпретаторе(не в REPL (load "filename"))?
Нативный бинарь у лиспа это очень своеобразная штука. По крайней мере у SBCL. Это по своей сути упакованная в один файл лисп-машина и core dump всего загруженного на момент "компиляции". В итоге бинари толстые.
На примере SBCL это выглядит так:
* (sb-ext:save-lisp-and-die "bin-name" :executable t :top-level 'function-name)
Всё, что выполняется вне функций упихиваешь в функцию (например (defun main () ...)). Тогда :top-level 'main будет. А :executable отвечает за конечный результат: бинарь дампа или лисп-машину туда присобачить.
Я долго разбирался с этим вопросом, но похоже свободные реализации не умеют компилировать нативный байт-код.
А загрузка осуществляется посредством (load "filename") да =)
Ещё рекомендую посмотреть
https://www.quicklisp.org/ это очень годная штука для подгрузки и обновления систем (что-то типа библиотек). Очень удобно.
[>]
Re: LISP
develop.16
Andrew Lobanov(station13, 1) — Difrex
2015-12-02 09:41:54
AL> Я долго разбирался с этим вопросом, но похоже свободные реализации не умеют компилировать нативный байт-код.
Зато ты можешь подгрузить и запустить swank и подключаться к этому толстому бинарю после запуска с помощью SLIME как к удалённой лисп-машине. Баги удалённо на горячую править или ещё чего.
[>]
Re: LISP
develop.16
Difrex(mira, 14) — Andrew Lobanov
2015-12-02 10:10:54
>Базу ЦД из PCL рекомендую всё таки разобрать. Хорошее погружение, так сказать.
Да я читаю это все. Просто хотелось параллельно писать полезный говнокод :)
>Нативный бинарь у лиспа это очень своеобразная штука.
Спасибо, попробую разобраться с этим.
[>]
Re: LISP
develop.16
Andrew Lobanov(station13, 1) — Difrex
2015-12-02 11:17:47
Difrex> О, compile-file делает, то, что мне нужно :)
Так оно же fasl компилит. Или я тебя не понял просто?
[>]
Re: LISP
develop.16
Andrew Lobanov(station13, 1) — Difrex
2015-12-02 11:27:41
Difrex> О, compile-file делает, то, что мне нужно :)
Кстати, если разберёшься как подружить fasl и quicklisp (я просто не копал в эту сторону), то черкни сюда пару строчек о решении.
[>]
Re: LISP
develop.16
Difrex(mira, 14) — Difrex
2015-12-02 11:34:27
>О, compile-file делает, то, что мне нужно :)
Не, не совсем то. Зато sbcl --script точно, то, что нужно.
Теперь есть такой вопрос: как обрабатывать исключения? По типу eval в perl, ну или try/except в python?
[>]
Re: LISP
develop.16
Andrew Lobanov(station13, 1) — Difrex
2015-12-02 11:36:44
Difrex> Не, не совсем то. Зато sbcl --script точно, то, что нужно.
Ещё есть полезняшка в виде sbcl --eval.
Difrex> Теперь есть такой вопрос: как обрабатывать исключения? По типу eval в perl, ну или try/except в python?
PCL глава 19. Сам ещё толком не разбирался.
[>]
Re: LISP
develop.16
vit01(mira, 1) — Andrew Lobanov
2015-12-02 14:51:56
На прошлой неделе тоже пытался немного пощупать сабж. Уж так ты его нахваливал, аж попробовать захотелось :)
Хотел бы узнать, какие биндинги/API/стандартные либы общие у всех диалектов. А то по синтаксису общие моменты есть, но в остальном всё у всех своё.
AL> Нативный бинарь у лиспа это очень своеобразная штука. По крайней мере у SBCL. Это по своей сути упакованная в один файл лисп-машина и core dump всего загруженного на момент "компиляции". В итоге бинари толстые.
Embeddable Common Lisp умеет переводить свой код в сишные файлы, компилируемые GCC. Хотя сколько не пытался, всё сегфолты и ошибки линковки.
[>]
Re: LISP
develop.16
Andrew Lobanov(station13, 1) — vit01
2015-12-02 16:44:04
vit01> На прошлой неделе тоже пытался немного пощупать сабж. Уж так ты его нахваливал, аж попробовать захотелось :)
Как оказалось, в PCL дело написано в первой главе: разные языки действительно различны не взирая на формальное равенство по Тьюрингу. Но у Lisp есть и некоторые неудобства в виде достаточно тяжёлой lisp-машины, например.
vit01> Хотел бы узнать, какие биндинги/API/стандартные либы общие у всех диалектов. А то по синтаксису общие моменты есть, но в остальном всё у всех своё.
Дело в том, что по факту разные диалекты лиспа это разные языки со схожими или одинаковыми принципами. Лично я рекомендую Common Lisp, так как он стандартизирован (ANSI). По факту даже разные реализации того же Common Lisp несколько различны, но у них одинаковое ядро и всегда можно написать код совместимый с большим числом реализаций.
Common Lisp сильно отличен от прочих языков. Здесь нет единой линии партии, единой реализации. К вопросу о разных реализациях, кстати, тот же C, я уж молчу про C++, может работать по разному с разными компиляторами. Так что трагического ничего нет.
vit01> Embeddable Common Lisp умеет переводить свой код в сишные файлы, компилируемые GCC. Хотя сколько не пытался, всё сегфолты и ошибки линковки.
То есть по факту таки нет.
[>]
Re: LISP
develop.16
vit01(mira, 1) — Andrew Lobanov
2015-12-03 16:10:47
> PS: Я рекомендую почитать первую главу PCL (Practical Common Lisp).
Спасибо за направление. Взял PDF в другом месте, буду читать теперь.
[>]
node.js
develop.16
Difrex(mira, 14) — All
2015-12-10 09:51:02
Кто пишет под это?
Может кто объяснить, как мне собрать метрики с процесса? Ну, там Garbage Collector вот это все.
[>]
split-sequence
develop.16
vit01(mira, 1) — Andrew Lobanov
2015-12-27 15:55:50
Вопрос Андрею, как знатоку CL.
Заглянул тут в код iicl и задумался: а зачем же использовать сабж? Для нужд ii вполне можно взять какую-нибудь самописную функцию и не тянуть лишние зависимости через quicklisp.
Или дело в каких-нибудь заморочках с производительностью?
[>]
Re: split-sequence
develop.16
Andrew Lobanov(station13, 1) — vit01
2015-12-30 05:18:19
vit01> Вопрос Андрею, как знатоку CL.
Я не знаток CL, к сожалению. Катострофически не хватает времени на всё. Так что знаю его весьма поверхностно.
vit01> Заглянул тут в код iicl и задумался: а зачем же использовать сабж? Для нужд ii вполне можно взять какую-нибудь самописную функцию и не тянуть лишние зависимости через quicklisp.
iicl - мой учебный проект, на котором я учился писать хоть что-нибудь на CL. Там многое сделано очень плохо и криво. split-sequence я взял потому что проще взять готовое. Вот если бы отказаться от drakma или hunchentoot это да, в split-sequence маленький и не критичный.
vit01> Или дело в каких-нибудь заморочках с производительностью?
Дело в ламерстве =)
[>]
Re: split-sequence
develop.16
vit01(mira, 1) — Andrew Lobanov
2015-12-30 08:02:46
AL> split-sequence я взял потому что проще взять готовое. Вот если бы отказаться от drakma или hunchentoot это да, в split-sequence маленький и не критичный.
hunchentoot, насколько слышал, присутствует в репозиториях дебиана (и, скорее всего, других дистрибутивов). Так что чем меньше посторонних зависимостей, тем проще будет отказаться именно от quicklisp, а не от самого нужного.
[>]
Re: split-sequence
develop.16
Andrew Lobanov(station13, 1) — vit01
2015-12-30 08:41:02
vit01> // ура, наконец-то кто-то из "своих" появился в ii =)
Суета в виде фарша из работы (конец года это жесть), учёбы и предновогодней подготовки отняла всё время.
AL>> split-sequence я взял потому что проще взять готовое. Вот если бы отказаться от drakma или hunchentoot это да, в split-sequence маленький и не критичный.
vit01> hunchentoot, насколько слышал, присутствует в репозиториях дебиана (и, скорее всего, других дистрибутивов). Так что чем меньше посторонних зависимостей, тем проще будет отказаться именно от quicklisp, а не от самого нужного.
Я противник в данном случае завязывания на систему. quicklisp это вполне себе штатное уже решение, которое даёт гарантию простого запуска на любой системе, где есть лисп-машина и интернет.
[>]
Re: split-sequence
develop.16
vit01(mira, 1) — Andrew Lobanov
2016-01-02 04:28:07
Так или иначе, попробовал набросать подобную функцию сам.
Скорее всего, это г...код, но всё же:
(defun split (str delimiter &key (save-empty nil))
(setq delimiter (coerce delimiter 'character))
(let ((result nil) (len (length str)) (j 0) (toappend ""))
(dotimes (i len)
(if (char= (char str i) delimiter)
(progn
(setq toappend (subseq str j i))
(setq result (append result (list toappend)))
(setq j (1+ i))
; если разделитель в конце, добавляем пустоту
(if (= i (1- len)) (setq result (append result (list "")))))
(if (= i (1- len))
(setq result (append result (list (subseq str j len)))))))
(if (equal save-empty nil) ; убираем пустые строки, если они не нужны
(setq result (loop for s in result when (not (string= s "")) collect s)))
result))
(defun dotest (vals)
(dolist (s vals) (print (apply #'split (eval s)))))
(dotest '((list "/x/features/" "/") ; проверяем, что всё верно работает
(list "/ffggg/kikj//kjjj///" "/" :save-empty t)
(list "x/features" "/")))
[>]
Bash и Python развращают мозг
develop.16
vit01(mira, 1) — All
2016-01-12 14:32:36
К такой мысли я пришёл, когда в очередной раз помирал от скуки.
Как известно, лень - двигатель прогресса. И именно поэтому часто приходится писать всяческие скрипты и полезные штуки, чтобы уменьшить количество рутинных действий за компьютером.
Казалось бы, имеется куча интересных языков программирования, с помощью которых можно хорошо повеселиться, получить удовольствие и необычный опыт в процессе написания скриптов. Но нет же: лень диктует своё, поэтому руки невольно тянутся к тому, что сразу работает. А с помощью чего можно быстро сделать всё, что угодно? Правильно - с помощью баша и питона. Пять строк простого, незамысловатого кода, и результат достигнут!
В этом месте лень начинает работать против человека. Зачем переписывать (и, главное, начинать писать) эти штуки на других языках, если всё и так работает? Зачем лишний раз напрягать мозг? Вот здесь и начинается разврат.
Путь к излечению трудный и долгий; придётся иметь дело с ломками, как у наркоманов. Надо каким-то образом загонять себя в жёсткие рамки используемых ресурсов и отказываться от привычных технологий в пользу самообразования. Создать себе на ЭВМ аскетичное рабочее окружение без всяких "плюшек" и пытаться в нём выживать.
В общем, перестать себя баловать всякими фичами и реализовать эти фичи самому.
[>]
Re: Bash и Python развращают мозг
develop.16
Andrew Lobanov(station13, 1) — vit01
2016-01-13 07:34:18
vit01> P.S. Извините за такой душевный выброс, но просто не получается держать это внутри
На самом деле bash это хорошо (потому что нет смысла писать на C/Pascal/Fortran/указать свой вариат то, что можно уместить в пайп). Пайтон же хорош для небольших скриптов (на худой конец для ii-ноды или ii-клиента =).
Действительно нет смысла переписывать то, что и так хорошо работает. Лучшее - враг хорошего.
В тему вспоминается старый анекдот про программиста и его сына:
- Пап, почему солнце встаёт на востоке и заходит на западе?
Отец, не отрываясь от монитора:
- Ты проверял?
- Да.
- Точно?
- Да.
- Тогда не трогай ничего.
[>]
Re: Bash и Python развращают мозг
develop.16
vit01(mira, 1) — Andrew Lobanov
2016-01-13 13:26:19
AL> На самом деле bash это хорошо
AL> Пайтон же хорош для небольших скриптов
vit01>> руки невольно тянутся к тому, что сразу работает. А с помощью чего можно быстро сделать всё, что угодно? Правильно - с помощью баша и питона.
Хотел выразить предыдущим сообщением всё-таки немного другое. Суть не в том, что баш и питон плохие (сабж слишком провокационный), а то, что мне уже надоело писать скрипты/ноды/клиенты для ii (всё равно они уже юзабельные и хорошо работают), хочется чего-то нового и другого, не на этих языках.
И ещё то, что излишний комфорт препятствует самообразованию.
Когда все баги исправлены, нужные софтины и скрипты работают, как часы, фичи все необходимые есть, тогда vit01 становится скучно, и начинается депрессняк. Думаю подыскать какой-нибудь опенсурс-проект и идти пилить, но не знаю, куда податься =(
[>]
Wine и Python
develop.16
vit01(mira, 1) — All
2016-02-03 04:16:05
Запустил питон под вайном. Еле-еле он работает. PyQt, как ни странно, тоже работает. И клиент запустился. Правда, там сообщения все в кракозябрах (и дефолт-редактор не работает), но всё же.
Pyinstaller не может найти специфичные для венды модули, но установить их пока не смог, т.к. pip не работает.
>C:\Python34\Scripts\pip.exe
Fatal error in launcher: Job information querying failed
Пришлось убрать (или поменять) в нескольких местах вызовы locale.setlocale, иначе выдавалась ошибка.
[>]
Re: Wine и Python
develop.16
vit01(mira, 1) — vit01
2016-02-03 14:13:38
Хорошие новости. Удалось завести pip и PyInstaller. Удалось скомпилировать всё в ехе-шники. Дефолтный редактор работает. Даже кракозябры теперь ясно, как убрать, в ближайшие дни этим займусь.
Остаётся только небольшая проблема со значками. Сейчас клиент их подцепляет из дефолтной темы DE и, естесственно, в винде ничего не работает. Попробую взять где-нибудь сторонние.
А, и да, ещё как-то установщик сделать и ярлык в меню "Пуск". Здесь я даже не знаю, в какую сторону копать.
[>]
Re: Wine и Python
develop.16
btimofeev(station13, 13) — vit01
2016-02-03 21:21:35
vit01> А, и да, ещё как-то установщик сделать и ярлык в меню "Пуск". Здесь я даже не знаю, в какую сторону копать.
Я когда-то давно пользовался установщиком nsis, попробуй его, он один из самых популярных. Пишешь простенький скрипт на встроенном языке, скармливаешь его программе, она тебе создает установщик.
Так же могу помочь с тестированием на winxp, у меня есть одна на нетбуке.
[>]
Re: Черновая сборка для Qt-клиента на винду
develop.16
Andrew Lobanov(station13, 1) — vit01
2016-02-05 02:05:17
vit01> И да, ещё можно пожелания высказать.
Кстати, может сделать получение не полной эхи? А то вчера под виндой запускал (8.1 полёт нормальный), так кое как дождался загрузки эх из стандартного конфига.
Ну и окно терминала бы скрыть ещё.
[>]
Re: Черновая сборка для Qt-клиента на винду
develop.16
vit01(mira, 1) — Andrew Lobanov
2016-02-05 02:29:33
AL> Кстати, может сделать получение не полной эхи? А то вчера под виндой запускал (8.1 полёт нормальный), так кое как дождался загрузки эх из стандартного конфига.
Если ты включишь в настройках "Поддержку расширенного /u/e", то клиент будет скачивать только последние N.
AL> Ну и окно терминала бы скрыть ещё.
Точно, забыл. Но это с PyInstaller'ом связано, а не с самим клиентом, починю. Ты же имеешь в виду чёрную консоль питона, да?
[>]
Re: Черновая сборка для Qt-клиента на винду
develop.16
Andrew Lobanov(station13, 1) — vit01
2016-02-05 04:15:39
vit01> Если ты включишь в настройках "Поддержку расширенного /u/e", то клиент будет скачивать только последние N.
Ух ты. Не доглядел =)
vit01> Точно, забыл. Но это с PyInstaller'ом связано, а не с самим клиентом, починю. Ты же имеешь в виду чёрную консоль питона, да?
Да. Его. Клиент мне очень глянулся на самом деле. Классный такой. Некоторые шороховатости, конечно, есть (например, окно получения эх я бы сделал с двумя прогресс барами: кол-во эх и кол-во скачиваемых сообщений, но это сугубо моё видение и не факт что так надо делать), но пользоваться уже можно и он уже няшен.
[>]
Re: Черновая сборка для Qt-клиента на винду
develop.16
vit01(mira, 1) — Andrew Lobanov
2016-02-05 05:01:31
AL> // А я в итоге без расширенного /u/e это сделал =) Теперь вот репу чешу: зачем предлагал =)
На самом деле расширенный /u/e - это более правильный подход, потому что клиенту не надо скачивать весь индекс.
При твоём способе клиент получает полный список сообщений и отсекает N локально, а при моём он сразу получает N в индексе (отсечка идёт на ноде).
На больших эхах вроде lor-opennet.15 расширение /u/e очень помогает.
AL> например, окно получения эх я бы сделал с двумя прогресс барами: кол-во эх и кол-во скачиваемых сообщений
Я рассматривал вариант помещения прогрессбара в получение эх, но отказался от такой затеи.
Во-первых, потому что юзер должен полностью контролировать процесс фетча (а прогрессбар - это штука сама по себе ненадёжная), во-вторых, потому что алгоритм фетча слишком оптимизирован (как у Ромы), и не определишь, к какой эхе какое сообщение относится. В-третьих, потому что придётся избавиться от модульности в ii-шном движке (а это скажется негативно на будущих поделках).
Сейчас и фетчер, и мейлер, и blacklist, и сам ii_functions.py полностью совместимы с любыми другими реализациями. Например, с tk-версией. Также к iicli-modular можно без проблем прикрутить консольную или текстовую морду, и он будет работать со всеми фичами.
Фантазировал даже как-то раз прикрутить Цезий на свой движок.
Более глубокая интеграция может порушить всю эту гармонию.
Кстати, а как тебе всякие дополнительные плюшки вроде получения списка эх, блэклиста, чистки и прочего? Пробовал /x/c включать на своей ноде?
AL> но пользоваться уже можно и он уже няшен.
Спасибо, рад стараться =)
[>]
Re: Черновая сборка для Qt-клиента на винду
develop.16
Andrew Lobanov(station13, 1) — vit01
2016-02-05 05:10:34
vit01> Я рассматривал вариант помещения прогрессбара в получение эх, но отказался от такой затеи.
vit01> Во-первых, потому что юзер должен полностью контролировать процесс фетча (а прогрессбар - это штука сама по себе ненадёжная), во-вторых, потому что алгоритм фетча слишком оптимизирован (как у Ромы), и не определишь, к какой эхе какое сообщение относится. В-третьих, потому что придётся избавиться от модульности в ii-шном движке (а это скажется негативно на будущих поделках).
А. Ну я ж со своей колокольни. У меня лютый монолит, завязанный узлом сам на себя.
vit01> Кстати, а как тебе всякие дополнительные плюшки вроде получения списка эх, блэклиста, чистки и прочего? Пробовал /x/c включать на своей ноде?
Пока не успел. Надо на слаке попробовать. На винде я его потыкал просто, так как машинку не на долго смог у жены отбить (курсач пишет). В ближайшие дни устрою стресс-тест твоего клиента и попробую пожить без запуска цезия (очень тяжко, кстати, это оказалось; как никак клиент мечты и прикипел к нему всей душой). О результатах эксперимента отпишусь к следующей неделе.
[>]
Re: Черновая сборка для Qt-клиента на винду
develop.16
vit01(mira, 1) — Andrew Lobanov
2016-02-05 05:27:30
AL> А. Ну я ж со своей колокольни.
Мой клиент сделан для таких людей, у которых прописано 5 и более станций, а на каждой станции по 40 эх =)
Так что ради производительности иногда приходится жертвовать удобством.
AL> PS: А где глянуть алгоритм получения сообщений?
Файл webfetch.py (и ещё network.py, если интересна работа с прокси).
AL> Как поведёт себя клиент в такой ситуации?
Он зафетчит 50 последних. Да, я знаю, что это неправильно и собираюсь пофиксить в будущем, но руки пока не доходят.
Поэтому по-умолчанию поставил лимит 200, чтобы наверняка такого не было.
[>]
Re: Черновая сборка для Qt-клиента на винду
develop.16
btimofeev(station13, 13) — vit01
2016-02-05 07:44:15
vit01> А как работает? Может быть, есть какие-нибудь баги?
vit01> И да, ещё можно пожелания высказать.
По установщику: он предлагает установку по-умолчанию в ту же директорию откуда запускаешь, а не в Program Files. В установленной папке лежат .git и какой-то tossedit.exe
В клиенте у меня не открывается редактор при нажатии кнопок "Ответить" или "Новое". В консоль пишет: "." не является внутренней или внешней командой, исполняемой программой или пакетным файлом. В настройках выставлен редактор Leafpad (которого у меня конечно нет) и стоит галочка на Использовать встроенный редактор.
[>]
Re: Вторая сборка клиента
develop.16
btimofeev(station13, 13) — vit01
2016-02-05 16:44:56
Теперь у меня редактор начал открываться, но выдает ошибку что мол не может открыть файл "C://Documents". Видимо не может обработать путь с пробелом. Ставлю gvim редактором, он просто создает и открывает файл "c://documents"
[>]
Re: Вторая сборка клиента
develop.16
vit01(mira, 1) — vit01
2016-02-06 15:45:09
В общем, у меня проблемы теперь. Решил пересобрать exe-шники, и питон всё время падает.
22033 INFO: Processing pre-find module path hook PyQt5.uic.port_v3
22094 INFO: Processing pre-find module path hook PyQt5.uic.port_v2
23074 INFO: Looking for import hooks ...
23140 INFO: Processing hook hook-PyQt5.uic.py
23214 INFO: Processing hook hook-PyQt5.QtGui.py
wine: Unhandled page fault on read access to 0x44874150 at address 0xb74a8b66 (thread 0027), starting debugger...
Traceback (most recent call last):
File "C:\Python34\lib\runpy.py", line 170, in _run_module_as_main
"__main__", mod_spec)
File "C:\Python34\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Python34\lib\site-packages\PyInstaller\__main__.py", line 97, in <module>
run()
File "C:\Python34\lib\site-packages\PyInstaller\__main__.py", line 90, in run
run_build(pyi_config, spec_file, **vars(args))
File "C:\Python34\lib\site-packages\PyInstaller\__main__.py", line 46, in run_build
PyInstaller.building.build_main.main(pyi_config, spec_file, **kwargs)
File "C:\Python34\lib\site-packages\PyInstaller\building\build_main.py", line 755, in main
build(specfile, kw.get('distpath'), kw.get('workpath'), kw.get('clean_build'))
File "C:\Python34\lib\site-packages\PyInstaller\building\build_main.py", line 701, in build
exec(text, spec_namespace)
File "<string>", line 16, in <module>
File "C:\Python34\lib\site-packages\PyInstaller\building\build_main.py", line 212, in __init__
self.__postinit__()
File "C:\Python34\lib\site-packages\PyInstaller\building\datastruct.py", line 183, in __postinit__
self.assemble()
File "C:\Python34\lib\site-packages\PyInstaller\building\build_main.py", line 432, in assemble
imphook_object = ImportHook(imported_name, hook_file)
File "C:\Python34\lib\site-packages\PyInstaller\building\imphook.py", line 182, in __init__
self._module = importlib_load_source(hook_modname, self._filename)
File "C:\Python34\lib\site-packages\PyInstaller\compat.py", line 490, in importlib_load_source
return mod_loader.load_module()
File "<frozen importlib._bootstrap>", line 539, in _check_name_wrapper
File "<frozen importlib._bootstrap>", line 1614, in load_module
File "<frozen importlib._bootstrap>", line 596, in _load_module_shim
File "<frozen importlib._bootstrap>", line 1220, in load
File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
File "<frozen importlib._bootstrap>", line 1129, in _exec
File "<frozen importlib._bootstrap>", line 1471, in exec_module
File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
File "C:\Python34\lib\site-packages\PyInstaller\hooks\hook-PyQt5.QtGui.py", line 17, in <module>
binaries.extend(qt5_plugins_binaries('accessible'))
File "C:\Python34\lib\site-packages\PyInstaller\utils\hooks\__init__.py", line 334, in qt5_plugins_binaries
pdir = qt5_plugins_dir()
File "C:\Python34\lib\site-packages\PyInstaller\utils\hooks\__init__.py", line 296, in qt5_plugins_dir
"from PyQt5.QtCore import QCoreApplication;"
File "C:\Python34\lib\site-packages\PyInstaller\utils\hooks\__init__.py", line 127, in eval_statement
return eval(txt)
File "<string>", line 1
Unhandled exception: page fault on read access to 0x44874150 in 32-bit code (0xb74a8b66).
^
SyntaxError: invalid syntax
[>]
Третья сборка клиента
develop.16
vit01(mira, 1) — All
2016-02-07 07:47:21
* Решил (надеюсь) проблему с пробелами в пути к файлу.
* Exe-шники снова собираются.
* Наконец-то работает деинсталлятор.
* Русский язык в установщике.
exe доступен по той же ссылке, просьба протестировать.
[>]
Re: Третья сборка клиента
develop.16
btimofeev(station13, 13) — vit01
2016-02-07 13:13:12
У меня работает. Пара незначительных моментов:
1. Когда загружаются сообщения процесс загрузки выводится сразу в двух окнах: основном и окне отладки. Нужно ли последнее пользователю?
2. Когда чищу базу сообщений окно отладки находится позади окна "дополнительные полезности" и на передний план его нельзя переместить.
[>]
Re: Третья сборка клиента
develop.16
btimofeev(station13, 13) — vit01
2016-02-07 13:18:08
Еще при вводе неправильного пароля при отправке сообщения не выводит ошибки. Пишет просто отправлено 0 сообщений. А, к примеру, при помытке скачать список файлов ноды выводит Error: no auth.
[>]
Re: Третья сборка клиента
develop.16
vit01(mira, 1) — btimofeev
2016-02-07 13:39:08
> 1. Когда загружаются сообщения процесс загрузки выводится сразу в двух окнах: основном и окне отладки. Нужно ли последнее пользователю?
Если у пользователя медленный интернет (или он через прокси сидит), то окно отладки даёт понять, что клиент не висит, а работает. Особенно во время начальных запросов индекса.
И ещё: когда нода выдаёт необычную ошибку, то можно сделать скриншот этого окна, и сисоп быстрее разберётся, в чём причина.
> 2. Когда чищу базу сообщений окно отладки находится позади окна "дополнительные полезности" и на передний план его нельзя переместить.
Про эту особенность уже знаю, но пока не задумывался, что она может мешать =)
Это как-то связано с модальностью окон, попробую с этим разобраться.