Сообщения в develop.16

Re: Emacs

Ответ на сообщение
vit01> Попробовал SLIME. Удобная штука. С Емаксом работать пока сложновато, но буду как-нибудь привыкать.
Прикол в том, что Emacs это далеко не только тектосвый редактор. Так что посмотри в сторону других его возможностей при случае. А удобнее SLIME я действительно ничего ещё в разработке не встречал.
vit01> Как в сабже нормально настроить русскую раскладку? Просто сочетания клавиш работают только на английской.
А вот не знаю. С другой стороны, команды в vim тоже на английской раскладке надо вбивать. Так что переключение раскладки уже в подкорке. Но если нагуглишь решение, то делись.
Andrew Lobanov to vit01 (2016-04-09 17:30:12) [ссылка]

Emacs

Попробовал SLIME. Удобная штука. С Емаксом работать пока сложновато, но буду как-нибудь привыкать.

Как в сабже нормально настроить русскую раскладку? Просто сочетания клавиш работают только на английской.
vit01 to All (2016-04-09 16:38:27) [ссылка]

Re: Упрощение написания скриптов для GIMP

Ответ на сообщение
AL> Тут какое дело. Лиспокод не по скобочкам читают на самом деле. Я скобочки не замечаю даже особо. Блоки отделяются отступом, а синтаксис на скобочки не так уж и завязан при чтении человеком, как бы это странно не звучало.
Дело скорее не именно в чтении (мы же всё-таки буквы читаем, а не скобочки, верно?), а в написании кода. Когда он уже написан, скобки можно перенести на предыдущие строки и не обращать на них внимания. Но во время кодинга привык отделять. Ладно, спишу это на свои привычки.
AL> Было бы прикольно подключиться SLIME к гимпу.
Не поверишь, но такой плагин уже существует: https://github.com/pft/gimpmode
vit01 to Andrew Lobanov (2016-03-30 06:49:30) [ссылка]

Re: Упрощение написания скриптов для GIMP

Ответ на сообщение
> Просто хочется как-то отделять скобочные блоки, чтобы не запутаться в них. Если оставлять закрывающие скобки на предыдущей строке (а не на отдельной), то очень трудно определить, где какой смысловой блок, и очень просто сделать синтаксическую ошибку.
Тут какое дело. Лиспокод не по скобочкам читают на самом деле. Я скобочки не замечаю даже особо. Блоки отделяются отступом, а синтаксис на скобочки не так уж и завязан при чтении человеком, как бы это странно не звучало.
> - Через Emacs можно советоваться с психотерапевтом и играть в тетрис!
> - Подумаешь тетрис! Я вон GIMP вместо калькулятора использую :D
Было бы прикольно подключиться SLIME к гимпу.
Andrew Lobanov to vit01 (2016-03-30 06:19:11) [ссылка]

Re: Упрощение написания скриптов для GIMP

Ответ на сообщение
AL> Возможно одно из двух: или ты не привык к лиспу
Оно самое.
AL> видно, что писал человек, привыкший к алголоподобному синтаксису =)
Когда знакомился с эстетическими правилами оформления в CL, они мне как-то не понравились. Иногда читаю конкретно твой лиспокод и всё никак не могу с этим смириться.

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

- Через Emacs можно советоваться с психотерапевтом и играть в тетрис!
- Подумаешь тетрис! Я вон GIMP вместо калькулятора использую :D
vit01 to Andrew Lobanov (2016-03-30 05:46:55) [ссылка]

Re: Упрощение написания скриптов для GIMP

Ответ на сообщение
vit01> За отступы и оформление кода в целом не ругайте, по-другому читать ЭТО не получается =)
Возможно одно из двух: или ты не привык к лиспу или твой редактор некорректно занимается автоформатированием. Но в любом случае, код вполне читаемый на выходе, но видно, что писал человек, привыкший к алголоподобному синтаксису =)

// Не знал, что в гимпе есть лисп. Спасибо за информацию.
Andrew Lobanov to vit01 (2016-03-29 17:25:59) [ссылка]

Упрощение написания скриптов для GIMP

Возникла на днях задача пакетно обработать 179 JPEG-файлов.

Была мысль сначала взять ImageMagick, но подумал, что мало приятного в его использовании. PIL (Python Imaging Library) использовать тоже не хотелось, потому что многие параметры там надо подкручивать вручную.

