Aldan

Спасибо. Загрузку с временной ссылки удалил. Теперь качать с фтп.

В связи с выходом новой стабильной версии KiCad переделал библиотеку 3-х летней давности. Схемотехническая библиотека мало изменилась: в ней были произведены некоторые уточнения. Библиотека посадочных мест претерпела большие изменения: она была почищена и расширилась на 900 посадочных мест вместе с 3D-модулями; прежде единый файл посадочных мест был разбит на 14 библиотек и все посадочные места были сконвертированы в .kicad_mod. Архив KiCadLibMod_27.01.2016.7z временно можно скачать по ссылке: https://yadi.sk/d/21d_61gpnnoqM Прошу, как всегда закинуть библиотеку на фтп ftp://ftp.kicad.ru/pub/kicad/ ( ftp://kicad.r4b.ru/pub/kicad/ ), причем старую библиотеку переместить в папку old. ---------- P.S. Вот бы еще и документацией на русском к новому KiCad разжиться, а то в нем даже папки “ru” нет...

Да, я уже наткнулся на то, что тестовая ветка не грузится и ее теперь переименовали в "продакт". Дело не в этом, а в том, что завершился отказ от стабильных релизов в принципе. Чтобы не повторять свои прошлые размышления на этот счет приведу слова пользователя с Кикад-форума http://groups.yahoo.com/neo/groups/kicad-u.../messages/16828 под которыми и я подписываюсь: I think users aren't asking for a "stable branch" which will be maintained separately from the mainline development trunk. They're just asking, "What revision should we install, and with that revision, what are the known bugs?" That's actually much simpler. The regular user just wants to design a circuit board, so if the developers could stop for a moment and just say, "Revision 4133 has these features, these issues, but is generally ready for production use," most folks would be happy. Then at some later date, the developers could then announce, "We've been busy, and we're now able to announce that Revision 4444 is stable enough for general use, please grab it." I'm not asking for the developers to maintain Revision 4133 as a separate branch to which patches are applied. If something horrible is found in 4133, the user should install the next "stable" version 4444 and get on with doing work. Am I asking too much?

Когда я писал свое прошлое сообщение, меня сильно беспокоило какое-то смутное чувство неуверенности. Ведь в последнее время команда Жан Пьера все больше и больше отходит от признанных канонов выпуска программного продукта для обычных пользователей, да и от своих устоявшихся правил тоже. Почему бы и в этот раз, думалось мне, Жан Пьеру не пойти еще дальше в своих организационных «новациях»? И, похоже, что интуиция меня не обманула. Возможно, что последние запоздавшие обновления «старой» стабильной сборки являются ничем иным, как «лебединой песней» в выпуске стабильных версий Кикад и больше ничего стабильного в «кикадостроении» уже не будет. По крайней мере такие мысли приходят на ум тогда, когда читаешь ответы на вопрос «When will there be a new stable release?» с Кикад-форума: http://groups.yahoo.com/neo/groups/kicad-u...ns/topics/16814 Если суммировать смысл ответов, то получается, что больше уже никогда не будет стабильных сборок Кикада. При этом, на вопрос о том, что для виндов необходимо выпускать готовые сборки, был ответ, что кто-нибудь может быть их будет собирать, а если нет, то тогда вин-Кикад будет доступен только для малой группы экспертов, делающих сборки для себя. В связи с открывшимися обстоятельствами у меня серьезная просьба к тем, кто работает в виндовом Кикаде и в данный момент (в отличие от меня) находится в активной фазе кикад-проектирования, на время подменить папочку “bin” своей текущей версии на такую же папочку из сборки kicad_stable_4027 от viknn для того, чтобы постараться обнаружить возможные упущения при сборке (патч Барановского уже на месте, но может быть опять проблемы с дугами при выводе в dxf или еще что-то из уже пофиксенного, но не вошедшего в данную сборку). Если обнаружатся недочеты, то сделать еще одну, самую финишную сборку с учетом всех замечаний, после чего торжественно поместить ее на фтп в раздел «релиз» на веки вечные, дабы иметь сборку, которой можно доверять. И, если и дальше развитие Кикад будет продолжаться в том же направлении, можно обычным пользователям присмотреться к DesignSpark, который весьма быстро прогрессирует.

