RSS
Pages: 1 2 3 4 5 6 7 8 9 10
[>] develop.16
develop.16
Difrex(mira, 14) — All
2015-12-01 09:55:28


Обсуждение вопросов программирования.

[>] 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
Difrex(mira, 14) — Difrex
2015-12-02 08:49:04


Да, поставил SBCL.

[>] 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/ это очень годная штука для подгрузки и обновления систем (что-то типа библиотек). Очень удобно.

PS: А синтаксис не такой уж и наркоманский. Зато позволяет легко осуществлять работу макросов и вообще. Ведь никто не запрещает передавать функции как данные, например.

[>] 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
Difrex(mira, 14) — Difrex
2015-12-02 11:05:27


О, compile-file делает, то, что мне нужно :)

[>] 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. Хотя сколько не пытался, всё сегфолты и ошибки линковки.

То есть по факту таки нет.

PS: Я рекомендую почитать первую главу PCL (Practical Common Lisp). Лучше всего взять русский перевод тут https://github.com/pcl-ru/pcl-ru или я могу скинуть уже готовую pdf-ку. Если первая глава заинтригует, то почитать хотя бы главы 2 и 3. После этого уже можно что-то писать (я clii написал, имея за плечами только этот багаж).

[>] 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 вот это все.

[>] Читаю тут PCL
develop.16
vit01(mira, 1) — All
2015-12-19 15:47:37


Сабж вполне подробный и нескучный.

Как прочитал "историю про макросы" отсюда https://github.com/pcl-ru/pcl-ru/blob/master/chapter-08.tex , впервые за день искренне улыбнулся =)

А функциональный подход лиспа всё-таки ломает неокрепшие мозги.
Кстати, а почему в Common Lisp есть общие макросы and, or, not, но при этом xor доступен только через logxor и подобные ему?

[>] 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


// ура, наконец-то кто-то из "своих" появился в ii =)

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


К такой мысли я пришёл, когда в очередной раз помирал от скуки.

Как известно, лень - двигатель прогресса. И именно поэтому часто приходится писать всяческие скрипты и полезные штуки, чтобы уменьшить количество рутинных действий за компьютером.
Казалось бы, имеется куча интересных языков программирования, с помощью которых можно хорошо повеселиться, получить удовольствие и необычный опыт в процессе написания скриптов. Но нет же: лень диктует своё, поэтому руки невольно тянутся к тому, что сразу работает. А с помощью чего можно быстро сделать всё, что угодно? Правильно - с помощью баша и питона. Пять строк простого, незамысловатого кода, и результат достигнут!
В этом месте лень начинает работать против человека. Зачем переписывать (и, главное, начинать писать) эти штуки на других языках, если всё и так работает? Зачем лишний раз напрягать мозг? Вот здесь и начинается разврат.
Путь к излечению трудный и долгий; придётся иметь дело с ломками, как у наркоманов. Надо каким-то образом загонять себя в жёсткие рамки используемых ресурсов и отказываться от привычных технологий в пользу самообразования. Создать себе на ЭВМ аскетичное рабочее окружение без всяких "плюшек" и пытаться в нём выживать.
В общем, перестать себя баловать всякими фичами и реализовать эти фичи самому.

P.S. Извините за такой душевный выброс, но просто не получается держать это внутри

[>] 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 становится скучно, и начинается депрессняк. Думаю подыскать какой-нибудь опенсурс-проект и идти пилить, но не знаю, куда податься =(

[>] Re: Bash и Python развращают мозг
develop.16
vit01(mira, 1) — vit01
2016-01-14 12:26:13


Всё, решено, буду делать велосипеды в большом количестве =)
Обнаружил пробелы в знаниях в области параллельного программирования и асинхронных запросов в вебе.

[>] 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
Difrex(mira, 14) — vit01
2016-02-03 07:56:24


Нужен человек с виндой.

[>] Re: Wine и Python
develop.16
vit01(mira, 1) — Difrex
2016-02-03 10:52:38


Difrex> Нужен человек с виндой.

Это ясно, но разве у нас такие водятся?

[>] 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: Wine и Python
develop.16
vit01(mira, 1) — btimofeev
2016-02-04 00:48:06


Спасибо, попробую на выходных сделать готовую сборку и отчитаюсь.

[>] Черновая сборка для Qt-клиента на винду
develop.16
vit01(mira, 1) — All
2016-02-04 14:18:13


Сделал через NSIS самым простым способом, какой только был. Это просто для теста, что оно работает.

Посмотрите, пожалуйста, что оно вообще запускается.

http://ii-net.tk/files/iiclient.exe

[>] Re: Черновая сборка для Qt-клиента на винду
develop.16
btimofeev(station13, 13) — vit01
2016-02-04 16:34:31


vit01> Посмотрите, пожалуйста, что оно вообще запускается.

Устанавливается и программа работает.

[>] Re: Черновая сборка для Qt-клиента на винду
develop.16
vit01(mira, 1) — btimofeev
2016-02-04 23:21:36


А как работает? Может быть, есть какие-нибудь баги?

И да, ещё можно пожелания высказать.

[>] 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.

Ух ты. Не доглядел =)

// А я в итоге без расширенного /u/e это сделал =) Теперь вот репу чешу: зачем предлагал =)

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 включать на своей ноде?

Пока не успел. Надо на слаке попробовать. На винде я его потыкал просто, так как машинку не на долго смог у жены отбить (курсач пишет). В ближайшие дни устрою стресс-тест твоего клиента и попробую пожить без запуска цезия (очень тяжко, кстати, это оказалось; как никак клиент мечты и прикипел к нему всей душой). О результатах эксперимента отпишусь к следующей неделе.

PS: А где глянуть алгоритм получения сообщений? Например, у меня включена поддержка расширенной /u/e и оно получает последние 50 сообщений. Я, например, неделю не получал новых сообщений и в эхе на ноде их скопилось больше 50. Как поведёт себя клиент в такой ситуации?

[>] 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: Черновая сборка для Qt-клиента на винду
develop.16
vit01(mira, 1) — btimofeev
2016-02-05 08:39:08


tossedit.exe - это и есть тот самый внутренний редактор. Насчёт точки, видимо, специфично для винды; попробую починить, спасибо.

Попробуй вместо leafpad поставить notepad и снять галку

[>] Вторая сборка клиента
develop.16
vit01(mira, 1) — All
2016-02-05 15:39:04


Учёл некоторые замечания, подправил установщик ещё и для создания ярлыков.

Доступна по той же ссылке:
http://ii-net.tk/files/iiclient.exe

// увы, установщик работает, а деинсталлятор пока не доделал; так что если клиент мусорит, то я не виноват =)

И да, теперь сборка идёт прямо из гита, т.к. я закоммитил все изменения для совместимости.

[>] Re: Вторая сборка клиента
develop.16
btimofeev(station13, 13) — vit01
2016-02-05 16:44:56


Теперь у меня редактор начал открываться, но выдает ошибку что мол не может открыть файл "C://Documents". Видимо не может обработать путь с пробелом. Ставлю gvim редактором, он просто создает и открывает файл "c://documents"

[>] Re: Вторая сборка клиента
develop.16
vit01(mira, 1) — btimofeev
2016-02-06 07:12:01


Хорошо, пересоберу вечером с экранированием пробелов.

[>] 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. Когда чищу базу сообщений окно отладки находится позади окна "дополнительные полезности" и на передний план его нельзя переместить.

Про эту особенность уже знаю, но пока не задумывался, что она может мешать =)
Это как-то связано с модальностью окон, попробую с этим разобраться.

Pages: 1 2 3 4 5 6 7 8 9 10