dervish_candela: (Dervish)
несмотря на кажущуюся очевидность записи вида settings.OptionX в С++ раньше получить подобную конструкцию достаточно сложно, надо было мутить целый класс (т.е. боль и страдание). с практической точки зрения можно было бы, конечно, использовать ассоциативный массив, но у него форма применения уж очень специфическая. про named tuples я вообще не говорю, это же слишком высокоуровневая абстракция для того чтобы ею можно было просто так взять и пользоваться (сарказм выкл).

я уже почти закончил реализацию на функциях в пространстве имён вида settings::OptionX(), когда до меня дошло, что теперь же у меня есть лямбды, и, аллилуйя, можно прямо в неймспейсе писать settings::OptionX = [](){ ... }();

П - прогресс*

*конечно, в питоне всё это делается элементарно.
dervish_candela: (Default)
огромное количество тру линуксовых хакеров в своих туториалах советуют запускать питон под виндой командой python. им даже в голову не приходит, что такой команды не существует ) бедный неофит искренне удивляется и негодуэ.
dervish_candela: (Default)
"DST rules are magic (determined by local law)"
— из руководства к модулю time.

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

LAW IS MAGIC
трудно выразить природу современного права лучше)
dervish_candela: (Default)
Скамейка объединила в себе hgtk инструменты log, status, commit и все комнады синхронизации. Куча лютых функциональных плюшек — мощные паттерны в окне фильтра, табнутый браузер репозитариев, итд. Интерфейс полностью переписан, и теперь похож на очень серьёзный инструмент, хотя в дизайне и чувствуется флавор чего-то очень опенсорсного и мозилльного, especially the legendary incomplete interface translation, it has such nostalgic air about it; и чудеснейший креативный перевод типа «протолкнуть» (push) и «после затягивания» (after pull).

Триумф! Наконец-то рабочая директория показывается в дереве выше верхушки, на месте будущего чейнджсета. Выбрать для нарисованной на экране ветки «Merge with local» оказалось куда проще, чем понять всю посвящённую веткам документацию, воссоздать дерево репозитария в голове и вбить нужную команду в шелл.

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

Вот кстати чудесный, простой как дважды два туториал показывает, как распрвляться с экспериментальными ветками-однодневками: http://csharpfeeds.com/post/98675/Experimental_branches_in_Mercurial.aspx
(а ненужную ветку можно стрипнуть или потом просто перезагрузить всю репу заново)

Нужно только помнить, что ветвей не существует :) Я серьезно. в смысле, в Hg не имеет смысла концепция ветви c технологической точки зрения, поэтому даже не стоит пытаться давать им имя, лучше скопировать всю репу и обозвать папочку как душе угодно. У этого есть один неприятный опбочный эффект — вид графа будет отличаться в зависимости от родителя рабочей директории. Если бы все незакрытые ветки торчали до самого верха то вышел бы отличный подсвечник было бы гораздо понятнее. Именно над этим я долго думал очень: как влить что-то в ветку, которой нет? Она есть, просто более новая ветка непосредственно продолжает более старую вверх вместо того, чтобы отходить вбок.

В итоге я изменил своё изначальное мнение насчёт defective by design веток в Меркуриале, заменив его на мнение об ущербности докментации и туториалов, не оговаривающих громко и явно ключевые (команда branch не создаёт веток) моменты.
dervish_candela: (insanity)
я таки задрот действительно написал программу, показывающую товар дня в Штурме.
теперь я не пропущу никаких шмоток Сиверы подешёвке :)