Если за выход новой версии считать выход финального вылизанного релиза, то да, это скорее всего произойдет где-то к лету как в прошлый раз. Однако, я писал о начале новой серии стабильных сборок, которая в прежние времена начиналась в январе, а в прошлый раз была в феврале: Надеюсь, что новая серия стабильных сборок вскоре стартует. Патч присутствует во всех последних стабильных сборках, но иногда забывается при сборке: Так что поищите у себя, он у вас имеется. Можно и напрямую обратиться к Константину Барановскому и он предоставит самую свежую версию. А вообще-то все очень грустно, т.к. ГОСТ-ветка Кикада умирает.., вот и патчи теряются... Не поймите как упрек, просто раньше, когда тестовые сборки выходили почти каждый день, ничего подобного не могло бы произойти.

viknn, спасибо, что не забываете делать сборки, а то в последние месяцы все ГОСТ-ветки встали. Правда, данное обновление весьма странное, т.к. на дворе уже 2014 год, а Жан Пьер снова начал долизывать старую стаб. версию вместо того, чтобы выпустить новую. Кстати, сборка опять получилась без патча Константина Барановского, о чем можно сделать вывод глядя на оформление основных записей форматки.

faa, раньше обновление перевода сопровождалось записью в http://bazaar.launchpad.net/~kicad-testing...testing/changes однако в этот раз там не было Вашего сообщения. Значит ли это, что все же теперь апгрейд перевода недоступен для сборщиков основной ветки? Иными словами, основная ветка Кикад Вами больше не поддерживается?

Поясню возникшую озабоченность: если раньше работа мешала появлению обновлений равномерно как для основной ветки так и для "форкнутой", то теперь баланс был нарушен в пользу форка. В таких случаях обычно говорят, что "мать в первую очередь покормить свое дитя". Я очень рад, что предчувствия меня обманули. Я подозревал, что это не совсем уместный метод актуализации перевода. Теперь выкину такую самодеятельность из головы. Хорошо бы, если такой досуг образовался у Вас поскорее, т.к. хотелось бы понять основные веяния, где мы и куда движемся. Ну вот и повод выложить свежую тестовую сборку основной ветки.

faa, я подождал пару недель с момента обновления Вами переводов на lp:kicad-gost-committers в надежде на то, что такое же обновление появится и на lp:kicad-testing-committers/kicad/testing, но так и не дождался этого. Желая довести до актуального состояния перевод и для «штатной» тестовой сборки, я скачал kicad_gost_commiters_product_bzr4213 и вытащил из нее файлы kicad.mo и kicad.po, которые и вставил в тестируемую мною kicad_gost_testing_bzr4310. В этой связи у меня появилось к Вам несколько вопросов на которые очень прошу Вас ответить. 1. Есть ли какая-то засада в использовании kicad.mo и kicad.po из неродной, но более свежей сборки? (На первый взгляд вроде все нормально и отсутствующие переводы появились.) 2. Надо ли понимать Ваше пренебрежение к ветке lp:kicad-testing-committers/kicad/testing как то, что Вы полностью отказались от обновлений в ней и окончательно ушли в lp:kicad-gost-committers и теперь обновлять переводы в lp:kicad-testing-committers/kicad/testing можно будет только «методом выковыривания»? 3. faa, Вы стояли у истоков ГОСТ-ветки Кикада и Ваш авторитет непререкаем, а Ваши действия и выбор имеют огромное влияние на события, связанные с развитием Кикад. Так может быть Вы поделитесь своим видением путей развития этой САПР в свете окончательной «форкнутости» чтобы уж поставить все точки над I.

