Вводная: для служб WCF можно запросить метаданные (в виде WSDL, MEX и чего-то там ещё) и сгенерировать по ним прокси-класс. А можно взять сборочку с метаданными службы (интерфейсами и прочими DTO) - если разработчик ее даст, конечно.
Лично мне второй вариант кажется предпочтительней, особенно, если разработчик я. Как следствие, клиент и сервер работают с одними и теми же (а не с похожими) типами, проще делать mock-и для клиента, а вся PITA, связанная с установкой и поддержанием соединения решается с помощью Castle (там, конечно, тоже будет прокси, но с заявленными интерфейсом).А вот MS, как будто бы, поощряет первый подход. А что предпочитаете вы, коллеги (необязательно для случая WCF, я так понимаю, что подходы похожи для разных технологий RPC)?
понедельник, июня 22, 2009
среда, апреля 01, 2009
После громких сообщений, касающихся возможной продажи компаний Sun Microsystems и Yahoo, теперь появилась информация о покупке корпорации Apple Гуглом.
В частности, как утверждают, председатель Гугл Эрик Шмидт заявил, что объединение с одной из самых уважаемых компаний США пойдет на пользу его компании. В частности, их привлекают возможности ОС по удаленному администрированию.
В рамках слияния ряд продуктов получит новые названия. Примерами могут служить новый Google Apple Engine и Google Apple Juice.
Также общественности предъявлен новый логотип объединенной компании:
Image Hosting.
В частности, как утверждают, председатель Гугл Эрик Шмидт заявил, что объединение с одной из самых уважаемых компаний США пойдет на пользу его компании. В частности, их привлекают возможности ОС по удаленному администрированию.
В рамках слияния ряд продуктов получит новые названия. Примерами могут служить новый Google Apple Engine и Google Apple Juice.
Также общественности предъявлен новый логотип объединенной компании:
Image Hosting.
четверг, октября 16, 2008
Между тем, MS, похоже, наваяла свой собственный клон Erlang'а, обозвав его 'Concurrency and Coordination Runtime', но запрятала его так, что заметил один Рихтер. Конкретно, в Microsoft Robotics Studio.
Наличествующие сущности:
- Dispatcher - набор потоков, в которых исполняется код.
- DispatcherQueue - очередь заданий, исполняемых потоками диспетчера в режиме round-robin.
- Port - типизированный вход для отправки сообщений на обработку. Порты могут группироваться в PortSet'ы (например, для связывания с операциями, результатом которых может быть значениие либо exception).
- Arbiter - собственно, обработчик сообщений, помещающий при срабатывании соответствующую задачу в очередь. Т.е. Арбитры напоминают оператор receive в erlang'е, но обладают большим разнообразием: есть арбитры для получения одного/нескольких сообщений с одного порта, обработки событий с любого или со всех портов из набора (т.е. объединение событий по ИЛИ/по И).
Что особенно приятно, все это довольно очевидным связывается с более традиционной Asynchronous Programming Model (которая "BeginXXX/EndXXX").
Надо будет эту штуку попробовать, создается впечатление, что с ее помощью удобно реализовывать многопоточные сервисы... =)
Наличествующие сущности:
- Dispatcher - набор потоков, в которых исполняется код.
- DispatcherQueue - очередь заданий, исполняемых потоками диспетчера в режиме round-robin.
- Port - типизированный вход для отправки сообщений на обработку. Порты могут группироваться в PortSet'ы (например, для связывания с операциями, результатом которых может быть значениие либо exception).
- Arbiter - собственно, обработчик сообщений, помещающий при срабатывании соответствующую задачу в очередь. Т.е. Арбитры напоминают оператор receive в erlang'е, но обладают большим разнообразием: есть арбитры для получения одного/нескольких сообщений с одного порта, обработки событий с любого или со всех портов из набора (т.е. объединение событий по ИЛИ/по И).
Что особенно приятно, все это довольно очевидным связывается с более традиционной Asynchronous Programming Model (которая "BeginXXX/EndXXX").
Надо будет эту штуку попробовать, создается впечатление, что с ее помощью удобно реализовывать многопоточные сервисы... =)
четверг, сентября 04, 2008
Все уже написали, один я остался.
Исправляюсь.
Пользовательские впечатления:
- красивенько (и интерфейс, и особенности рендеринга, типа подсветки активного элемента HTML);
- шустренько;
- маловато функциональности для меня (я привык к RSS-агрегатору, почтовому клиенту и детальным настройкам в Опере), но jedem das seine (, например, доволен). Опять же, предполагается, что почту и RSS люди будут юзать гугловские =);
- пока глючно (чего стоит падение от сочетания символов %:);
- не проникся идеей ресайза одних только шрифтов;
- проверка орфографии для русского языка отстойна (или "отстой на", как она сама предложила =))
Технические впечатления:
- Необычен (но достоин уважения) подход по выделению закладок в отдельные процессы-sandbox'ы (хотя от вышеупомянутой баги не защищает ;));
- памяти кушает больше, чем Опера
- напрягает периодический ломёж браузера на гугловские сайты (видимо, с сообщениями о перемещениях пользователя, пока не понял);
- напряг пункт в EULA насчет передачи всего сформированного контента в длинные руки гугла, но говорят, что этот пункт отменен;
Мнение:
Цель создания этой программы, скорее всего, все-таки не создание еще одного FLOSS-браузера, а построение клиентской части гугловской платформы разработки Web-приложений (в особенности, работающих на Google App Engine). Т.о., Chrome конкурирует не с IE/Firefox/Safari/Opera, а с Silverlight/JavaFX/AIR. Об этом говорит наличие встроенного отладчика JavaScript и инспектора HTML, использование Gears, упор на быстродействие движка JS.
Такое вот ИМХО.
Исправляюсь.
Пользовательские впечатления:
- красивенько (и интерфейс, и особенности рендеринга, типа подсветки активного элемента HTML);
- шустренько;
- маловато функциональности для меня (я привык к RSS-агрегатору, почтовому клиенту и детальным настройкам в Опере), но jedem das seine (
- пока глючно (чего стоит падение от сочетания символов %:);
- не проникся идеей ресайза одних только шрифтов;
- проверка орфографии для русского языка отстойна (или "отстой на", как она сама предложила =))
Технические впечатления:
- Необычен (но достоин уважения) подход по выделению закладок в отдельные процессы-sandbox'ы (хотя от вышеупомянутой баги не защищает ;));
- памяти кушает больше, чем Опера
- напрягает периодический ломёж браузера на гугловские сайты (видимо, с сообщениями о перемещениях пользователя, пока не понял);
- напряг пункт в EULA насчет передачи всего сформированного контента в длинные руки гугла, но говорят, что этот пункт отменен;
Мнение:
Цель создания этой программы, скорее всего, все-таки не создание еще одного FLOSS-браузера, а построение клиентской части гугловской платформы разработки Web-приложений (в особенности, работающих на Google App Engine). Т.о., Chrome конкурирует не с IE/Firefox/Safari/Opera, а с Silverlight/JavaFX/AIR. Об этом говорит наличие встроенного отладчика JavaScript и инспектора HTML, использование Gears, упор на быстродействие движка JS.
Такое вот ИМХО.
четверг, августа 28, 2008
работа с C# Expression trees
Иногда стопроцентно известна сигнатура конструктора класса (соглашение такое, скажем), но сам класс неизвестен.
Например, потому что этот класс - параметр дженерик-метода. А у дженериков в качестве ограничения типа можно задать только конструктор без параметров, что не гуд.
Тогда приходится использовать reflection.
Например, через класс Activator.
Но использование reflection'а имеет некоторый (хотя и обычно терпимый) оверхед, плюс, оно просто не интересно =), поэтому можно попробовать иначе.
Воспользоваться так называемыми деревьями выражений, появившимися в .NET BCL 3.5. Они позволяют динамически строить и анализировать (как это делают провайдеры LINQ) AST выражений (в том числе, соответствующих делегатам). А потом выражения для делегатов можно откомпилировать в CIL (который затем JIT откомпилирует в native-код).
Самое лучшее - когда типы, используемые в выражении известны.
Тогда построения дерева выражения можно возложить на компилятор, написав что-то вроде:
Но если бы типы были известны, вообще делать было бы нечего. Поэтому нам придется строить дерево вручную. Что, в общем-то, тоже несложно.
Легко увидеть, что дерево выражения для данного конструктора имеет вид (в псевдокоде)
В реальном коде на C# это будет выглядеть как:
аналогично и для других конструкторов:
new T(params) ->
и дерево будет выглядеть как
N.B.: ВАЖНО, чтобы параметры в теле лямбда-функции совпадали с ее параметрами, т.к. компилятор ищет их именно по совпадению, а не по имени.
Как видно, реальный код хотя и отличается, но не очень значительно.
Я наваял небольшой класс, кэширующий скомпилированные конструкторы. Замеры показали, что однократная компиляция+извлечение из словаря обгоняют чистый рефлекшен где-то с 16 тыс. созданий объектов, скэшированный же явным образом результат вообще вне конкуренции, т.к. это просто вызов конструктора.
В общем, expression trees могут оказаться хорошей заменой System.Reflection.Emit или System.CodeDom.Compiler там, где надо сгенерировать код на лету, но до порождения CIL или генерации кода в виде текста напрямую спускаться не хочется.
При этом, возможности expression trees ограничены - в них сложно обеспечить последовательное выполнение команд (разве что используя для этого AndAlso) и обработку исключений, нельзя породить класс (не для этого они созданы) и пр.
Опять же - не для того они были сделаны =)
Например, потому что этот класс - параметр дженерик-метода. А у дженериков в качестве ограничения типа можно задать только конструктор без параметров, что не гуд.
Тогда приходится использовать reflection.
Например, через класс Activator.
Но использование reflection'а имеет некоторый (хотя и обычно терпимый) оверхед, плюс, оно просто не интересно =), поэтому можно попробовать иначе.
Воспользоваться так называемыми деревьями выражений, появившимися в .NET BCL 3.5. Они позволяют динамически строить и анализировать (как это делают провайдеры LINQ) AST выражений (в том числе, соответствующих делегатам). А потом выражения для делегатов можно откомпилировать в CIL (который затем JIT откомпилирует в native-код).
Самое лучшее - когда типы, используемые в выражении известны.
Тогда построения дерева выражения можно возложить на компилятор, написав что-то вроде:
Expression<Func<char[],string>> e = chars => new string(chars);Но если бы типы были известны, вообще делать было бы нечего. Поэтому нам придется строить дерево вручную. Что, в общем-то, тоже несложно.
Легко увидеть, что дерево выражения для данного конструктора имеет вид (в псевдокоде)
(lambda (chars)(new (get-constructor (typeof string) (typeof chars[])) chars)
В реальном коде на C# это будет выглядеть как:
var p = Expression.Parameter(typeof(char[]), "chars");
var lambda = Expression.Lambda<Func<string>>(
Expression.New(typeof(string).GetConstructor(typeof(char[]), p);
аналогично и для других конструкторов:
new T(params) ->
(lambda (params) (new
(get-constructor (typeof T) (map (lambda (p) (typeof p)) params)
params)и дерево будет выглядеть как
var parameters = (from t in argTypes
select Expression.Parameter(t, "@"+t))
.ToArray();
Expression.Lambda(
Expression.New(targetType.GetConstructor(argTypes), parameters),
parameters);N.B.: ВАЖНО, чтобы параметры в теле лямбда-функции совпадали с ее параметрами, т.к. компилятор ищет их именно по совпадению, а не по имени.
Как видно, реальный код хотя и отличается, но не очень значительно.
Я наваял небольшой класс, кэширующий скомпилированные конструкторы. Замеры показали, что однократная компиляция+извлечение из словаря обгоняют чистый рефлекшен где-то с 16 тыс. созданий объектов, скэшированный же явным образом результат вообще вне конкуренции, т.к. это просто вызов конструктора.
В общем, expression trees могут оказаться хорошей заменой System.Reflection.Emit или System.CodeDom.Compiler там, где надо сгенерировать код на лету, но до порождения CIL или генерации кода в виде текста напрямую спускаться не хочется.
При этом, возможности expression trees ограничены - в них сложно обеспечить последовательное выполнение команд (разве что используя для этого AndAlso) и обработку исключений, нельзя породить класс (не для этого они созданы) и пр.
Опять же - не для того они были сделаны =)
понедельник, января 29, 2007
сериализация сериализовалась-cериализовалась да и десериализовалась
Ситуация: есть некоторые объекты, которые надо долговременно хранить (в БД/на диске).
Платформа: .NET
Очевидное решение: десериализация.
Неочевидная проблема: если у сборки, где определен сериализованный тип меняется строгое имя (strong name), десериализация объета невозможна.
Пояснение: Любой тип в .NET характеризуется именем, структурой И сборкой, в которой он определен. Это сделано целенаправленно, чтобы избежать глюков/дыр в связи с наличием нескольких типов, имеющих одинаковые имена.
Для идентификации сборки используется ее строгое имя, т.е. совокупность имени, версии и
публичного ключа автора/издателя.
Если у сборки изменить строгое имя, то при десериализации ранее сериализованного объекта окажется, что система просто не знает, где определен тип, к которому он принадлежит.
Решения:
а) подписывать сборки проекта как можно раньше и не менять публичный ключ.
б) не использовать стандартный механизм сериализации для хранения данных, если есть вероятность, что публичный ключ может быть изменен впоследствии.
Первый вариант, безусловно, наиболее предпочтительный. Но не всегда реальный. Увы.
Второй хорош для RealProgrammer'а, который считает злом использование готовых решений. Можно, скажем, ручками писать поля объектов в поток. Но при необходимости сериализовать объекты разных классов издержки оказываются слишком велики. Еще один вариант - XML-сериализация - может оказаться неприемлемым по всем тем причинам, по которым XML
оказывается менее предпочтительным, нежели бинарный формат.
Остается последний вариант
в) найти способ ручного управления выбором типов.
Оказалось, что третий путь (как обычно ;)) наиболее простой и эффективный (с т.зр. расширяемости). Для этого достаточно создать свою реализацию класса System.Runtime.Serialization.SerializationBinder.
Конкретно - перекрыть в нем метод BindToType.
А затем задать экземпляр своего класса в качестве значения свойства Binder.
Bingo! Привязка осуществляется корректно.
Причем, насколько я понимаю, даже не обязательно реализовывать в привязываемом типе ISerializable, достаточно атрибута
[Serializable].
Платформа: .NET
Очевидное решение: десериализация.
Неочевидная проблема: если у сборки, где определен сериализованный тип меняется строгое имя (strong name), десериализация объета невозможна.
Пояснение: Любой тип в .NET характеризуется именем, структурой И сборкой, в которой он определен. Это сделано целенаправленно, чтобы избежать глюков/дыр в связи с наличием нескольких типов, имеющих одинаковые имена.
Для идентификации сборки используется ее строгое имя, т.е. совокупность имени, версии и
публичного ключа автора/издателя.
Если у сборки изменить строгое имя, то при десериализации ранее сериализованного объекта окажется, что система просто не знает, где определен тип, к которому он принадлежит.
Решения:
а) подписывать сборки проекта как можно раньше и не менять публичный ключ.
б) не использовать стандартный механизм сериализации для хранения данных, если есть вероятность, что публичный ключ может быть изменен впоследствии.
Первый вариант, безусловно, наиболее предпочтительный. Но не всегда реальный. Увы.
Второй хорош для RealProgrammer'а, который считает злом использование готовых решений. Можно, скажем, ручками писать поля объектов в поток. Но при необходимости сериализовать объекты разных классов издержки оказываются слишком велики. Еще один вариант - XML-сериализация - может оказаться неприемлемым по всем тем причинам, по которым XML
оказывается менее предпочтительным, нежели бинарный формат.
Остается последний вариант
в) найти способ ручного управления выбором типов.
Оказалось, что третий путь (как обычно ;)) наиболее простой и эффективный (с т.зр. расширяемости). Для этого достаточно создать свою реализацию класса System.Runtime.Serialization.SerializationBinder.
Конкретно - перекрыть в нем метод BindToType.
class MyBinder: SerializationBinder{
public override Type BindToType(string assemblyName, string TypeName){
// логика выбора типа на основе имени сборки, версии и пр.
else return null;
}
}А затем задать экземпляр своего класса в качестве значения свойства Binder.
BinaryFormatter bf = new BinaryFormatter();
bf.Binder = new MyBinder();
Bingo! Привязка осуществляется корректно.
Причем, насколько я понимаю, даже не обязательно реализовывать в привязываемом типе ISerializable, достаточно атрибута
[Serializable].
воскресенье, января 21, 2007
Я вот подумал, и решил использовать этот блог для технических постов, ранее публиковавшихся в моем ЖЖ под тегом "мой Вавилон".
Потому как ЖЖ - он по сути своей всё-таки вещь для более гуманных проявлений жизнедеятельности, нежели сравнение кода, порождаемого компиляторам Хаскелля, Немерля и Волта...
Ну, вы поняли =)
Посему там будут только краткие отрывки из описания моих программных эскапад, а здесь - более развернутые рассказы.
Потому как ЖЖ - он по сути своей всё-таки вещь для более гуманных проявлений жизнедеятельности, нежели сравнение кода, порождаемого компиляторам Хаскелля, Немерля и Волта...
Ну, вы поняли =)
Посему там будут только краткие отрывки из описания моих программных эскапад, а здесь - более развернутые рассказы.
воскресенье, сентября 17, 2006
По итогам вчерашних полночных бдений за связкой FarEditor-csc
1) Функции высшего порядка и ленивые списки (в т.ч. реализованные через итераторы .NET) рулят;
2) Использование вышеперечисленного и generic-ов вообще в языке, не поддерживающем type-inference - акт мазохизма;
3) отсутствие механизма макросов в Шарпе начинает напрягать... избаловался, блин!
Юзаю Nemerle и жду третьего шарпа. Хотя зачем?
2) Использование вышеперечисленного и generic-ов вообще в языке, не поддерживающем type-inference - акт мазохизма;
3) отсутствие механизма макросов в Шарпе начинает напрягать... избаловался, блин!
Юзаю Nemerle и жду третьего шарпа. Хотя зачем?
воскресенье, августа 27, 2006
Продолжая тему языков ;)
Изучаю внутренности такого замечательного языка, как Mondrian.
Краткая характерстика:
- "чистый" (без побочных эффектов) функциональный язык;
- по синтаксису - смесь урезанного Haskell'а с Java;
- как и Хаскелл, реализует очень своеобразный ООП;
- компилится под .NET 1.1 (под 2.0, ес-сно, тоже);
- предполагаемая ниша - ASP.NET-программирование;
Также в пакет входит и компилятор для Haskell под .NET (для работы требуется наличие компилятора GHC, точнее, видимо, его либ), правда, скорее препроцессор Haskell->Mondrian.
Впрочем, сам компилятор Mondrian порождает код на C#, так что компиляция с Haskell представляет собой компиляцию Haskell->Mondrian->C#->.NET. Что само по себе забавно :)
Впрочем, это еще детский сад.
Дело в том, что, насколько мой рассудок смог определить, программа на Mondrian выполняется в собственной виртуальной машине(!), реализованной в .NET(!!!).
По кр.м. программка HelloWorld трансформировалась в 50 шарповых строк, программка с двумя версиями вычисления факториала (рекурсивной и оконечно-рекурсивной) - в 300 с лишним (что утешает, т.к. заметно, что объем генерируемого кода растет нелинейно ;)).
Самый шок наступил, когда я заглянул в их ран-тайм библиотечку (исходники качать было в лом, посему заюзал мегаинструмент Reflector, декомпилирующий .NET-код в CIL, C#, VB, Delphi, MC++ и Chrome).
Так вот, эти извращенцы мало того, что наваяли свою ВМ, так они еще и написали, скажем, своb класс ы Vector, Stack и т.п. (что назыается, для внутреннего пользования), причем всякие разные перечисления элементов они смело реализовали сами, отлично от подхода, реализуемого в .NET, так как видимо, решили, что при переборе содержимого коллекции гораздо лучше написать
while (enumerator.hasMoreElements())
{
doStuffOn(enumerator.nextElement());
}
нежели
foreach(object in collection)
{
doStuffOn(object);
}
притом, что при нормальной реализации доступны будут оба варианта.
Ну и по мелочам: разницы между Int32 и Int64 компилятор видит с трудом (если видит), большое количество ошибок оставляет на откуп компилятору Шарпа.
Но есть и плюсы:
1) компилятор шустр (шустрее, чем, скажем, Nemerle; впрочем, учитывая интеллектуальность последнего, сравнивать некорректно)
2) синтаксис в чем-то привычнее, чем у Haskell'а;
и 3) проект закрыт!!!!!! Вот это не может не радовать!
на этой оптимистической ноте автор откланивается, предчувствуя, каким невыспанным он будет с утра.
Adieu!
Краткая характерстика:
- "чистый" (без побочных эффектов) функциональный язык;
- по синтаксису - смесь урезанного Haskell'а с Java;
- как и Хаскелл, реализует очень своеобразный ООП;
- компилится под .NET 1.1 (под 2.0, ес-сно, тоже);
- предполагаемая ниша - ASP.NET-программирование;
Также в пакет входит и компилятор для Haskell под .NET (для работы требуется наличие компилятора GHC, точнее, видимо, его либ), правда, скорее препроцессор Haskell->Mondrian.
Впрочем, сам компилятор Mondrian порождает код на C#, так что компиляция с Haskell представляет собой компиляцию Haskell->Mondrian->C#->.NET. Что само по себе забавно :)
Впрочем, это еще детский сад.
Дело в том, что, насколько мой рассудок смог определить, программа на Mondrian выполняется в собственной виртуальной машине(!), реализованной в .NET(!!!).
По кр.м. программка HelloWorld трансформировалась в 50 шарповых строк, программка с двумя версиями вычисления факториала (рекурсивной и оконечно-рекурсивной) - в 300 с лишним (что утешает, т.к. заметно, что объем генерируемого кода растет нелинейно ;)).
Самый шок наступил, когда я заглянул в их ран-тайм библиотечку (исходники качать было в лом, посему заюзал мегаинструмент Reflector, декомпилирующий .NET-код в CIL, C#, VB, Delphi, MC++ и Chrome).
Так вот, эти извращенцы мало того, что наваяли свою ВМ, так они еще и написали, скажем, своb класс ы Vector, Stack и т.п. (что назыается, для внутреннего пользования), причем всякие разные перечисления элементов они смело реализовали сами, отлично от подхода, реализуемого в .NET, так как видимо, решили, что при переборе содержимого коллекции гораздо лучше написать
while (enumerator.hasMoreElements())
{
doStuffOn(enumerator.nextElement());
}
нежели
foreach(object in collection)
{
doStuffOn(object);
}
притом, что при нормальной реализации доступны будут оба варианта.
Ну и по мелочам: разницы между Int32 и Int64 компилятор видит с трудом (если видит), большое количество ошибок оставляет на откуп компилятору Шарпа.
Но есть и плюсы:
1) компилятор шустр (шустрее, чем, скажем, Nemerle; впрочем, учитывая интеллектуальность последнего, сравнивать некорректно)
2) синтаксис в чем-то привычнее, чем у Haskell'а;
и 3) проект закрыт!!!!!! Вот это не может не радовать!
на этой оптимистической ноте автор откланивается, предчувствуя, каким невыспанным он будет с утра.
Adieu!
четверг, августа 17, 2006
А я молодец!..
Наваял-таки мегакласс, который отбирает из компонентов лежащих на форме только имеющие нужный тип и позволяет выбрать из них нужный для установки property в другом компоненте/контроле.
Причем, после написания проверил, нет ли чего-то такого уже готового ;) во фреймворке. Как ни странно, нет! Даже велосипеда не получилось :)
Теперь устанавливать связи между компонентами можно в режиме визуальной разработки. Приятно!
Причем для подключения мегадевайсины надо всего лишь установить атрибут. Правда, достаточно корявый, так что тут есть над чем работать.
Причем, после написания проверил, нет ли чего-то такого уже готового ;) во фреймворке. Как ни странно, нет! Даже велосипеда не получилось :)
Теперь устанавливать связи между компонентами можно в режиме визуальной разработки. Приятно!
Причем для подключения мегадевайсины надо всего лишь установить атрибут. Правда, достаточно корявый, так что тут есть над чем работать.
четверг, июля 13, 2006
Загадки дизайна .NET Base Class Library
В целом архитектура .NET мне нравится. Но есть некоторые загадки, в частности, в BCL...
Простой пример: пытаюсь (в N-ый раз) построить что-то вроде конвейера, чтобы можно было параллельно обрабатывать поток изображений.
Ну и мне влом описывать классы для этих самых наборов промежуточных результатов. А так как я последнее время загоняюсь по ФП, сразу захотелось поюзать кортежи, ведь это стандартная фича всех ФЯП. Однако пишется проект на Шарпе, а не на Nemerle ;), соответственно, встроенной поддержки кортежей нет :( Стал искать нечто подобное в библиотеке .NET.
Не поверите, но нашел. Но отнюдь не в System.Collections.Generic, не в System.Collections и не в System.Collections.Specialized.
Знаете, где?
В System.Web.UI! %)
Причем, увы, использование требует явного приведения типов (ибо хранятся там System.Object'ы), и имеются в наличии только пары (Pair) и триплеты (Triplet). Чего мне, в принципе, могло бы и хватить, но добавлять ссылки на System.Web меня не радует, так что лучше напишу сам ;)
Простой пример: пытаюсь (в N-ый раз) построить что-то вроде конвейера, чтобы можно было параллельно обрабатывать поток изображений.
Ну и мне влом описывать классы для этих самых наборов промежуточных результатов. А так как я последнее время загоняюсь по ФП, сразу захотелось поюзать кортежи, ведь это стандартная фича всех ФЯП. Однако пишется проект на Шарпе, а не на Nemerle ;), соответственно, встроенной поддержки кортежей нет :( Стал искать нечто подобное в библиотеке .NET.
Не поверите, но нашел. Но отнюдь не в System.Collections.Generic, не в System.Collections и не в System.Collections.Specialized.
Знаете, где?
В System.Web.UI! %)
Причем, увы, использование требует явного приведения типов (ибо хранятся там System.Object'ы), и имеются в наличии только пары (Pair) и триплеты (Triplet). Чего мне, в принципе, могло бы и хватить, но добавлять ссылки на System.Web меня не радует, так что лучше напишу сам ;)
вторник, мая 23, 2006
Третий путь ведет к просветлению...
Ага, я порадовался, конечно, что надыбал набор COM-объектов (и документацию достал!), котороые очень удобно использовать в .NET, достаточно только поутюжить dll-ку tlbimp-ом.
Только вот маленькая незадача: TlbImp не всегда корректно распознает типы. Т.е., если в COM-овской библиотеке типов был в качестве параметра unsigned char* (т.е., как правило, С-шный массив), то наивная утилита его представит как ref byte, а не как byte[]. Что, в общем-то, логично. Информацию о том, что сие есть, ей взять неоткуда. Или, скажем, вместо всенародно любимого винапишного HANDLE (который суть void* и которому в .NET соответстует IntPtr) везде оказался int.
Проблема №2: как известно, все COM-объекты реализуют интерфейс IUnknown. А посему стандартной является ситуация, при которой во все методы передается как раз IUnknown, а там представляемый им объект проверяется на прочие интерфейсы. Я вот лично считаю, что сие в общем случае есть антипаттерн. Ибо: 1) ликвидирует остатки типобезопасности; 2) код ни хрена не самодокументируемый (блин, я вот догадался, что IUnknown* pDibImage - это IDibImage pDibImage; а вот tlbimp - нет); 3) снижает расширяемость кода.
Но вернемся к нашимбаранамобъектам. Как уж сказано, TlbImp не одарен ИИ (что вы хотите от утилиты весом 56K?) и венгерскую нотацию читать не умеет (я вот тоже не силен). Посему он тупо поставил в соответствие всем IUnknown* по Object'у и немедленно выпил сказал, что преобразование закончено. Меня эта ситуация не устроила, бо я уже воевал с подобными обертками и больше как-то не хочется.
Короче, задача звучит так: прикрутить либы к программе.
Варианты: 1) использовать "как есть". Отметен, как отстойный. Во-первых, придется постоянно делать приведение типов от Object к реальным типам объектов. А это суть кака. Во-вторых, если все методы, работающие, скажем, с хендлом окна будут требовать int, то я задолбаюсь писать MyWin.Handle.ToInt32(). И, что самое существенное, мне не хочется даже думать о том, как передать byte[] вместо ref byte. Скорее всего, это требует грязных извратов.
2) Написать обертку самому. Десяток классов (методов по 20), плюс реализуемые ими интерфейсы, которые, кажись, тоже придется описывать... Извиняйте, ломает.
3) Путь воина. ОтILDASMить сборку, поправить нужные места, сассемблировать ILASM'ом. Вот оно!!! Править нужно далеко не все, причем, в связи с регулярной структурой сборки, можно все это автоматизировать.
Попробовал. Понравилось. Особенно грело душу, когда после компиляции тестовая прога продолжала работать правильно. А ObjectBrowser в Студии показывал результаты моих трудов =)
Восторг - непередаваемый! Видно, что не совсем ишо тупой. Мелочь, а приятно...
Теперь осталось сочинить прожку, которая будет делать такую конверсию автоматически, на основании имен в венгерской записи. Должна же быть от этого израта хоть какая-то польза!! Главное - не забить ;)
З.Ы.: Все-таки я не хакер. Меня не заставишь лезть куда-то на нижний уровень, пока не припрет производственная необходимость. :)))
Только вот маленькая незадача: TlbImp не всегда корректно распознает типы. Т.е., если в COM-овской библиотеке типов был в качестве параметра unsigned char* (т.е., как правило, С-шный массив), то наивная утилита его представит как ref byte, а не как byte[]. Что, в общем-то, логично. Информацию о том, что сие есть, ей взять неоткуда. Или, скажем, вместо всенародно любимого винапишного HANDLE (который суть void* и которому в .NET соответстует IntPtr) везде оказался int.
Проблема №2: как известно, все COM-объекты реализуют интерфейс IUnknown. А посему стандартной является ситуация, при которой во все методы передается как раз IUnknown, а там представляемый им объект проверяется на прочие интерфейсы. Я вот лично считаю, что сие в общем случае есть антипаттерн. Ибо: 1) ликвидирует остатки типобезопасности; 2) код ни хрена не самодокументируемый (блин, я вот догадался, что IUnknown* pDibImage - это IDibImage pDibImage; а вот tlbimp - нет); 3) снижает расширяемость кода.
Но вернемся к нашим
Короче, задача звучит так: прикрутить либы к программе.
Варианты: 1) использовать "как есть". Отметен, как отстойный. Во-первых, придется постоянно делать приведение типов от Object к реальным типам объектов. А это суть кака. Во-вторых, если все методы, работающие, скажем, с хендлом окна будут требовать int, то я задолбаюсь писать MyWin.Handle.ToInt32(). И, что самое существенное, мне не хочется даже думать о том, как передать byte[] вместо ref byte. Скорее всего, это требует грязных извратов.
2) Написать обертку самому. Десяток классов (методов по 20), плюс реализуемые ими интерфейсы, которые, кажись, тоже придется описывать... Извиняйте, ломает.
3) Путь воина. ОтILDASMить сборку, поправить нужные места, сассемблировать ILASM'ом. Вот оно!!! Править нужно далеко не все, причем, в связи с регулярной структурой сборки, можно все это автоматизировать.
Попробовал. Понравилось. Особенно грело душу, когда после компиляции тестовая прога продолжала работать правильно. А ObjectBrowser в Студии показывал результаты моих трудов =)
Восторг - непередаваемый! Видно, что не совсем ишо тупой. Мелочь, а приятно...
Теперь осталось сочинить прожку, которая будет делать такую конверсию автоматически, на основании имен в венгерской записи. Должна же быть от этого израта хоть какая-то польза!! Главное - не забить ;)
З.Ы.: Все-таки я не хакер. Меня не заставишь лезть куда-то на нижний уровень, пока не припрет производственная необходимость. :)))
воскресенье, мая 21, 2006
В Шаолинь, животное!!!!
Я вот не знаю занятия, более воспитывающего силу воли и помогающего осознать глубинную сущность программирования, чем reverse-engineering.
Берем библиотечку объемом ~30-40 метров. Загружаем IDA. Медитируем...
До полного просветления/схождения с ума (обычно это равноценные понятия)
Берем библиотечку объемом ~30-40 метров. Загружаем IDA. Медитируем...
До полного просветления/схождения с ума (обычно это равноценные понятия)
суббота, мая 20, 2006
Учите матчасть, бойцы!..
Блин, месяца два мы воевали, завертывая одну библиотечку (вернее, набор оных) до вида, более-менее удобного для использования (и просто удобного, и приемлемого в .NET-е). Ухху...
Сегодня попробовал обработать ее tlbimp-ом, о котором совсем недавно прочел (кто не знает - это утилитка из .NET SDK, которая по библиотеке типов COM создает сборку .NET). Обработал. Посмотрел ей внутре. Возматерился.
Ибо половину работы это с нас бы сняло. Там почти все (как я и предполагал) оформлено COM-объектами. Которые вполне приживаются в .NET.
Единственный минус - что эти объекты документированы еще хуже чем в скрывающей их библиотеке. Ибо в документации к той хотя бы по 4 строчки к каждой функции (из сотни) написано. А к объектам - вообще ничего.
Но все равно - инструментарий надо знать!!!
Сегодня попробовал обработать ее tlbimp-ом, о котором совсем недавно прочел (кто не знает - это утилитка из .NET SDK, которая по библиотеке типов COM создает сборку .NET). Обработал. Посмотрел ей внутре. Возматерился.
Ибо половину работы это с нас бы сняло. Там почти все (как я и предполагал) оформлено COM-объектами. Которые вполне приживаются в .NET.
Единственный минус - что эти объекты документированы еще хуже чем в скрывающей их библиотеке. Ибо в документации к той хотя бы по 4 строчки к каждой функции (из сотни) написано. А к объектам - вообще ничего.
Но все равно - инструментарий надо знать!!!
пятница, апреля 28, 2006
1961 - I "barely saw" the idea several times ca. 1961... The first was on the Burroughs 220 in the form of a style for transporting files from one Air Training Command installation to another. There were no standard operating systems or file formats back then, so some (t this day unknown) designer decided to finesse the problem by taking each file and dividing it into three parts. The third part was all of the actual data records of arbitrary size and format. The second part contained the B220 procedures that knew how to get at records and fields to copy and update the third part. And the first part was an array or relative pointers into entry points of the procedures in the second part (the initial pointers were in a standard order representing standard meanings).
К слову сказать, файлы тогда на перфолентах были... В лучшем случае...
1966 - The title was "Sketchpad: A man-machine graphical communication system" [Sutherland, 1963]. What it could do was quite remarkable, and completely foreign to any use of a computer I had ever encountered. The three big ideas that were easiest to grapple with were: it was the invention of modern interactive computer graphics; things were described by making a "master drawing" that could produce "instance drawings"; control and dynamics were supplied by "constraints," also in graphical form, that could be applied to the masters to shape an inter-related parts. Its data structures were hard to understand--the only vaguely familiar construct was the embedding of pointers to procedures and using a process called reverse indexing to jump through them to routines, like the 22- file system [Ross, 1961]. It was the first to have clipping and zooming windows...
так, вот уже и окошки показались...
Soon Dan had bootstrapped Smalltalk across , and for many months it was the sole software sytem to run on the Interim dynabook. Appendix I has an "acknowledgements" dodcument I wrote from this time that is interesting it its allocation of credits and the various priorities associated with them. My $230K was enough to get 15 of the original projected 30 machines (over the years some 2000 Interim Dynabooks were actually built. True to Schopenhauer's observation, Executive "X" now decided that the Interim Dynabook was a good idea and he wanted all but two for his lab (I was in the other lab). I had to go to considerable lengths to get our machines back, but finally succeeded.
Создание машин специально для ОО-систем...
И просто золотые слова:
Another way to think of all this is: though the late-binding of automatic storage allocations doesn't do anything a programmer can't do, its presence leads both to simpler and more powerful code. OOP is a late binding strategy for many things and all of them together hold off fragility and size explosion much longer than the older methodologies. In other words, human programmers aren't Turing machines--and the lesss their programming systems require Turing machine techniques the better.
Взято из "Early History of SmallTalk".
К слову сказать, файлы тогда на перфолентах были... В лучшем случае...
1966 - The title was "Sketchpad: A man-machine graphical communication system" [Sutherland, 1963]. What it could do was quite remarkable, and completely foreign to any use of a computer I had ever encountered. The three big ideas that were easiest to grapple with were: it was the invention of modern interactive computer graphics; things were described by making a "master drawing" that could produce "instance drawings"; control and dynamics were supplied by "constraints," also in graphical form, that could be applied to the masters to shape an inter-related parts. Its data structures were hard to understand--the only vaguely familiar construct was the embedding of pointers to procedures and using a process called reverse indexing to jump through them to routines, like the 22- file system [Ross, 1961]. It was the first to have clipping and zooming windows...
так, вот уже и окошки показались...
Soon Dan had bootstrapped Smalltalk across , and for many months it was the sole software sytem to run on the Interim dynabook. Appendix I has an "acknowledgements" dodcument I wrote from this time that is interesting it its allocation of credits and the various priorities associated with them. My $230K was enough to get 15 of the original projected 30 machines (over the years some 2000 Interim Dynabooks were actually built. True to Schopenhauer's observation, Executive "X" now decided that the Interim Dynabook was a good idea and he wanted all but two for his lab (I was in the other lab). I had to go to considerable lengths to get our machines back, but finally succeeded.
Создание машин специально для ОО-систем...
И просто золотые слова:
Another way to think of all this is: though the late-binding of automatic storage allocations doesn't do anything a programmer can't do, its presence leads both to simpler and more powerful code. OOP is a late binding strategy for many things and all of them together hold off fragility and size explosion much longer than the older methodologies. In other words, human programmers aren't Turing machines--and the lesss their programming systems require Turing machine techniques the better.
Взято из "Early History of SmallTalk".
четверг, апреля 06, 2006
И эти люди запрещают мне ковыряться в носу!..
Я хре фигею с того, чем занимается Microsoft Research!
Им мало F# (клона OCaml под .NET), им мало С-omega (C# с элементами SQL; он, правда, как отдельный продукт не выйдет). У них есть еще и Vault.
Вкратце - это почти С (т.е. императивный "curly brackets" язык), но:
- со строгой типизацией;
- с модульностью;
- с generic функциями (например, передача параметра по ссылке реализуется именно с их помощью);
- с многочисленными реверансами в сторону ФП, как-то произвольное место объявления функций, передача их как параметры, кложуры, currying (!) и т.п.
- с непривычными для императивных языков типами, вроде кортежей (tuple) и вариантов (замена для enum'ов и union'ов), тоже явно перекочевавшими из Haskell и ML;
- с pattern-matching'ом (правда, только для switch'ей) оттуда же;
- с дополнительными атрибутами для типов (сам плохо понял и нервно курю, но похоже, что-то вроде DesignByContract на этапе компиляции - например для контроля того, что файл был открыт перед обращением 8-/);
Ужос!!! Если бы сюда еще и ООП, я бы возлюбил это всем сердцем (может быть)... Но где стал бы на этом писать - не знаю..
Им мало F# (клона OCaml под .NET), им мало С-omega (C# с элементами SQL; он, правда, как отдельный продукт не выйдет). У них есть еще и Vault.
Вкратце - это почти С (т.е. императивный "curly brackets" язык), но:
- со строгой типизацией;
- с модульностью;
- с generic функциями (например, передача параметра по ссылке реализуется именно с их помощью);
- с многочисленными реверансами в сторону ФП, как-то произвольное место объявления функций, передача их как параметры, кложуры, currying (!) и т.п.
- с непривычными для императивных языков типами, вроде кортежей (tuple) и вариантов (замена для enum'ов и union'ов), тоже явно перекочевавшими из Haskell и ML;
- с pattern-matching'ом (правда, только для switch'ей) оттуда же;
- с дополнительными атрибутами для типов (сам плохо понял и нервно курю, но похоже, что-то вроде DesignByContract на этапе компиляции - например для контроля того, что файл был открыт перед обращением 8-/);
Ужос!!! Если бы сюда еще и ООП, я бы возлюбил это всем сердцем (может быть)... Но где стал бы на этом писать - не знаю..
среда, декабря 21, 2005
PDP-11 как колыбель современного программирования и могила рассудка
Кое-кто слышал, вероятно, про линейку миникомпьютеров PDP от компании DEC, весьма популярную в 70-е годы.
"Мини" не должно вводить в заблуждение. Эти миникомпьютеры были размером со средних размеров секретер. Однако уже и такие размеры были большим достижением. Что более существенно, рабочее время этих машин было дешевле чем время мэйнфреймов. Да и сами они были относительно недороги...
PDP внесли существенный вклад в развитие IT. В частности, первые версии UNIX и C создавались вначале на PDP-7, а затем на PDP-11. Хвалебные оды PDP-11 как отправной точке множества хакеров (в широком смысле этого слова) возносит небезызвестный Крис Касперски... Клонировали машины все, кому было не лень. В частности, широкое распространение машины с процессором PDP-11 (это была не микросхема, а плата с набором микросхем) получили в СССР под названием "Электроника-60" (впрочем, у нас тогда все передирали у янки)
А причина популярности была в развитой системе команд. Для каждого из операндов (всего их могло быть 2) имелось 8 способов адресации через каждый из регистров (в том числе и через R7 - счетчик команд!). В результате можно был делать очень интересные вещи.
Например, вызов функции
myFunc(1, 2)
мог быть странслирован в следующий процуссорный код:
JSR R0, myFunc ; переход на myFunc с сохранением адреса возрата в R0
1 ; op1
2 ; op2
MOV R1, C. ; сюда будет осуществлен возврат
myFunc:
MOV (R0)+, R1 ; R1 = *R0++
ADD (R0)+, R1 ; R1 += *R0++
RTS R0 ; возврат по адресу в R0
Как видно, компилятор для такой системы команд писать одно удовольствие.
Машину на ее основе собрать тоже несложно. Причем в ней даже не обязательно обеспечивать стек. Как видно, вызов подпрограмм и так работать будет.
Надо сказать, что эта система команд и поныне широко используется, например, в контроллерах станков и т.п.. Естественно, теперь процессор реализуется интегрально.
Так я это к чему? А к тому, что у нас курсач - "Проектирование процессора с сокращенным набором команд на основе системы команд PDP-11". И мне эта система команд уже вот где!!!! Млин, им хорошо было придумывать, а мы сношайся!
Как прикажете трактовать команду JMP @(R7)+ ?
- как addr = *R7, R7 = *addr, R7++
- как addr = *R7, R7++, R7 = *addr
- или еще как-то?
А как быть с двухадресными командами? Например, с BIT @Array(R7), @(R7)+ (команда BIT вычисляет логическое И аргументов без записи результата)? Это же полный бульбец!!!
Нет, понятно, что здоровый человек так не напишет, но есть у меня знакомые, которые могли бы (да, Лёша, я говорю о тебе!)
А еще бесит реализация конвейера. Потому что любое изменение значения счетчика команд или же использование данных лежащих после кода команды херит к чертовой матери весь конвейер (а он всего-то 3 уровня; что бы было при большей глубине - страшно подумать!).
Охренеть!!!
Слава Богу, мне еще не надо результаты записывать в память. А то я бы уже отъехал в район АМЗ
Да здравствует архитектура RISC!!!!!!!!!
"Мини" не должно вводить в заблуждение. Эти миникомпьютеры были размером со средних размеров секретер. Однако уже и такие размеры были большим достижением. Что более существенно, рабочее время этих машин было дешевле чем время мэйнфреймов. Да и сами они были относительно недороги...
PDP внесли существенный вклад в развитие IT. В частности, первые версии UNIX и C создавались вначале на PDP-7, а затем на PDP-11. Хвалебные оды PDP-11 как отправной точке множества хакеров (в широком смысле этого слова) возносит небезызвестный Крис Касперски... Клонировали машины все, кому было не лень. В частности, широкое распространение машины с процессором PDP-11 (это была не микросхема, а плата с набором микросхем) получили в СССР под названием "Электроника-60" (впрочем, у нас тогда все передирали у янки)
А причина популярности была в развитой системе команд. Для каждого из операндов (всего их могло быть 2) имелось 8 способов адресации через каждый из регистров (в том числе и через R7 - счетчик команд!). В результате можно был делать очень интересные вещи.
Например, вызов функции
myFunc(1, 2)
мог быть странслирован в следующий процуссорный код:
JSR R0, myFunc ; переход на myFunc с сохранением адреса возрата в R0
1 ; op1
2 ; op2
MOV R1, C. ; сюда будет осуществлен возврат
myFunc:
MOV (R0)+, R1 ; R1 = *R0++
ADD (R0)+, R1 ; R1 += *R0++
RTS R0 ; возврат по адресу в R0
Как видно, компилятор для такой системы команд писать одно удовольствие.
Машину на ее основе собрать тоже несложно. Причем в ней даже не обязательно обеспечивать стек. Как видно, вызов подпрограмм и так работать будет.
Надо сказать, что эта система команд и поныне широко используется, например, в контроллерах станков и т.п.. Естественно, теперь процессор реализуется интегрально.
Так я это к чему? А к тому, что у нас курсач - "Проектирование процессора с сокращенным набором команд на основе системы команд PDP-11". И мне эта система команд уже вот где!!!! Млин, им хорошо было придумывать, а мы сношайся!
Как прикажете трактовать команду JMP @(R7)+ ?
- как addr = *R7, R7 = *addr, R7++
- как addr = *R7, R7++, R7 = *addr
- или еще как-то?
А как быть с двухадресными командами? Например, с BIT @Array(R7), @(R7)+ (команда BIT вычисляет логическое И аргументов без записи результата)? Это же полный бульбец!!!
Нет, понятно, что здоровый человек так не напишет, но есть у меня знакомые, которые могли бы (да, Лёша, я говорю о тебе!)
А еще бесит реализация конвейера. Потому что любое изменение значения счетчика команд или же использование данных лежащих после кода команды херит к чертовой матери весь конвейер (а он всего-то 3 уровня; что бы было при большей глубине - страшно подумать!).
Охренеть!!!
Слава Богу, мне еще не надо результаты записывать в память. А то я бы уже отъехал в район АМЗ
Да здравствует архитектура RISC!!!!!!!!!
понедельник, ноября 21, 2005
| Я - хард |
Иначе говоря, винчестер. Хранитель информации. А кто владеет информацией, тот владеет миром, важно помнить. Не смотря на возможную молчаливсть, вы являетесь сутью и содержанием, если так можно выразиться, компьютера. Но по жизни помните, что в принципе под лежачий камень вода затекает редко, и если дело совсем плохо, то надо срочно искать того, кто станет процессором и "мозгом". А там уж и до целой машины недалеко. |
Пройти тест 'Какая ты деталь компьютера?' |
среда, ноября 02, 2005
С. Трофимов - Распутица
Боже мой, как она надоела, осенняя эта распутица!
Целый день по колено грязи еле тащишься по верстовой.
Может, встать и дождаться ночного мороза, чтоб больше не мучиться,
И по первому насту придти, смертельно усталый, домой...
Возвращаюсь. Земля белым снегом укрыта от сглаза небесного,
Небо к осени, видно, устало проповедовать свет и тепло.
Плачет ветер, вселенскую смерть поминая унылою песнею.
Только я по колено в грязи все пытаюсь идти этой смерти назло.
Возвращаюсь. Нагие деревья стыдливо скрываются в сумерках.
Не признали меня, устыдились, а ведь я их когда-то растил.
Даже месяц, мой спутник унылый, испуганно прячется в облака,
Только грубою лаской мороз, как и прежде, меня приютил.
Путь неблизкий. Седая пурга до весны заметает мои следы.
Я последний, кто шел по дороге до Покрова, что в ночь начался.
Утром мир будет девственно чистым, не знающим ни счастия, ни беды.
Значит, грязь это только преддверие счастья нового и красоты бытия
Целый день по колено грязи еле тащишься по верстовой.
Может, встать и дождаться ночного мороза, чтоб больше не мучиться,
И по первому насту придти, смертельно усталый, домой...
Возвращаюсь. Земля белым снегом укрыта от сглаза небесного,
Небо к осени, видно, устало проповедовать свет и тепло.
Плачет ветер, вселенскую смерть поминая унылою песнею.
Только я по колено в грязи все пытаюсь идти этой смерти назло.
Возвращаюсь. Нагие деревья стыдливо скрываются в сумерках.
Не признали меня, устыдились, а ведь я их когда-то растил.
Даже месяц, мой спутник унылый, испуганно прячется в облака,
Только грубою лаской мороз, как и прежде, меня приютил.
Путь неблизкий. Седая пурга до весны заметает мои следы.
Я последний, кто шел по дороге до Покрова, что в ночь начался.
Утром мир будет девственно чистым, не знающим ни счастия, ни беды.
Значит, грязь это только преддверие счастья нового и красоты бытия
вторник, ноября 01, 2005
Google как искусственный интеллект
Поисковые машины, похоже, уже сейчас обладают искусственным интеллектом. Я об этом говорил в комменте к посту grandmag'а о необычных услугах yandex'а и сегодня снова в этом убедился.
Просто посмотрите на верхнюю строчку результатов поиска в Google'е по слову 'failure'....
Просто посмотрите на верхнюю строчку результатов поиска в Google'е по слову 'failure'....
Подписаться на:
Сообщения (Atom)