Jump to content

    

dxp

Свой
  • Content Count

    3862
  • Joined

  • Last visited

Community Reputation

0 Обычный

3 Followers

About dxp

  • Rank
    Adept

Информация

  • Город
    Array

Recent Profile Visitors

8983 profile views
  1. Ну, эти - да, уже программы, первая - веб приложение, вторая - нативное. Спайдер изрядно похож на оболочку матлаба. А ноутбук удобен для публикаций - например, тот же гитхаб умеет "рендерить" файлы .ipynb, в которые сохраняются сессии ноутбука. Достаточно перейти по ссылке на файл, и браузер покажет пересчитанную страницу. Преимуществом ноутбучного подхода по сравнению с чисто программой является то, что в ноутбуке можно делать гибридные документы - он состоит из секций разных типов: текстовые (язык разметки), графические (картинки, видео), вычислительные (питон код в полном объёме с графиками и диаграммами сразу). Таким образом, можно прямо хоть научные отчёты оформлять, при этом они "живые" - редактируешь секцию, она тут же пересчитывается. Вот тут пример, целый урок по питону оформлен в виде Jupyter Notebook страницы.
  2. Ну, питон - не расчётная программа, а ЯП. По идеологии очень похож на скриптовый язык матлаба, но будучи ЯП общего назначения как язык значительно мощнее и гибче. Матлаб исходно проектировался для математических расчётов - в особенности, для матричных вычислений (отсюда и название), питон сам по себе в этом вопросе вообще никакой, но к нему подтягивается пакет numpy, который внутри реализован на тех же пакетах BLAS, LAPACK, что и матричная математика матлаба, поэтому в этом вопросе тут где-то паритет. Питон силён библиотеками. Это вообще язык-фронтэнд: вся эффективность достигается путём грамотного управления ресурсами (встроенными средствами типа слайсов, enumerate и библиотеками) Несмотря на бесплатность, в питоновые средства серьёзно вкладываются солидные заведения вроде университетов. И существует тенденция уже не одного года, когда специалисты, много лет сидевшие на матлабе, переходят на питон + numpy + matplotlib и прочее. И это вопрос не только финансов, но и бОльших возможностей как самого ЯП, так и библиотек под него. Сильная сторона матлаба - обилие специализированных библиотек (тулбоксов) и налачие инструментов Simulink и HDL Coder. Но двое последних не имеют отношения к собственно языку, это скорее надстройки. В питоне таких инструментов нет.
  3. Так IPython - не это дополнение. Какая разница, написать в командной строке 'python' или 'ipython'? Запуститься консоль. Дальше вся работа одинакова - пишем команды, смотрим вывод программы. Там ничего изучать и осваивать не надо. А даже внешний вид уже куда приятнее.
  4. Но для интерактивной работы ведь нужна консоль. Штатная питоновая уж "слишком проста". IPython - та же консоль, но с наличием множества очень удобных плюшек, начиная от продвинутой системы word completion вкупе с историей команд (например, достаточно ввести пару букв команды и далее стрелка вверх перебирает из истории только те команды, которые начинались с этих букв) и заканчивая возможностью писать и редактировать целые блоки кода вплоть до функций (можно написать, отладить функции, а потом перенести её в исходник). Нумерованный ввод-вывод. Подсветка синтаксиса. Попробуйте - после этого желание пользоваться штатной консолью питона пропадёт.
  5. Не Jupyter, Notebook, а Jupyter Notebook. А вы пробовали IPython? И если отметаете это, то чем пользуетесь в качестве консоли?
  6. "да" означало в данном случае, что путь правильный - ставить анаконду. Потому что через pip там как-то криво ставилось. Правда, было это года два или три назад, может починили с тех пор, но сомнительно, а анаконда без вопросов вставала и всё работало замечательно. По сути это просто всё то же самое, собранное в одном пакете. Что избыточно? IPython?
  7. Так чтобы по отдельности не таскать эти либы, имеет смысл сразу накатить jupyter - он всё это тянет автоматом. При этом ещё предлагает прекрасную IPython консоль, в т.ч. и в QtConsole варианте, а также web приложение jupyter notebook. В линухах ставится всё pip install jupyter. Под вендами - да, путь - анаконда.
  8. Да. И это только защищает FIFO от over/underflow, чтобы логика этого устройства не поломалась, когда, например, происходит запись при установленном full, но не защищает от пропуска данных. Для корректной работы всего тракта надо обязательно пользовательскую логику увязывать с full. А вообще, SVA тут рулят со страшной силой.
  9. Если нужен счётный семафор, то лучше сразу сделать свой - там для этого есть штатный путь: отнаследоваться от TService и написать свою логику, подсматривая, как сделаны другие сервисы межпроцессного взаимодействия. Имхо, это будет прямой путь: проще и без костылей. За основу возможно подойдёт тот же TMutex, только вместо простого флага там счётчик завести.
  10. Насколько я понял, автор цитируемой фразы ("Для классов с инитом конструкторов - тольлько new/delete. Без вариантов!") имел в виду, судя по тексту самой фразы, что если у класса есть конструктор, то обязательно будет выделение памяти (вызов new). Что совершенно неверно и выдаёт непонимание на уровне азов.
  11. Такой безобразный синтаксис кастов введён специально, чтобы это выделялось на общем фоне, и программисту было напоминание лишний раз подумать, надо ли делать ручное преобразование типа или эта необходимость возникла из-за ошибки проектирования. И это видные места, где может быть проблема.. Прежний (сишный) синтаксис в этом плане плох - он не выделяется из кода. К тому же он усугубляет и без того злоупотребление скобками, чем и так грешат C/C++. Ну, и в С++ static_cast и reinterpret_cast - это разные уровни кастования - например, static_cast не позволит целое преобразовать к указателю, т.е. как бы разные уровни severity, а сишный вариант не различает их - объединяет оба.
  12. Т.е. получается, что: "для производства вполне достаточно : сборка-гербер-перечень элементов (спецификация)...а-и-всё" таки недостаточно для производства, а помимо сборочных чертежей, герберов и перечня/спецификации ещё нужно разработать и предоставить производству тестовые стенды, инструкции по настройке и проверке и прочую технологическую шнягу. Которая-таки тоже разрабатывается и нередко сложность и стоимость разработки тестовых стендов и ПО для них превышает по сложности и трудоёмкости само изделие.
  13. А проверку (прогон тестов) плат после выхода с монтажной линии на контрактном производстве, а также тестирование конечных изделий (тоже прогон всех необходимых тестов) - это тоже КП делает или вы сами?
  14. Таймер делать не стали, просто анализируем тракт передачи - как только он пустеет, генерируется прерывание. Так получается и проще, и даже быстрее реакция
  15. Рабочая схема. Пробовали её, но в итоге нам удобнее оказалось генерировать прерывания по порогу заполнения выходной очереди: драйвер задаёт порог через регистр в дивайсе, и тот мечет прерывания на каждые эн пакетов. Очень эффективный способ получился, особенно на коротких пакетах (т.е. когда их очень много).