Константин, о том, что я пользуюсь Вашей программой Вы и так знаете из нашей переписки. Насчет того, надо ли здесь сообщать о новых версиях ответ один — надо. Ваша программа единственная в своем роде т. к. только она позволяет выводить текстовую документацию пользователям стабильных сборок т. е. основной армии пользователей. Но эта «армия» пока немногочисленна и почти не захаживает на форумы вроде нашего, так что не ожидайте большого количества ответов на Ваш вопрос об использовании. К тому же даже наш форум на данном отрезке времени почти мертв и отвечать Вам просто некому. Я не обнаружил файлы рамок, о которых Вы говорите, ни в тестовой ГОСТ-сборке kicad_gost_testing_bzr4310, ни в буржуйской kicad-20130823-r4296-windows с сайта http://kicad.tuturutu.cz/ так что обратите на это внимание. Похоже, что им пока не дан ход. К этому сообщению прикрепляю файлы gost_landscape.kicad_wks и gost_portrait.kicad_wks которые Вы мне выслали в виде архива "For PL Editor", дабы те, кому интересно потестить PL Editor могли это сделать. Надеюсь, Вы не против. For_PL_Editor.zip

Спасибо за пояснения. Моя неудача с русскими надписями, как и ожидалось, была по причине поверхностного знакомства с сапром. Однако, Ваше деликатное молчание по остальным моим вопросам утвердило меня в том, что у DesignSparkPCB с ГОСТ-ом глухо.

Уважаемые пользователи DesignSparkPCB, а как у вас получается подружиться с ГОСТ-ом (надписи на русском, форматки, вывод текстовой документации по ГОСТ)? Я пробовал ставить сей продукт, но у меня не получилось даже сделать на схеме надпись на русском, т.к. получил "кракозябры". Про форматки и вывод перечня по ГОСТ я вовсе молчу. Русификация графического интерфейса тоже бы не помешала. Так может быть не все так мрачно и все эти вопросы уже как-то решены? Развейте мои сомнения...

Приветствую! Хочется верить, что это надолго. Было бы хорошо, если и "классические" сборки тоже были не забыты под натиском gost-committers

http://electronix.ru/forum/index.php?showt...t&p=1189321

viknn, благодарю за сборки. Чувствую, что используя стабильную сборку, безнадежно отстал от прогресса. Поясните, пожалуйста, что это за работа с глобальными библиотеками для pcbnew и есть ли в этом какие-то грабли. Чую не спроста Вы выложили две сборки сразу, какой из них советуете воспользоваться?

Viknn, за все лето в разделе «testing» ftp://ftp.kicad.ru/pub/kicad/install/win32/testing/ не появилось ни одной новой тестовой сборки, а раздел «bzr» ftp://ftp.kicad.ru/pub/kicad/bzr/win32/ не обновлялся с марта. Если можно, выложите свежую тестовую виндовую сборку для того, чтобы можно было обстоятельно протестировать свежую версию kicadbom2spec Константина Барановского http://electronix.ru/forum/index.php?showt...t&p=1189177 Данная версия этого продукта прекрасно работает на стабильной сборке, в чем я уже убедился, но, как Вы знаете, тестовые сборки полны новшеств, наличие которых и позволят провести тестирование в полной мере. Кроме того, я задумал переделать свою библиотеку посадочных мест, разбив ее на подбиблиотеки т. к. в новых сборках в cvpcb теперь возможно работать с ними и это тоже требует наличия свежей сборки. «Форкнутую» сборку, которая постоянно обновляется, использовать не могу, т. к. она не вполне соответствует «классической», да и переходить на форк не планирую. Словом, хотелось бы, чтобы хоть раз в месяц или, на худой конец, в квартал появлялась «классическая» тестовая сборка для виндов т. к. хочется иметь выход к новинкам в Кикад.

Кхе, кхе.. (мнется переступая с ноги на ногу), viknn, Жан Пьер разродился очередной стабильной версией - 4023 с большим количеством исправлений, хорошо бы собрать ее и горяченькую на наш фтп :)

Viknn, на фтп Жан Пьера в это же самое время появилась стабильная сборка KiCad_stable-2013.07.07-BZR4022. Хорошо бы и на нашем фтп сделать соответствующее обновление. Похоже, что Жан Пьер совсем отказался от финальных релизов и гонит непрерывную серию стабильных сборок, которая закончится только тогда, когда из тестовой ветки стартует новая стабильная серия.

