|
Altium 15.1 |
|
|
3 страниц
1 2 3 >
|
 |
Ответов
(1 - 31)
|
May 5 2015, 11:14
|

Гуру
     
Группа: Модераторы
Сообщений: 11 653
Регистрация: 25-03-05
Из: Минск
Пользователь №: 3 671

|
Цитата(ClayMan @ May 5 2015, 13:34)  Мне кажется, что разработчикам Альтиума прежде чем расширять функционал своей программы было бы очень полезно исправить все косяки и добиться нормальной и стабильной работы программы в текущем ее состоянии. Сам лично до сих пор сижу на 14.3 и глядя на количество багов в 15-й версии обновляться как-то нет желания. в чем проблемы? 6 версия была еще с меньшим числом косяков. В Summer9 тоже самое. Но вряд ли кто захочет туда откатиться. Главное отсутствие принципиальных ошибок, и известность warning. А вообще держите обеверсии. или вообще несколько.. Обычно я так и делаю. все в новом. А потом проверка и в изученном. и если нет разницы-- переход на втором третьем проекте на новый.
|
|
|
|
|
May 5 2015, 15:18
|

Эксперт
    
Группа: Модераторы
Сообщений: 1 385
Регистрация: 18-07-06
Из: Сан Диего
Пользователь №: 18 895

|
Цитата(Myron @ May 5 2015, 16:03)  Делают программу люди, которые не используют ее. У программистов нет понимания того, что есть косяк. Все разработчики в РФ делают изделия для космонавтики, военки и т.д. и никто из них эти изделия не использует. Отсюда, по вашему, следует вывод что у вас также нет понимания того что вы делаете. p.s. Предложил бы не заниматься офтопиком, или делать это в соответсвующем разделе. Баги и разные вопросы, связанные с 15.1. предложил бы обсудить в этой теме. Примерно через неделю будет патч к 15.1, все обнаруженные критичные ошибки в нем будут исправлены.
--------------------
|
|
|
|
|
May 6 2015, 06:39
|

люблю бегать и орать
    
Группа: Свой
Сообщений: 1 685
Регистрация: 28-04-07
Из: ЮБутово@Москва.ru
Пользователь №: 27 376

|
Цитата(Alexey Sabunin @ May 5 2015, 18:18)  Все разработчики в РФ делают изделия для космонавтики, военки и т.д. и никто из них эти изделия не использует. Отсюда, по вашему, следует вывод что у вас также нет понимания того что вы делаете. Неправда ваша. Такие изделия делаются по ТЗ заказчика, который понимает, что ему надо, а мы просто исполнители. Следуя вашей логике, мы должны (а мы можем) выдать ТЗ разработчику (вам) и он сделает как надо? Цитата(Alexey Sabunin @ May 5 2015, 18:18)  p.s. Предложил бы не заниматься офтопиком, или делать это в соответсвующем разделе. Баги и разные вопросы, связанные с 15.1. предложил бы обсудить в этой теме. Примерно через неделю будет патч к 15.1, все обнаруженные критичные ошибки в нем будут исправлены. Во. и главный вопрос: Что считать ошибкой и тем более критичной? Ваши программисты вряд ли проверяют работу программы на больших платах, по 100 раз на дню ее загружать, наблюдая за "Buiding DirectX Scene" занятие не для слабонервных. Но, справедливости ради, стоит заметить, что кое-какие проблески есть: Цитата 4901 Unnecessary & Time Wasting "Analyzing Nets" has been optimized on large designs. Наконец-то!!! "Large Design"!!! А "Analyzing Nets" реально задалбливает. А главная и критическая ошибка это нереальные тормоза альтиума! Исправлять намерены?
|
|
|
|
|
May 6 2015, 11:35
|
Участник

Группа: Участник
Сообщений: 74
Регистрация: 30-03-06
Пользователь №: 15 624

|
Таки еще глюк или у меня руки не из того места. Попробовал новый визард по созданию xSignal. Так вот для соединения точка - конденсатор - точка - создал, а для соединения точка - точка - резистор (память DDR) - обломался. Хотя ручками все создается на ура.
|
|
|
|
|
May 6 2015, 17:04
|

Эксперт
    