P.S. Единственный недостаток в моей программе - не может угадать, когда проснётся тов. Тим и выставит новый «товар дня». Так что надо в запуск её ставить не на утро, а на после обеда :)
dervish_candela: (Default)
Так как фотобукет был, - и, похоже, остался, - одним из немногих адекватных хостингов, то я до исх пор с него никуда не перешёл. Немножко допилил workflow: для загрузки из проводника или ACDSee по правой кнопочке мышки используем их древний аплоадер (они прекратили распространять его, даже не отладив как следует, но оставили API на месте, и он до сих пор работает). На сайте получаем список ссылок и из них с помощью нехитрого скрипта на питоне генерим простенькую галерею именно так, как нам нужно. Если бы им пользовался ещё кто-то кроме меня, объективную эргономику можно было бы допилить до чего-то более приемлемого — сделать гуёвый экзешник, подцепить к буферу обмена, генерить гелерею из списка файлов независимо от их загрузки, итд; но мне и так неплохо.
примитивненький скрипт )
Для больших серий публичных фотографий планирую всё же перейти на яндекс или гугл. Пока что тестирую яндекс. Непривычно, но вроде всё нужное на месте и работает.
dervish_candela: (Dervish)
Есть оказывается, такая чудесная вещь, как PyVISA.
Теперь можно грабить корованы мерять что угодно, не убивая моск буферами и указателями на С++:

import visa
CNT90 = visa.instrument("USB0::0x14EB::0x0090::313373") #частотомер Pendulum CNT-90 S/N 313373
print CNT90.ask_for_values("measure:frequency? (@1)")

Идентификатор устройства мы обычно знаем от VISAIC или находим с помощью visa.get_instruments_list()

Все современные устройства измерения, оказывается, в отличие от дубовых вольтметров в кабинете физики, поддерживают командный интерфейс SCPI через КОП/USBTMC/RS232, а для унифицированного доступа и управления служит фреймворк VISA (Labview, например, имеет её в своем составе).
dervish_candela: (Default)
Хорошая штука, однозначно удобнее XRCed'а хотя бы тем, что имеет поясняющие комментарии ко всем этим флагам в сайзер-айтемах. Идея писать пользовательский код в наследуемом классе впервые до меня дошла и поразила своей очевидностью и правильностью =) Генерировать код формы и наследовать его в сто раз удобнее, чем загружать из XRC.

On another note, оказывается, есть такая чудесная функция vars, которая объединяет всю эту мишуру типа locals(), globals() и __dict__ в одну кучу, что всё запутывает ещё больше очень удобно: vars() is locals() и vars(o) is o.__dict__
dervish_candela: (Default)
>>> bool((None,None))
True

Но я не об этом. Оказывается, не существует штатного способа инкапсулировать работу с кучей параметров. И атрибуты объекта, и переменные класса доступны только в квалифицированном виде. Единственный способ обойти это уродство - засрать пространство имён модуля глобальными переменными Т_Т ?

Кстати, а как это сделать? как изнутри модуля получить доступ к его __dict__ ? Никак?

Потому что я не намерен писать формулы вида self.a + self.b / self.c. (даже с учетом замены «self» на «o»)
И уж точно я не собираюсь писать
с = self.__class__
с.a + с.b/с.с

Боже, ребята, что вы сделали с языком? Т_Т он же абсолютно непригоден к каким бы то ни было вычсилениям, если каждый неглобальный чих нужно квалифицировать.

P.S. Я наконец догадался заменить «self» на «o», от слова «object», ведь кругляшок идеально символизирует объект — можно представлять себе, что это такой специальный синтаксис :) Заодно и бойлерплейта стало в разы меньше, теперь это можно писать руками, не убиваясь об стену.

UPD: «So you're writing a library, and you have this object that keeps showing up in parameters or attributes everywhere, even though there's only ever one of that thing at a given moment in time.»

Звучит знакомо, правда? Это вступление к описанию библиотеки Contextual. К сожалению, я слабо подкован в теории и практике промышленной разработки и не смог с наскока понять, как оно поможет лично мне (и поможет ли). Но подобные вещи звучат вкусно:

«In addition to these simple pseudo-global objects, peak.context also supports other kinds of context-sensitivity, like the concept of "settings" in a "current configuration" and the concept of "resources" in a "current action" (that are notified whether the action completed successfully or exited with an error).»