И тут вспомнил, что в Гимпе есть свой встроенный Лисп. Воображение сразу разгулялось =)
Открыл встроенную консоль для Script-Fu и нашёл пару статеек на Хабре (например, эта: https://habrahabr.ru/post/111387/ )

Но не тут-то было! Изначально хотелось писать скрипты в своём любимом Vim'e и удобно их отлаживать, но Гимп предлагает только примитивный REPL (который требует запись программы в одну строку) и каталог модулей, запуск которых идёт как будто в "чёрном ящике".

Обнаружил, что можно запустить сервер Script-Fu и подключаться к Гимпу удалённо. Протокол у него предельно простой, но вот нормальных готовых клиентов реализовано практически не было.

Один из них полностью на Perl (и перлом заправляет, т.е. никаких скобочек), другой на неизвестном диалекте Scheme, третий на Питоне (из исходников самого Гимпа) и ничего мне нужного не умеет.

Решил реализовать собственный, на Си, через сокеты. Для скачивания идти сюда: https://github.com/vit1-irk/gimp-exec

Всё, что он делает - это скармливает Scheme-овский исходник запущенному GIMP-серверу, который уже выполняет всю работу. Может быть, кому-нибудь пригодится.

* Запускаете GIMP-сервер (удобнее через меню "Фильтры" => "Script-Fu" => "Запустить сервер")
* Пишете скрипт в вашем любимом редакторе
* Скармливаете его командой gimp-exec your-script.scheme
* Всё

Дополнительные моменты в README.md репозитория.

А для конвертации получилось вот такое вот заклинание:
(gimp-message-set-handler 1)
(let*
	((files (cadr (file-glob "/путь/к/картинкам/*" 1))))
	(while (not (null? files))
		(let (
			(filename (car files))
			(new-filename "")
			(image 0)
			(layer 0)
		)
			(set! image (car (gimp-file-load RUN-NONINTERACTIVE filename filename))) 
			(set! layer (car (gimp-image-get-active-layer image)))
			(set! new-filename (string-append filename "-new.png"))

			(gimp-message (string-append "Обрабатываем " filename))

			(gimp-levels-stretch layer)
			(gimp-brightness-contrast layer 0 40)
			(gimp-posterize layer 10)
			(gimp-image-convert-grayscale image)
			(gimp-image-convert-indexed image 2 3 10 FALSE TRUE "colors")
			(file-png-save RUN-NONINTERACTIVE image layer new-filename new-filename 0 9 0 0 0 1 0)
			(gimp-image-delete image)
		)
		(set! files (cdr files))
	)
)
За отступы и оформление кода в целом не ругайте, по-другому читать ЭТО не получается =)
vit01 to All (2016-03-28 19:15:22) [ссылка]

Re: Вдохновляющий текст: Write Code Every Day

Ответ на сообщение
>> The code must be Open Source and up on Github.
> Я вот, кстати, не считаю, что надо сразу тащить все на гитхаб.
Мне кажется, это надо читать, как "доступность кода с историей изменений". Хоть hg, хоть git, хоть svn с bazar. Во всяком случае именно это мне кажется хорошим тоном для Open Source проекта. В конце концов, хороший код с историей изменений и хорошими комментариями к коммитам может играть роль некоего учебного пособия помимо прочего.
Andrew Lobanov to Difrex (2016-03-10 04:43:45) [ссылка]

Re: Вдохновляющий текст: Write Code Every Day

Ответ на сообщение
>> The code must be Open Source and up on Github.
Difrex> Я вот, кстати, не считаю, что надо сразу тащить все на гитхаб.
Конечно, на гитхаб не обязательно: он содержится коммерческой компанией, интересы которой в любой момент могут войти в конфликт с интересами пользователей. + до сих пор помню ту историю с Роскомпозором, когда весь сайт из-за одного txt-шника заблочили.

Но вот насчёт "коммунизм-кода" с автором соглашусь. Если твои труды могут принести кому-то пользу, то лучше ими поделиться. И позже, кстати, они пойдут в репутацию для работодателя.
vit01 to Difrex (2016-03-02 12:12:32) [ссылка]

Re: Вдохновляющий текст: Write Code Every Day

Ответ на сообщение
>The code must be Open Source and up on Github.
Я вот, кстати, не считаю, что надо сразу тащить все на гитхаб.
Difrex to vit01 (2016-03-02 11:55:37) [ссылка]

Вдохновляющий текст: Write Code Every Day

Это надо запостить сюда полностью
Источник: http://ejohn.org/blog/write-code-every-day/