Группа: Модераторы
Сообщений: 1 385
Регистрация: 18-07-06
Из: Сан Диего
Пользователь №: 18 895

|
Цитата(peshkoff @ May 6 2015, 10:39)  Следуя вашей логике, мы должны (а мы можем) выдать ТЗ разработчику (вам) и он сделает как надо? Так и происходит. Заказчики, имеющие по 100 лицензий составляют ТЗ и оно отрабатывается. В целом такое ТЗ мы принимаем от всех пользователей, но приоритет отдается крупным пользователям. Остальные пожелания также рано или поздно уходят в работу. Мои контакты у вас есть - пишите, это не останется без внимания. Цитата(peshkoff @ May 6 2015, 10:39)  Ваши программисты вряд ли проверяют работу программы на больших платах, по 100 раз на дню ее загружать, наблюдая за "Buiding DirectX Scene" занятие не для слабонервных. Еще как проверяют. Многие проблемы известны, и они решаются. Но они не могут быть решены так быстро, как хотелось бы пользователям и разработчикам - есть ряд причин... Цитата(peshkoff @ May 6 2015, 10:39)  А главная и критическая ошибка это нереальные тормоза альтиума! Исправлять намерены? Многие из них мы решили еще год назад, но это потребовало больших изменений, и период тестирования может занять еще какого-то времени! Цитата(Myron @ May 6 2015, 15:53)  Вот именно, критичные. А "критичность" ошибок определяет сам разработчик. И очередь исправления ошибок в Алтиуме далеко не нулевая. Использую Алтиум/DXP 12 лет, ситема неплохая. Но баги, в основном тормоза, убивают все поз. эмоции. После каждого обновления с трепетом проверяю исправление известных мне багов - полностью исправлено или нет - и наличие новых "особенностей". А куда вы сообщаете об известных вам багах? Наверное если бы они были известны еще кому-то кроме вас, их бы уже и не было))) Давайте обсуждать эти вопросы более предметно. Вот вы можете например написать 10 изветсных вам багов, которые не были исправлены за последние 2 года?
--------------------
|
|
|
|
|
May 6 2015, 17:27
|
Профессионал
    
Группа: Свой
Сообщений: 1 849
Регистрация: 6-02-05
Пользователь №: 2 451

|
Цитата(Alexey Sabunin @ May 6 2015, 11:04)  А куда вы сообщаете об известных вам багах? Наверное если бы они были известны еще кому-то кроме вас, их бы уже и не было))) Давайте обсуждать эти вопросы более предметно. Вот вы можете например написать 10 изветсных вам багов, которые не были исправлены за последние 2 года? Мне хватило одного раза объясниться с людьми Альтиума по очень серьезному багу, на мой взгляд, по выбору компонетов для разных вариантов схемы, пока они приняли этот баг к работе. 2 раза мою заявку о баге снимали, пока по телефону не объяснил по шагам. Прошло больше 1,5 лет, они исправили в версии 14.8 (если не ошибаюсь), получилось неплохо. За исключением появившегося нового бага: после выбора компонентов для вариантов схемы и последующем пермещении компонентов (без изменения схемы, только для упрощения и читабельности) я применяю annotation снова для упорядочивания нумерации. При этом исходная информация по разным компонентам в вариантах перемешивается с неизменяемыми компонентами и приходится чистить это вручную. После моего первого "объяснения" с Алтиумом стараюсь избегать заявок об ошибках. Во всяком случае пока.
|
|
|
|
|
May 7 2015, 17:01
|
Частый гость
 
Группа: Свой
Сообщений: 81
Регистрация: 24-07-14
Из: NA
Пользователь №: 82 352

|
Цитата(dxp @ May 7 2015, 09:53)  Учитывая, что продукт написан на C# (информация была озвучена на семинаре, и я был очень этим удивлён), может статься, что эта "главная и критическая ошибка" окажется неисправимой в принципе. Уж что что, а на шарпе явно проще и надежнее можно писать приложения благодаря его гибкости, а вот выбранный язык для Альтия - довольно специфичен ибо он уже старичёк, более того создатель делфи - это и создатель шарпа. И сколько не использовал программ - все что на делфи написаны, порядком тяжелее и медлительнее (скайп, винамп и д.р.) по сравнению с аналогами на С++ \ С# (к примеру винамп \ аимп сравнить можно), но стоит признать - редактор ПП в нем сделан довольно удобно и вполне логично + самый приятный рендер плат в 3D - таки притягивают.
Сообщение отредактировал truppik - May 7 2015, 17:04
--------------------
never know best.
|
|
|
|
Guest_TSerg_*
|
May 8 2015, 05:11
|
Guests