UPD2: Ещё есть некая PyContext, но кроме одной слабовнятной статьи, информации по вообще ней ноль.
dervish_candela: (Default)
ну что, товарищи по несчастью, помогайте ещё?

основной вопрос: что говорит Истинное Функциональное Программирование® о Девственно Чистых Методах произведения Запутанных Расчётов™?

а) Традиционно оформить кучу настроек и функций-методов для их обработки мы можем в виде класса, настройки поместить в перменные класса, и сделать особые функции для их установки и валидации типа set_parameters_type1.

а.1) вариант: вообще не делать параметры переменными, а поместить их в свой словарь или свой мини-класс (что в общем-то одно и то же), таким образом их можно будет передавать конструктору.

б) Чтобы избежать больших веток «if...then...else» в каждом из методов, мы можем главные настройки (тип вычисления, вид вычисления) вынести наверх; и сделать иерархию парочки классов, инстанцируя нужный для конкретной обработки и заполняя поля с помощью упомянутых set_parameters. Вместо одной проблемы мы получаем другую. Этот подход неприятен вынесением половины важнейшей логики наружу объекта для обработки данных, поэтому...

б.1) поэтому мы наверное захотим механизм условного инстанцирования упрятать в какую-нибудь «фабрику», что результирует в куче лишнего кода для убийства глаз и сущностей для убийства своих мозгов!

б.2) аналогично варианту а.1 совокупности параметров представлять своим объектом, что позволит немножко более осмысленную «фабрику».

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

вариант г) мы не рассматриваем, чтобы не навлечь ярость Amnesty International и феминисток цивилизованных государств.

а как бы поступил иисус?
dervish_candela: (Default)
вопрос не такой дурацкий, как кажется. хотя и не столько технический, сколько философский стилистический.

код, который у меня идёт за основу, ужасен. есть цепочка вызовов вида:
bRes = Convert(); //bRes - это флаг успеха, а обработка данных - сайд-эффект; божичка, как же жить страшно.

если бы я переписывал это на С++, я бы просто сделал вот так:
Convert(&data); //тонкий намёк на кровавые сайд-эффекты виден издалека, ясен как день и кристально понятен

но что мне делать в питоне? если я напишу просто
Convert(data) #и чо?
я сам же через полчаса забуду, что этот (мутабельный) массив вообще где-то там обрабатывается. а так как он занимает минимум несколько мегабайт (до 16) в памяти, плодить его копии не очень хочется :/

насколько мудро будет написать вот так:
data = Convert(data) #технически, это работает (что происходит при ребинде имени к тому же объекту? ничего?), но выглядит так, как будто я что-то курил

или лучше будет наплодить новых имён и писать скажем так:
converted_data = Convert(data) #при том ,что указывать они будут на один и тот же массив, мне это не кажется очень разумным :/

или не паритсья и просто вернуться к изначальному варианту в менее кретиническом виде, сделав data обратно глобальным?
dervish_candela: (Default)
пеарю:
http://www.finalcog.com/node/20
в основном очевидное, но всё равно приятно и полезно.

P.S. Когда всё успеть >_<
И, самое непонятное, откуда на меня столько всего свалилось? То есть откуда, это понятно, но как я это допустил?! Надо срочно юккурить, пока не поздно.
dervish_candela: (Dervish)
эта штуковина заворачивает функцию (генератор) в класс и навешивает ей так необходимые каждому уважающему себя контекстоуправителю ушки __enter__() и __exit__().

осталось разобраться, когда выгружается длл-ка, то есть, как именно умирает ctypes.CDLL. из-за автоматического дворника, не так все просто с деструкторами...

Posted via mobilebloger
dervish_candela: (WTF)
self self selfselfselfself.selfблятьпитонself!

P.S. А, я понял. Эта лабуда - завуалированный, но доходчивый аргумент, - мол, чувак, да не хочешь ты его писать на самом деле, этот класс, сделай просто модуль с функциями, и всем будет лучше. Так сказать, по-хорошему, по-человечески просят. И работает же!

