Благодарю за ссылку, почитаю. Мои заметки по Haskell — это изложение того, как я понял ту или иную тему в ходе её изучения. Я не исключаю, что какой-то материал мною мог быть понят неверно. Опубликовывая информацию по Haskell через призму своего текущего понимания, я тем самым ожидаю, что более опытные люди смогут аргументированно указать мне на мои ошибки (собственно ради этого и опубликовываю).
М. Липовача «Изучай Haskell во имя добра!», стр 159: Примечание. Мы называем тип конкретным, если он вообще не принимает параметров (например Int или Bool) либо если параметры в типе заполнены (например, Maybe Char). Если у вас есть какое-то значение, у него всегда конкретный тип.
Пообщавшись на stackoverflow.com/ я понял, что моё определение понятия оператора оказалось не совсем верным. В свете этого я внёс исправления в исходный материал заметки.
Операторы можно составлять как угодно, за исключением следующих комбинаций:
« :: =… — @ \ | < — -> ~ => »
Однако следующий код работает:
(=...)::Int->[Char]->[Char]
a =... b = show a ++ ' ' : b
Проверяю:
ghci> :l src
[1 of 1] Compiling Main ( src.hs, interpreted )
Ok, modules loaded: Main.
ghci> let a = 123
ghci> let b = «asdf»
ghci> a =… b
«123 asdf»
ghci> (=...) a b
«123 asdf»
ghci>
Подскажите, а где можно почитать про обратную совместимость версий именно для .NET-плагинов?
Здесь я перечислил четыре пункта, выполнение которых существенно повышает вероятность совместимости. Официальной информации по этому вопросу нет, насколько мне известно. То, что я пишу — основано на собственном опыте.
Про «заглушки» я не вполне осмыслил. Получается, что для AutoCAD до 2011 версии рекомендуется создавать две отдельные сборки проекта — под x86 и x64, иначе возможны проблемы?
Вы невнимательно читали указанную мною ссылку — я ведь там пояснил, в каких случаях сборку можно компилировать как AnyCPU, а в каких собирать отдельно под x86 и x64. Пояснение: управляемые DLL файлы, подключаемые из Object ARX SDK я называю «заглушками» по той причине, что в процессе работы Ваше расширение будет использовать не их (Copy Local = False), но реальные одноимённые DLL файлы из каталога AutoCAD. Заглушки, как правило, не совпадают с «боевыми» DLL по размеру, что наводит на мысль, что они не идентичны по составу.
Как-то раз заказчик спросил: «А с какими версиями AutoCAD сможет работать программа?», и мне пришлось изрядно времени потратить на поиски ответа. В целом, ответ звучит так: «Autodesk поддерживает обратную совместимость в течение трех лет».
Обозначенный ответ не имеет никакого отношения к обозначенному вопросу. Обозначенный ответ относится к расширениям, написанным на C++. Для .NET расширений действуют иные «правила игры».
ObjectARX SDK – набор библиотек, необходимых для работы с AutoCAD.
Неверно. Это набор библиотек, необходимых для написания расширений под AutoCAD (почувствуй разницу). Работать с AutoCAD можно и через COM, используя позднее связывание — в этом случае ObjectARX SDK не используется вовсе.
>Пока задачи перекомпилировать программу с другими библиотеками у меня не возникало. Думаю, что это хорошо: перспектива создавать отдельную версию продукта для других выпусков AutoCAD не радует совершенно.
Здесь, в комментарии от 11 сентября 2014 г. 12:19 рассказано, как это решается «малой кровью».
«AutoCAD .NET Wizard» – шаблон проекта для создания плагинов под AutoCAD. Люди знающие говорят, что этот шаблон сильно упрощает жизнь;
Это утверждение справедливо скорее к Wizard для C++, чем для .NET. Лично я при создании .NET расширений под AutoCAD предпочитаю не юзать «визард»…
Если плагин предназначен для старой версии AutoCAD, то целесообразно сразу же задать в свойствах проекта версию .NET, которую будем использовать.
Версию .NET целесообразно задавать в любом случае. Информация о совместимости приведена здесь
>Эти DLL-файлы находятся в папке с именем inc-<наименование_архитектуры>.
В более свежих версиях AutoCAD часть управляемых DLL находится в подкаталоге inc.
у меня дома установлена 32-разрядная ОС, у заказчика – 64-разрядная. Пока серьезных проблем с совместимостью не возникало. Но однажды я все же напоролся на то, что у меня функция возвращала Int32, а у заказчика – Int64. Линковщик ОЧЕНЬ расстраивался. Нужно иметь эту особенность в виду.
Исчерпывающего перечня сопоставлений я найти не смог, поэтому все проверялось методом научного тыка. Если есть более правильный способ, было бы интересно его узнать…
Плохой «способ\метод». «Исчерпывающий перечень» тебе и не нужен — подключать следует только то, что тебе действительно необходимо. Как правило, это acdbmgd.dll, acmgd.dll, (acoremgd.dll — для AutoCAD 2013 или новее). Почитай это
обязательно запретите копирование библиотек AutoCAD .NET API в каталог сборки при построении проекта! Для этого найдите в свойствах каждой добавленной ссылки параметр CopyLocal и установите его в False.
Это смотря какие библиотеки подключаются… Почитай на тему TLB файлов здесь
Например, можно создать обычную форму Windows с полями ввода, отобразить ее на экране с помощью ShowModal()
Плохой способ, т.к. в этом случае существует вероятность в AutoCAD поймать Fatal Error. Вместо этого следует пользоваться статическими методами класса Autodesk.AutoCAD.ApplicationServices.Application: для WPF это методы ShowModalWindow и ShowModelessWindow, а для WinForms — методы ShowModalDialog и ShowModelessDialog.
Чтобы «превратить» созданный метод в команду AutoCAD, применяется атрибут CommandMethod. В скобках после него указывается имя создаваемой команды, которое можно будет использовать непосредственно в среде AutoCAD.
По хорошему, «в скобках» должно указываться гораздо больше информации, которая определяет контекст работы команды (приложение или документ), локализованное имя команды, а так же связь с соответствующим разделом справочной системы. Альтернативный, более гибкий вариант управления локализациями команд AutoCAD обозначен здесь
Затем в открывшемся окне указать путь к файлу плагина:
отсутствует изображение.
После этого плагин будет загружен в AutoCAD. Мы должны увидеть первое сообщение:
В наше время уникальной экспетизой может быть редкая, специализированная или новая технология (Tizen, Xamarin, Unity, AutoCAD)
С каких это пор AutoCAD стал «технологией»? AutoCAD — это программное обеспечение из категории САПР (Система Автоматизированного Проектирования). И, откровенно говоря, если заглянуть «под капот» этого ПО, то «тихий ужас» (по части качества его API) обеспечен: огромное количество багов, многое вовсе не тестируется прежде чем попадает в «продакшэн». Причём сей факт (плохое тестирование) компания Autodesk даже и не скрывает.
Смысл опубликовывать вершки, которых нахватался за получасовое чтение мануала? В чём изюм поста? В интернете полно ресурсов, в которых вопросы .NET программирования под AutoCAD изложены более грамотно. Имхо. Ссылка по теме. По содержимому статьи полно замечаний… Если их выписывать — получится новая статья, об ошибках этой…
Потихоньку перевожу на русский документацию по NUnit 2.6. Результаты выкладываю здесь. Посильное участие (проверка перевода, перевод ещё не переведённого) приветствуется.
К сожалению вынужден согласиться… Я какое-то время скрипя зубами занимался сравнением перевода с оригиналом (в виду того, что в локализованном варианте по ходу чтения встречал такие места, в которых написана какая-то нелепая муть)… Затем бросил это дело, ибо книга просто набита ошибками перевода, опечатками и банальным некорректным размещения даже исходного кода программ (хотя казалось бы -уж тут-то какие ошибки???). Закончилось тем, что я бросил её читать и полностью переключился на чтение оригинала, который у меня в pdf-формате (к сожалению).
Оригинальный вариант — замечателен, но текущий локализованный вариант просто отвратителен. На форумах и знакомым программистам я настоятельно не рекомендую покупать её, ибо большая цена в данном случае вовсе не подразумевает соответствующего качества (к сожалению).
п.с. Книги по программированию должны переводить программисты, а не дилетанты, причём не просто программисты, а программисты хорошо знающие английский.
Как видим, перевод действительно отличается…
Однако следующий код работает:
Проверяю:
Здесь я перечислил четыре пункта, выполнение которых существенно повышает вероятность совместимости. Официальной информации по этому вопросу нет, насколько мне известно. То, что я пишу — основано на собственном опыте.
Вы невнимательно читали указанную мною ссылку — я ведь там пояснил, в каких случаях сборку можно компилировать как AnyCPU, а в каких собирать отдельно под x86 и x64. Пояснение: управляемые DLL файлы, подключаемые из Object ARX SDK я называю «заглушками» по той причине, что в процессе работы Ваше расширение будет использовать не их (Copy Local = False), но реальные одноимённые DLL файлы из каталога AutoCAD. Заглушки, как правило, не совпадают с «боевыми» DLL по размеру, что наводит на мысль, что они не идентичны по составу.
Обозначенный ответ не имеет никакого отношения к обозначенному вопросу. Обозначенный ответ относится к расширениям, написанным на C++. Для .NET расширений действуют иные «правила игры».
Неверно. Это набор библиотек, необходимых для написания расширений под AutoCAD (почувствуй разницу). Работать с AutoCAD можно и через COM, используя позднее связывание — в этом случае ObjectARX SDK не используется вовсе.
>Пока задачи перекомпилировать программу с другими библиотеками у меня не возникало. Думаю, что это хорошо: перспектива создавать отдельную версию продукта для других выпусков AutoCAD не радует совершенно.
Здесь, в комментарии от 11 сентября 2014 г. 12:19 рассказано, как это решается «малой кровью».
Это утверждение справедливо скорее к Wizard для C++, чем для .NET. Лично я при создании .NET расширений под AutoCAD предпочитаю не юзать «визард»…
Версию .NET целесообразно задавать в любом случае. Информация о совместимости приведена здесь
>Эти DLL-файлы находятся в папке с именем inc-<наименование_архитектуры>.
В более свежих версиях AutoCAD часть управляемых DLL находится в подкаталоге inc.
Рекомендую почитать это
Плохой «способ\метод». «Исчерпывающий перечень» тебе и не нужен — подключать следует только то, что тебе действительно необходимо. Как правило, это acdbmgd.dll, acmgd.dll, (acoremgd.dll — для AutoCAD 2013 или новее). Почитай это
Это смотря какие библиотеки подключаются… Почитай на тему TLB файлов здесь
Плохой способ, т.к. в этом случае существует вероятность в AutoCAD поймать Fatal Error. Вместо этого следует пользоваться статическими методами класса Autodesk.AutoCAD.ApplicationServices.Application: для WPF это методы ShowModalWindow и ShowModelessWindow, а для WinForms — методы ShowModalDialog и ShowModelessDialog.
По хорошему, «в скобках» должно указываться гораздо больше информации, которая определяет контекст работы команды (приложение или документ), локализованное имя команды, а так же связь с соответствующим разделом справочной системы. Альтернативный, более гибкий вариант управления локализациями команд AutoCAD обозначен здесь
отсутствует изображение.
отсутствует изображение.
отсутствует изображение.
С каких это пор AutoCAD стал «технологией»? AutoCAD — это программное обеспечение из категории САПР (Система Автоматизированного Проектирования). И, откровенно говоря, если заглянуть «под капот» этого ПО, то «тихий ужас» (по части качества его API) обеспечен: огромное количество багов, многое вовсе не тестируется прежде чем попадает в «продакшэн». Причём сей факт (плохое тестирование) компания Autodesk даже и не скрывает.
Оригинальный вариант — замечателен, но текущий локализованный вариант просто отвратителен. На форумах и знакомым программистам я настоятельно не рекомендую покупать её, ибо большая цена в данном случае вовсе не подразумевает соответствующего качества (к сожалению).
п.с. Книги по программированию должны переводить программисты, а не дилетанты, причём не просто программисты, а программисты хорошо знающие английский.
— Состою в браке :)