Нечто схожее, но от команды Qucs - "QucsStudio": http://www.mydarc.de/DD6UM/QucsStudio/about.html

Я пробовал редактировать сгенеренный скриптом файл *.ods и нашел, что это не такое уж утомительное занятие. Однако, с редактором полей элементов все будет гораздо шоколаднее :) Как я уже написал, игры с диапазоном печати ни к чему не привели. Тогда я взял в руки бубен и решил все переустановить еще раз, а то ведь то питон правил, а потом отдельно odfpy. Распечатке первых листов это не помогло, а вот проект с названием из трех букв стал конвертироваться без проблем. Все же одной проблемой меньше :) Что касается пропадения нескольких горизонтальных разделительных линий, то это оказался глюк ЛибреОфиса при предварительном просмотре перед печатью. Сама печать проходит без этих артефактов. Я специально зарегистрировался на https://launchpad.net и зашел к Вам на https://launchpad.net/kicadbom2spec где нашел Ваш адрес электронной почты. Выслал на него часть проекта полуторагодовалой давности. Предлагаю дальнейшее общение продолжить по переписке. Считайте, что я обратился к Вам не через форум, а прямо на launchpad. Так будет гораздо удобнее.

Спасибо, понятно. Конечно. Я лишь выразил недоумение в том, что в стабильной сборке зачем-то имеется нестабильный (не доведенный до ума в тестовых сборках) компонент, к тому же к нему нет доступа из Кикад. Так что pcad2kicadsch идет просто как «довесок» никакого отношения к стабильной сборке не имеющий. По серости своей не знаю о NSIS-исталляторе, но был бы очень рад, если Константин прислушается к Вашему предложению. Я тоже писал не как наезд, а просто обратил внимание на странности. Я достаточно регулярно пишу о таких вещах, если что-то обнаружу, однако Вы только в этот раз решили среагировать. Это потому что мое замечание касалось продукта AVL? Понимаю Ваш юмор, но не разделяю и вот почему. Примерно с год назад у меня на работе случилась такая ситуация: мне, работающему в Кикад, предложили быстренько завершить схему другого разработчика, работающего в PCAD и развести плату. Я кинулся в интернет и нашел pcad2kicadsch. Запустил, получил тот же результат, что и Вы и понял, что мне этот продукт не интересен. Видимо, по этой же причине Жан Пьер с админами пока не хотят включать его в сборку. Вот по этой-то причине я его всегда и удаляю. Наверно после такой «удачной» шутки я должен был рассмеяться, но еще раз замечу, pcad2kicadsch к стабильной сборке никакого отношения не имеет и с ней даже не интегрирован. Так что такое удаление никак не затрагивает работоспособность Кикад. Я тихо, без «подколов» и эмоцей спросил у viknn и он мне столь же сухо, по-деловому ответил. Никто бы не стал выделять из общего потока мое сообщение, но тут появляетесь Вы, и заставляете меня объясняться и оправдываться, привлекая всеобщее внимание. Так кто из нас вносит смуту, я или Вы :)

Константин, очень рад, что Вы снова сможете продолжить свою работу! Игры с диапазоном печати ни к чему не приводят и я думаю, что все дело скорее всего в «кривой» установке odfpy. Напомню, что я сначала по незнанию поставил питон3, а потом собрал odfpy. Далее, понял, что нужен питон2 и установил его, но скрипт не запускался. Далее, мне пришла мысль, что, возможно, odfpy собранная при питоне3 как-то влияет на запуск. Пересобрал odfpy и все стало запускаться. Так вот, сейчас меня меня гложет мысль, что именно odfpy все портит, т. к. МсОфис проблем с выводом листов не имеет. Константин, более подробный ответ с результатами экспериментов смогу предоставить только вечером, скорее ближе к ночи, а сейчас нет никакой возможности. Было бы здорово, если бы Вы написали мне, как можно «почистить» odfpy и все постараться установить с чистого листа. Тогда все последующие эксперименты могут и не понадобиться.