И ведь чсх толку-то от этих классов-то ноль, для управления ресурсами они непригодны. Надо глянуть контексты.
dervish_candela: (Default)
Мама мия. Чёрт меня дёрнул довести это до конца. Итак, вашему вниманию: танец с сопялми свиг без исходников (дано: 1×dumb.dll на MFC без исходников, 1×dumb.h, 1×dumb.lib).
Осторожно, моск. For exxxtreme geeks only.

сгенерировать обёртку, предварительно убрав __declspec(dllimport):
swig -python -c++ -module dumb_wrap dumb.h

получим:

dumb_wrap.cxx
dumb_wrap.c //нам не нужно
dumb_wrap.py

вернуть __declspec(dllimport) на место,
создать проект длл,
переключить в release (иначе будет требовать несуществующую python26_d.lib, вместо которой не получится подставить обычную),
скопировать python26.lib в папку проекта (прагма отказывается работать с абсолютными путями),

вместо #include <Python.h> в .cxx сгенерированном SWIGом файле добавить

#include <C:\Python26\include\Python.h>
#pragma comment(lib, "python26.lib") //подключение .lib-файла. в настройках проекта можно не указывать.

и там же
#define WINVER 0x0501
#define _AFXDLL //разрешить MFC
#include <afxwin.h> //подключить MFC

в принципе, оное надо только затем, чтобы не искать и не добавлять вручную все источники тупых макросов типа DWORD, CONST итд.

#include "dumb.h"
#pragma comment(lib, "dumb.lib")

получившуюся в итоге dll переименовать (это важно) в подчёркиваниеdumb_wrap.pyd

enjoy your aids.

Большая часть из этого выяснена в процессе, случайно. Интересно было бы посчитать шансы против меня.

дальше сибаритствуем:

import dumb_wrap
d1 = dumb_wrap.CDumb()

AkelPad 4

Mar. 3rd, 2010 01:34 pm
dervish_candela: (Default)
оказывается, актуальная версия уже бампнулась, и обладает уже весьма взрослой подстветкой кода. Не полноценный синтаксический анализатор, правда (многострочные коментарии обламываются) — но глупо ожидать от лучшего блокнота того, с чем со скрипом справляются даже лучшие ide.

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

Из других полезных добавок - явный индикатор BOM.

Speaking of BOM, нашёл вот такой убер-рулез: универсальный детектор кодировок.
Как всегда - что ни придумай, это уже сделали =) Если верить автору, это адаптация мозилловского детектора, основывающаяся на статистике символов.

Я закопипастил предложенный код и протеститровал немного на маленьких файлах, работает в принципе всё just as planned:
utf-8-sig → utf-8 1.0 (duh)
utf-8 без бома для файла с только ascii-символами → utf-8 0.99 (как?!)
windows-1251 c только ascii-символами → ascii 1.0 (just as planned)
windows-1251 c рус./лат. 50/50 → ~0.98
KOI8-R c рус./лат. 50/50 → ~0.9
OEM c рус./лат. 50/50 → ~0.7, для уверенного распознавания должно быть сильно больше русского текста.
Shift-JIS c лат. текстом и 1% каны → Shift-JIS 1.0, но ascii с только ascii-символами.

такая вот петрушка.
dervish_candela: (Default)
перешёл на питон 2.6
dervish_candela: (Default)
http://lukeplant.me.uk/blog.php?id=1107301645

Позабавило :) Примерно подводит черту под моими отношениями с С++ после знакомства с Питоном. Может бросить хаскель пока не поздно? :)