Last fall, work on my coding side projects came to a head: I wasn’t making adequate progress and I couldn’t find a way to get more done without sacrificing my ability to do effective work at Khan Academy.

There were a few major problems with how I was working on my side projects. I was primarily working on them during the weekends and sometimes in the evenings during the week. This is a strategy that does not work well for me, as it turns out. I was burdened with an incredible amount of stress to try and complete as much high quality work as possible during the weekend (and if I was unable to it felt like a failure). This was a problem as there’s no guarantee that every weekend will be free – nor that I’ll want to program all day for two days (removing any chance of relaxation or doing anything fun).

There’s also the issue that a week between working on some code is a long time, it’s very easy to forget what you were working on or what you left off on (even if you keep notes). Not to mention if you miss a weekend you end up with a two week gap as a result. That massive multi-week context switch can be deadly (I’ve had many side projects die due to attention starvation like that).

Inspired by the incredible work that Jennifer Dewalt completed last year, in which she taught herself programming by building 180 web sites in 180 days, I felt compelled to try a similar tactic: working on my side projects every single day.

I decided to set a couple rules for myself:

1. I must write code every day. I can write docs, or blog posts, or other things but it must be in addition to the code that I write.
2. It must be useful code. No tweaking indentation, no code re-formatting, and if at all possible no refactoring. (All these things are permitted, but not as the exclusive work of the day.)
3. All code must be written before midnight.
4. The code must be Open Source and up on Github.

Some of these rules were arbitrary. The code doesn’t technically need to be written before midnight of the day of but I wanted to avoid staying up too late writing sloppy code. Neither does the code have to be Open Source or up on Github. This just forced me to be more mindful of the code that I was writing (thinking about reusability and deciding to create modules earlier in the process).

Thus far I’ve been very successful, I’m nearing 20 weeks of consecutive work. I wanted to write about it as it’s completely changed how I code and has had a substantial impact upon my life and psyche.

With this in mind a number of interesting things happened as a result of this change in habit:

* Minimum viable code. I was forced to write code for no less than 30 minutes a day. (It’s really hard to write meaningful code in less time, especially after remembering where you left off the day before.) Some week days I work a little bit more (usually no more than an hour) and on weekends I’m sometimes able to work a full day.

* Code as habit. It’s important to note that that I don’t particularly care about the outward perception of the above Github chart. I think that’s the most important take away from this experiment: this is about a change that you’re making in your life for yourself not a change that you’re making to satisfy someone else’s perception of your work. The same goes for any form of dieting or exercise: if you don’t care about improving yourself then you’ll never actually succeed.

* Battling anxiety. Prior to starting this experiment I would frequently feel a high level of anxiety over not having completed “enough” work or made “enough” progress (both of which are relatively unquantifiable as my side projects had no specific deadlines). I realized that the feeling of making progress is just as important as making actual progress. This was an eye-opener. Once I started to make consistent progress every day the anxiety started to melt away. I felt at peace with the amount of work that I was getting done and I no longer had the over-bearing desire to frantically get any work done.

* Weekends. Getting work done on weekends use to be absolutely critical towards making forward momentum (as they were, typically, the only time in which I got significant side project coding done). That’s not so much the case now – and that’s a good thing. Building up a weeks-worth of expectations about what I should accomplish during the weekend only ended up leaving me disappointed. I was rarely able to complete all the work that I wanted and it forced me to reject other weekend activities that I enjoyed (eating dim sum, visiting museums, going to the park, spending time with my partner, etc.) in favor of getting more work done. I strongly feel that while side projects are really important they should not be to the exclusion of life in general.

* Background processing. An interesting side effect of writing side project code every day is that your current task is frequently running in the back of your mind. Thus when I go for a walk, or take a shower, or any of the other non-brain-using activities I participate in, I’m thinking about what I’m going to be coding later and finding a good way to solve that problem. This did not happen when I was working on the code once a week, or every other week. Instead that time was consumed thinking about some other task or, usually, replaced with anxiety over not getting any side project work done.

* Context switch. There’s always going to be a context switch cost when resuming work on a side project. Unfortunately it’s extremely hard to resume thinking about a project after an entire week of working on another task. Daily work has been quite helpful in this regard as the time period between work is much shorter, making it easier to remember what I was working on.