|
Цитата(truppik @ May 7 2015, 20:01)  ...все что на делфи написаны, порядком тяжелее и медлительнее (скайп, винамп и д.р.) по сравнению с аналогами на С++ Это не так. Если говорить о вычислительном аспекте, то решают все алгоритмы и отсутствие криворукости. А интерфейс никогда не был причиной медлительности.
|
|
|
|
|
May 11 2015, 13:31
|
Частый гость
 
Группа: Свой
Сообщений: 81
Регистрация: 24-07-14
Из: NA
Пользователь №: 82 352

|
Цитата(TSerg @ May 8 2015, 08:11)  Это не так. Если говорить о вычислительном аспекте, то решают все алгоритмы и отсутствие криворукости. А интерфейс никогда не был причиной медлительности. Да, согласен - интерфейс это не причина медлительности. Но выбор языка таки влияет на общую картину построения программы и стилю (не в плане красивости кода, а в плане отношения к его корректности и общем отношении, аля говнокод или нет) её написания. Т.к. инструментов и материалов современных, примеров под перспективные вещи на делфи меньше чем на шарп (к примеру) - то и программы естемтвенно будут у среднестатического программиста выходить более кривыми, но конечно же можно всё вычищать и оптимизировать (да хоть на асемблере пиши...) - только вот времени на это уюма уйдет. А альтиевцы пошли простым и быстрым способом, только вот язык для ПО выбран не коректный для такого рода разработки - к примеру подают свежие версии альтия - вауя вот вам дорогие юзеры пару новых и красивых фич!юзайте! только вот с этим мало того, что ломают что то уже работающее в прошлой версии альтия, так и новое то баженное. и пользователь как отличный тестер выходит.. только вот, нафига платить столько (а просят то не мало) денег за такое ПО, которое регулярно в свет выходит с вагоном багов...
--------------------
never know best.
|
|
|
|
|
May 11 2015, 16:14
|
Участник

Группа: Участник
Сообщений: 74
Регистрация: 30-03-06
Пользователь №: 15 624

|
Цитата(truppik @ May 11 2015, 16:31)  ... к примеру подают свежие версии альтия - вауя вот вам дорогие юзеры пару новых и красивых фич!юзайте! только вот с этим мало того, что ломают что то уже работающее в прошлой версии альтия, так и новое то баженное. и пользователь как отличный тестер выходит.. только вот, нафига платить столько (а просят то не мало) денег за такое ПО, которое регулярно в свет выходит с вагоном багов... Плюсуюсь.
|
|
|
|
|
May 12 2015, 07:46
|

Adept
     
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343

|
По моим представлениям, основной язык для реализации функциональности серьёзного САПРа сегодня должен быть С++. С#, насколько мне известно, это интерпретируемый язык, что означает, что он по эффективности (в плане скорости, в частности) может конкурировать с Java и Python, но никак не с нативным кодом, получаемым из компилируемых языков С/С++ (и, кстати, Paskal/Delphi). Если на Шарпе там только GUI сделан, то это нормально, но если внутренние потроха, то перспектив в плане прироста быстродействия рассматривать не приходится.
Также полностью согласен с TSerg в том, что эффективность алгоритмов рулит, и если алгоритмы горбатые, то никакой ЯП уже ничего не исправит.
P.S.: IMHO: выбор C#, а не, скажем, С++ обусловлен тем, что идут по пути наименьшего сопротивления - высококвалифицированных программистов С++ найти гораздо труднее, чем на C#, т.к. и язык сложнее многократно, и порог вхождения выше. Шарп позволяет проще найти разработчиков, но в итоге он вводит определённый "потолок" для САПРа по размеру/сложности разрабатываемых проектов.
P.P.S.: Выбрав C#, Альтиум прибил себя гвоздями к венде. Недальновидное решение и стратегически проигрышное, учитывая, что венда чем дальше, тем тошнотворнее становится.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
May 12 2015, 13:06
|
Частый гость
 