P.S. Ощущаю всё больший этический и эстетический протест против лживых и подлых нападок на stateful-системы. Что такое алгебраические типы данных? Исходя из того, что я понял, с практической точки зрения это и есть механизм автоматического обеспечения внутренней целостности и непротиворечивости системы с состоянием. Могу предположить, что теория может быть развита далее, до автоматического обеспечения непротиворечивости и целости сложных изменяемых объектно-оринетированных систем, а собственно высокоуровневые «методы» будут прикручиваться уже сверху на полученный костяк. Технологически, часть этого уже реализована в Хаскеле. Причем, подозреваю, большая часть. Идеология объединения данных и мехнизмов их обработки, суть ООП - великое достижение, и принципиальная подверженность получающихся сложных систем ошибкам, как мне кажется, вовсе не вина подхода и уж точно не аргумент в пользу функционального стиля («битый небитого везёт», выезжать на спине других - нехорошо), а всего лишь индикатор несовершенства теоретический и технологической базы.

Всё-таки многие системы для человеческой мысли гораздо удобнее представлять в виде асинхронных сущностей с состоянием и методами, чем в виде деревьев вызова чистых функций. Именно это и стало причиной появления и формулировки данной проблемы. Будь нам функциональная парадигма ближе, этой проблемы бы даже не появилось.
dervish_candela: (Default)
оказался проще, чем мы думали:
import threading
import wx.lib.newevent
MakeEvent01, wx.EVENT01 = wx.lib.newevent.NewEvent()

class widget1(wx.SomeWidget):
def async_report(self, s):
    event = MakeEvent01()
    event.text = s
    wx.PostEvent(self, event)

def __init__(self, parent, **kwargs):
   wx.SomeWidget.__init__(self, parent, wx.ID_ANY, **kwargs)

def AssignJob(self,do_stuff):
   do_stuff_frozen = functools.partial(do_stuff, async_report)
   self.t = threading.Thread(target=do_stuff_frozen)
   self.Bind(wx.EVENT01, self.Event01Handler)
   self.t.start()

def Event01Handler(self, evt)
   self.Display(evt.text)

Этому добру кормим любую функцию вида DoSomeLongAndHeavyStuff(log) и радуемся жизни.
Интересно, можно ли ещё проще.
dervish_candela: (Default)
Черезвычайно интересно. Оказывается, существуют средства, позволяющие допилить работу с SQL в питоне до немного похожей парадигмы. Из имен я нашел Dejavu, Geniusql и SqlSoup (SQLAlchemy). Причем два последних предоставляют синтаксис, по ясности не уступающий интегрированному в язык псевдо-sql, причем оба умеют превращать вызовы методов и лямбды во вполне неиллюзорные sql-запросы (т.е. это обертки для, а не эмуляторы sql). Единственная ключевая продажная точка у LINQ (кроме, конечно же, нашего любимого идола Синтаксического Сахарозного Диабета) — он представляет из себя универсальную унифицированную архитектуру преобразования запросов в AST предметной области, к которой легким движением руки навинчиваются нужные реализации для чего угодно. Теоретически, можно создать нечто подобное для питона на базе существующих элементных деревьев, супов и прочего добра для XML, но работы там непочатый край. И вопрос синтаксической сахарозы вовсе не так пренебрежим, как кажется: не всех радует вручную передавать лямбды генераторным выражениям (Geniusql), кто-то просто вернется к старым добрым функциям (SqlSoup), и не будет никакой единой инфраструктуры.

Вообще, чувствую, в конце времен придут к идее добавить в питон явную статическую типизацию. Этот момент будет началом сингулярности.

P.S. Хм. Судя по вот этой дискуссии, я не точно не превый, кто догадался расширить питон (лол), но по однострочному ответу на неё (о содержимом можно догадаться, не кликая на ссылку), ожидать чего-либо интересного от питона в этой конкретной области не приходится. Кстати, я потрясен: я думал, Питон реализует первоклассные объекты кода (полностью согласен насчет Лиспа с тем оратором :). Использовать чёрную магию и грязные хаки типа разборки байткода для решения в сущности примитивной задачи - это подозрительно похоже на знак старения языка и сообщества вокруг него.

P.S. Лол батарейка в рабочем компе садится, записи оказываются отправленными в прошлое =)

April 2017

S M T W T F S
       1
234 5678
9101112131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 23rd, 2017 09:21 am
Powered by Dreamwidth Studios