* Work balance. One of the most important aspects of this change was in simply learning how to better balance work/life/side project. Knowing that I was going to have to work on the project every single day I had to get better at balancing my time. If I was scheduled to go out in the evening, and not get back until late, then I would need to work on my side project early in the day, before starting my main Khan Academy work. Additionally if I hadn’t finished my work yet, and I was out late, then I’d hurry back home to finish it up (instead of missing a day). I should note that I’ve been finding that I have less time to spend on hobbies (such as woodblock printing) but that’s a reasonable tradeoff that I’ll need to live with.

* Outward perception. This has all had the added benefit of communicating this new habit externally. My partner understands that I have to finish this work every day, and thus activities sometimes have to be scheduled around it. It’s of considerable comfort to be able to say “Yes, we can go out/watch a movie/etc. but I have to get my coding in later” and have that be understood and taken into consideration.

* How much code was written? I have a hard time believing how much code I’ve written over the past few months. I created a couple new web sites, re-wrote some frameworks, and created a ton of new node modules. I’ve written so much I sometimes forget the things I’ve made – work from even a few weeks prior seem like a distant memory. I’m extremely pleased with the amount of work that I’ve gotten done.

I consider this change in habit to be a massive success and hope to continue it for as long as I can. In the meantime I’ll do all that I can to recommend this tactic to others who wish to get substantial side project work done. Let me know if this technique does, or doesn’t, work for you – I’m very interested in hearing additional anecdotes!
vit01 to All (2016-03-01 12:15:45) [ссылка]

Обнаружил проблему 2038 года в ii-php

Сабж
Проявится, если использовать движок MySQL.
Надо будет поменять там структуру.
vit01 to All (2016-02-22 09:05:27) [ссылка]

"Транспорты" для базы и PHP

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

Поэтому решил реализовать абстрактный интерфейс, через который бы можно было делать любые вещи с любой базой.

Сейчас в ноде до сих пор нельзя просто взять и удалить эху. Создать - на раз два, а удалить - через одно место. В некоторых местах стоят разные условия для разных баз.

В планах стоит сделать некую сисоп-панель, через которую можно править/удалять содержимое эх, чистить дубли и.т.д.
vit01 to All (2016-02-21 11:36:10) [ссылка]

Пятая сборка клиента

Список изменений:
ii://kg020clPuRsXz6UjrJIu
( эха ii://ii.14 )

Виндузятникам рекомендуется сначала удалить предыдущую версию.

Пожалуйста, протестируйте по юзабилити.
vit01 to All (2016-02-11 06:47:20) [ссылка]

Четвёртая сборка клиента

Исправления и улучшения можно почитать здесь:
ii://ii.14

ii://ek0DKrdqVsZwu4VhQcAf
ii://WrBS7WxjodCn0y2Q2cGv

Установщик находится всё по тому же адресу.
Пакет для дебиана: http://ii-net.tk/files/iicli-modular-0.6.0.deb

[NEW] Portable-версия для винды.
Теперь можно носить клиент вместе с базой на флешке!
http://ii-net.tk/files/ii-portable.zip
vit01 to All (2016-02-10 04:53:53) [ссылка]

Re: Третья сборка клиента

Ответ на сообщение
> Еще при вводе неправильного пароля при отправке сообщения не выводит ошибки. Пишет просто отправлено 0 сообщений. А, к примеру, при помытке скачать список файлов ноды выводит Error: no auth.
А это из-за модульного строения клиента (морда и мейлер отдельно). Можно соорудить костыль для такого, конечно.
То, что при попытке скачивания списка файлов выводит ошибку, связано с тем, что это всё парсится, и если парсинг не удался, то выкидывается Exception.

Теперь есть, с чем ещё поработать =)
vit01 to btimofeev (2016-02-07 13:46:08) [ссылка]

Re: Третья сборка клиента

Ответ на сообщение
> 1. Когда загружаются сообщения процесс загрузки выводится сразу в двух окнах: основном и окне отладки. Нужно ли последнее пользователю?
Если у пользователя медленный интернет (или он через прокси сидит), то окно отладки даёт понять, что клиент не висит, а работает. Особенно во время начальных запросов индекса.

И ещё: когда нода выдаёт необычную ошибку, то можно сделать скриншот этого окна, и сисоп быстрее разберётся, в чём причина.
> 2. Когда чищу базу сообщений окно отладки находится позади окна "дополнительные полезности" и на передний план его нельзя переместить.
Про эту особенность уже знаю, но пока не задумывался, что она может мешать =)
Это как-то связано с модальностью окон, попробую с этим разобраться.
vit01 to btimofeev (2016-02-07 13:39:08) [ссылка]

Re: Третья сборка клиента