Группа: Свой
Сообщений: 81
Регистрация: 24-07-14
Из: NA
Пользователь №: 82 352

|
Цитата(dxp @ May 12 2015, 10:46)  По моим представлениям, основной язык для реализации функциональности серьёзного САПРа сегодня должен быть С++. С#, насколько мне известно, это интерпретируемый язык, что означает, что он по эффективности (в плане скорости, в частности) может конкурировать с Java и Python, но никак не с нативным кодом, получаемым из компилируемых языков С/С++ (и, кстати, Paskal/Delphi). Если на Шарпе там только GUI сделан, то это нормально, но если внутренние потроха, то перспектив в плане прироста быстродействия рассматривать не приходится. Согласен, потребуется среда исполнения - аля .Net Скорость, да несколько ниже чем на с\с++, Но ИМХО не настолько критичная разница для прог пользовательского уровня. У нас же не система реального времени на микроконтроллере. Цитата(dxp @ May 12 2015, 10:46)  P.S.: IMHO: выбор C#, а не, скажем, С++ обусловлен тем, что идут по пути наименьшего сопротивления - высококвалифицированных программистов С++ найти гораздо труднее, чем на C#, т.к. и язык сложнее многократно, и порог вхождения выше. Шарп позволяет проще найти разработчиков, но в итоге он вводит определённый "потолок" для САПРа по размеру/сложности разрабатываемых проектов.
P.P.S.: Выбрав C#, Альтиум прибил себя гвоздями к венде. Недальновидное решение и стратегически проигрышное, учитывая, что венда чем дальше, тем тошнотворнее становится. Вот - Сами сказали, что профи найти для шарпа проще, Но альтий не на C# а на Delphi (которая так же привязана к Windows кстати) и квалифицированностью разработки, судя по новым версиям - тут и не пахнет. Можно только обьяснить дела с последними версиями тем, что альтиевцы гонятся за большим номером в версии и количестве фич в своем ПО и только, с полным пофигизмом какой ногой вечером это было сделано (не говоря уже о тестировании этих фич и их совместимости со старыми).
Сообщение отредактировал truppik - May 12 2015, 13:08
--------------------
never know best.
|
|
|
|
|
May 13 2015, 12:44
|

Adept
     
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343

|
QUOTE (V_G @ May 12 2015, 14:00)  Не профессиональный программист я, но C# не должен быть интерпретируемым. Компиляется в байт-код, который исполняется виртуальной машиной. QUOTE (V_G @ May 12 2015, 14:00)  (NET Framework 3.5 там уже стоял). Это оно. QUOTE (truppik @ May 12 2015, 19:06)  Согласен, потребуется среда исполнения - аля .Net Скорость, да несколько ниже чем на с\с++, Но ИМХО не настолько критичная разница для прог пользовательского уровня. У нас же не система реального времени на микроконтроллере. Как раз серьёзная САПР печатных плат - это ещё какой челлендж для разработки эффективно (быстро) работающего приложения - там же тысячи и десятки (а то и сотни) тысяч объектов (компоненты, цепи, проводники, ламели, отверстия, связи, пины, правила, румы и т.п.), online DRC и прочее - для комфортной работы это всё должно обрабатываться быстро - да, в идеале, в реальном времени. Представьте себе плату класса материнки, вопросы по необходимости эффективности не появятся. На семинаре А.Сабунин озвучил оценку самого Альтиума: если оценивать сложность (в т.ч. и размеры) по 10-балльной шкале, то AD - это где-то до 7 баллов, выше не его ниша (во всяком случае пока, но помня про Шарп, думается, что не пока - моё мнение). 8-10 баллов - это как раз то, до чего он (AD) не может дотянуться в первую очередь из-за производительности. И если функционал как-то подтягивают (работают люди, стараются), то по быстродействию прогресса нет. И не предвидится. Моя оценка. Во всяком случае, нужен пересмотр концепции - тяжёлые ресурсоёмкие вещи надо реализовывать: а) с упором на эффективность алгоритмов; б) на эффективном (пусть и относительно низкоуровневом) ЯП - например, С++. Всё медленное - GUI - делать на чём нравится - Шарп вполне годится. Если, конечно, не интересует кроссплатформенность.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|