Константин, у меня такой вопрос: при переходе только на файл схемы общие принципы взаимодействия с компонентами библиотек останутся прежними? Спрашиваю потому, что собираюсь сделать некоторое оформление полей компонентов и не хотелось бы, чтобы эта работа была напрасной по причине кардинальных изменений в работе Вашего скрипта. Если не секрет, когда рассчитываете стать посвободнее и написать новый скрипт? И еще, если у Вас появится время, помогите побороть странную особенность в работе скрипта: сгенерированные файлы .ods просматриваемые в ВинОфисе имеют нормальный вид за исключением некоторых погрешностей с форматированием, а вот если эти файлы просматривать, как положено, в ЛибреОфисе, то все совсем не так красиво. Наблюдается такая закономерность (проверял на 4-х проектах): если перечень получается больше, чем на одном листе, то первый лист не виден на предварительном просмотре и, следовательно, не печатается; если же перечень помещается на один лист, то тогда этот лист становится виден, но с артефактами: у некоторых групп строк по три строчки пропадают горизонтальные разделительные линии. Не думаю, что эти артефакты будут обязательно проявляться и в других коротких перечнях, а вот невозможность распечатать первый лист в длинных перечнях — стойкая закономерность. Хочу отметить, что скрипт испытывался на проектах годовой давности. Не может ли это как то повлиять на такой странный результат? Может быть Вы глянете длинный перечень и, если все будет нормально, то перечень из старого проекта? Хотелось бы со всем этим разобраться, т. к. со остальным вопросов вроде бы больше нет. И еще, когда я генерил перечни из разных проектов, то попался мне один из них с именем «SOR”. Так вот, после всех стандартных действий перечень так и не появлялся. Мне пришла мысль, что, возможно, имя слишком короткое и, после того, как я добавил к нему еще пару букв - все пошло. Лучше убрать такое ограничение на длину названия файла если это не вредит скрипту или указать это ограничение в доке.

viknn, все время забываю Вас спросить, а зачем в стабильную сборку добавляют тестовую pcad2kicadsch.exe, которая к тому же крашится: Удалить его конечно же не сложно, но может быть лучше его добавлять только в тестовые сборки, а стабильные оставить в покое? В Вашем файле «kicad_news_2013.pdf» есть 12-й пункт: «Реализована поддержка Python-программирования для KiCAD (создание внешних и внутренних скриптов для pcbnew и доступ к объектам pcb-модели платы, поддержка swig-интерфейса для стыковки с++/python)» Не могли бы Вы рассказать подробнее и более доходчиво в чем заключается « поддержка Python-программирования для KiCAD»? Вопрос вызван тем, что для работы скрипта Константина Барановского требуется Python и его приходится устанавливать отдельно. Можно ли ожидать, что Кикад при каких-то условиях таки позволит запускать скрипты без отдельной установки Питона?

faa, мне хотелось бы с Вашей помощью понять есть ли пути развития Кикад-ГОСТ кроме как ухода в форк, а также хочется понять какова свобода для определения содержания ГОСТ-сброк, т. е. что можно, а что нельзя в них «вливать»? Вот, например, Вы пишете: Т.е. в данном случае Вы воспользовались тем, что свойства ГОСТ-сборки проявляются только в том случае, если пользоваться именно ею. Пользователи других сборок данное нововведение не будут иметь. Такая самостоятельность именно ГОСТ-подраздела сборки, наверно, не сильно контролируется Жан Пьером и полностью отдана Вам под Вашу ответственность. Получается, что ГОСТ-сборка, хоть и не форк, а все же позволяет «вливать» необходимые для нас новшества и при этом она нисколько не теряет связь с основной веткой Кикад. При таком раскладе ГОСТ-сборка является неким «контейнером» на основной ветке, позволяющим аккумулировать в себе нечто сверх того, что дает основная ветка. Если это так, то зачем «форкаться»? Чем плох вариант развития, который был до последнего момента? И вытекающий из этого вопрос: будут ли и дальше выпускаться стабильные ГОСТ-сборки или теперь будет только kicad_gost_commiters?