Ответ на сообщение
Еще при вводе неправильного пароля при отправке сообщения не выводит ошибки. Пишет просто отправлено 0 сообщений. А, к примеру, при помытке скачать список файлов ноды выводит Error: no auth.
btimofeev to vit01 (2016-02-07 13:18:08) [ссылка]

Re: Третья сборка клиента

Ответ на сообщение
У меня работает. Пара незначительных моментов:

1. Когда загружаются сообщения процесс загрузки выводится сразу в двух окнах: основном и окне отладки. Нужно ли последнее пользователю?

2. Когда чищу базу сообщений окно отладки находится позади окна "дополнительные полезности" и на передний план его нельзя переместить.
btimofeev to vit01 (2016-02-07 13:13:12) [ссылка]

Третья сборка клиента

* Решил (надеюсь) проблему с пробелами в пути к файлу.
* Exe-шники снова собираются.
* Наконец-то работает деинсталлятор.
* Русский язык в установщике.

exe доступен по той же ссылке, просьба протестировать.
vit01 to All (2016-02-07 07:47:21) [ссылка]

Re: Вторая сборка клиента

Ответ на сообщение
В общем, у меня проблемы теперь. Решил пересобрать 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 
    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 "", line 16, in 
  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 "", line 539, in _check_name_wrapper
  File "", line 1614, in load_module
  File "", line 596, in _load_module_shim
  File "", line 1220, in load
  File "", line 1200, in _load_unlocked
  File "", line 1129, in _exec
  File "", line 1471, in exec_module
  File "", line 321, in _call_with_frames_removed
  File "C:\Python34\lib\site-packages\PyInstaller\hooks\hook-PyQt5.QtGui.py", line 17, in 
    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 "", line 1
    Unhandled exception: page fault on read access to 0x44874150 in 32-bit code (0xb74a8b66).
                      ^
SyntaxError: invalid syntax
vit01 to vit01 (2016-02-06 15:45:09) [ссылка]

Re: Вторая сборка клиента

Ответ на сообщение
Хорошо, пересоберу вечером с экранированием пробелов.
vit01 to btimofeev (2016-02-06 07:12:01) [ссылка]

Re: Вторая сборка клиента

Ответ на сообщение
Теперь у меня редактор начал открываться, но выдает ошибку что мол не может открыть файл "C://Documents". Видимо не может обработать путь с пробелом. Ставлю gvim редактором, он просто создает и открывает файл "c://documents"
btimofeev to vit01 (2016-02-05 16:44:56) [ссылка]

Вторая сборка клиента

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

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

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

И да, теперь сборка идёт прямо из гита, т.к. я закоммитил все изменения для совместимости.
vit01 to All (2016-02-05 15:39:04) [ссылка]

Re: Черновая сборка для Qt-клиента на винду

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

Попробуй вместо leafpad поставить notepad и снять галку
vit01 to btimofeev (2016-02-05 08:39:08) [ссылка]

Re: Черновая сборка для Qt-клиента на винду

Ответ на сообщение
vit01> А как работает? Может быть, есть какие-нибудь баги?
vit01> И да, ещё можно пожелания высказать.
По установщику: он предлагает установку по-умолчанию в ту же директорию откуда запускаешь, а не в Program Files. В установленной папке лежат .git и какой-то tossedit.exe

В клиенте у меня не открывается редактор при нажатии кнопок "Ответить" или "Новое". В консоль пишет: "." не является внутренней или внешней командой, исполняемой программой или пакетным файлом. В настройках выставлен редактор Leafpad (которого у меня конечно нет) и стоит галочка на Использовать встроенный редактор.
btimofeev to vit01 (2016-02-05 07:44:15) [ссылка]

Re: Черновая сборка для Qt-клиента на винду

Ответ на сообщение
AL> А. Ну я ж со своей колокольни.
Мой клиент сделан для таких людей, у которых прописано 5 и более станций, а на каждой станции по 40 эх =)
Так что ради производительности иногда приходится жертвовать удобством.
AL> PS: А где глянуть алгоритм получения сообщений?
Файл webfetch.py (и ещё network.py, если интересна работа с прокси).
AL> Как поведёт себя клиент в такой ситуации?
Он зафетчит 50 последних. Да, я знаю, что это неправильно и собираюсь пофиксить в будущем, но руки пока не доходят.
Поэтому по-умолчанию поставил лимит 200, чтобы наверняка такого не было.
vit01 to Andrew Lobanov (2016-02-05 05:27:30) [ссылка]

Re: Черновая сборка для Qt-клиента на винду

Ответ на сообщение
vit01> Я рассматривал вариант помещения прогрессбара в получение эх, но отказался от такой затеи.
vit01> Во-первых, потому что юзер должен полностью контролировать процесс фетча (а прогрессбар - это штука сама по себе ненадёжная), во-вторых, потому что алгоритм фетча слишком оптимизирован (как у Ромы), и не определишь, к какой эхе какое сообщение относится. В-третьих, потому что придётся избавиться от модульности в ii-шном движке (а это скажется негативно на будущих поделках).
А. Ну я ж со своей колокольни. У меня лютый монолит, завязанный узлом сам на себя.
vit01> Кстати, а как тебе всякие дополнительные плюшки вроде получения списка эх, блэклиста, чистки и прочего? Пробовал /x/c включать на своей ноде?
Пока не успел. Надо на слаке попробовать. На винде я его потыкал просто, так как машинку не на долго смог у жены отбить (курсач пишет). В ближайшие дни устрою стресс-тест твоего клиента и попробую пожить без запуска цезия (очень тяжко, кстати, это оказалось; как никак клиент мечты и прикипел к нему всей душой). О результатах эксперимента отпишусь к следующей неделе.

PS: А где глянуть алгоритм получения сообщений? Например, у меня включена поддержка расширенной /u/e и оно получает последние 50 сообщений. Я, например, неделю не получал новых сообщений и в эхе на ноде их скопилось больше 50. Как поведёт себя клиент в такой ситуации?
Andrew Lobanov to vit01 (2016-02-05 05:10:34) [ссылка]

Re: Черновая сборка для Qt-клиента на винду

Ответ на сообщение
AL> // А я в итоге без расширенного /u/e это сделал =) Теперь вот репу чешу: зачем предлагал =)
На самом деле расширенный /u/e - это более правильный подход, потому что клиенту не надо скачивать весь индекс.

При твоём способе клиент получает полный список сообщений и отсекает N локально, а при моём он сразу получает N в индексе (отсечка идёт на ноде).

На больших эхах вроде lor-opennet.15 расширение /u/e очень помогает.
AL> например, окно получения эх я бы сделал с двумя прогресс барами: кол-во эх и кол-во скачиваемых сообщений
Я рассматривал вариант помещения прогрессбара в получение эх, но отказался от такой затеи.
Во-первых, потому что юзер должен полностью контролировать процесс фетча (а прогрессбар - это штука сама по себе ненадёжная), во-вторых, потому что алгоритм фетча слишком оптимизирован (как у Ромы), и не определишь, к какой эхе какое сообщение относится. В-третьих, потому что придётся избавиться от модульности в ii-шном движке (а это скажется негативно на будущих поделках).

Сейчас и фетчер, и мейлер, и blacklist, и сам ii_functions.py полностью совместимы с любыми другими реализациями. Например, с tk-версией. Также к iicli-modular можно без проблем прикрутить консольную или текстовую морду, и он будет работать со всеми фичами.
Фантазировал даже как-то раз прикрутить Цезий на свой движок.
Более глубокая интеграция может порушить всю эту гармонию.

Кстати, а как тебе всякие дополнительные плюшки вроде получения списка эх, блэклиста, чистки и прочего? Пробовал /x/c включать на своей ноде?
AL> но пользоваться уже можно и он уже няшен.
Спасибо, рад стараться =)
vit01 to Andrew Lobanov (2016-02-05 05:01:31) [ссылка]

Re: Черновая сборка для Qt-клиента на винду

Ответ на сообщение
vit01> Если ты включишь в настройках "Поддержку расширенного /u/e", то клиент будет скачивать только последние N.
Ух ты. Не доглядел =)

// А я в итоге без расширенного /u/e это сделал =) Теперь вот репу чешу: зачем предлагал =)
vit01> Точно, забыл. Но это с PyInstaller'ом связано, а не с самим клиентом, починю. Ты же имеешь в виду чёрную консоль питона, да?
Да. Его. Клиент мне очень глянулся на самом деле. Классный такой. Некоторые шороховатости, конечно, есть (например, окно получения эх я бы сделал с двумя прогресс барами: кол-во эх и кол-во скачиваемых сообщений, но это сугубо моё видение и не факт что так надо делать), но пользоваться уже можно и он уже няшен.
Andrew Lobanov to vit01 (2016-02-05 04:15:39) [ссылка]