Посмотрел что официально пишут в Линукс-man разных лет про resize, там по сути говорится что команда с таким синтаксисом официально есть, но так же есть и терминалы её не поддерживающие.
Команда resize, по меньшей мере в системах полностью поддерживающих синтаксис bash, поскольку это часть его синтаксиса, устанавливаем кастомный размер текущего окна терминала ВхШ в символах.
У меня Линукс Минт 20.04 с простым xcfe, графическим окружением и дефолтный терминал из xcfe, он такую команду понимает сразу.
1). В bash скрипте нужно установить кастомный размер терминального окна минимум 120 символов по горизонтали и 32 по вертикали. Иначе любой сценарий при типично дефолтном разрешении 80х24 вылетит со специфическом руганью питоновского интерпретатора, в которой вообще говоря не каждый плисовод разбирается.
2). На текущих версиях Cocotb, хоть установленных по инструкции из pip репозитория, хоть самой новой непосредственно с гитхаба крэшатся примеры номер 2 и номер 5.
Отличная статья! На мой взгляд подобную штуку, возможно не такую винтажную, но позволяющюю писать программы в машинных кодах, следует применять на лабораторках в ВУЗе, по всем специальностям, где требуется глубокое понимание программирования. Это даст и незаменимое понимание принципов построения и применения высокоуровневых языков, оптимизации программ и т.д.
Про "Не только в угоду переносимости, еще в угоду скорости разработки и простоты поддержки/расширения этого кода" благодарю за развитие мысли. Это тоже ультимативный "java-стайл". Другой вопрос, java-стайл, несмотря на ряд его достоинств далеко не универсален.
Строго по определению IDE — это интегрированная среда разработки, (integrated development environment). Она может быть минималистичной, а может включать в свой состав фремворки и прочие средства разработки ПО.
Не думаю, что я что-то путаю фраза звучит "Как vim удалось выжить, учитывая множество появившихся за эти годы современных IDE?". Что же касается "Cube-IDE", "Arduino-IDE", то эту устоявшуюся классификацию и терминологию, как вы понимаете не я сегодня изобрел. А вопрос мой "Cube-IDE" сводится к тому, что эта официальная вендорская IDE заточена лишь под "java-стайл". Иной стиль написания программ в ней не назовешь удобным и практичным.
Как vim удалось выжить, учитывая множество появившихся за эти годы современных IDE? На мой скромный взгляд, потому что он не навешивет на Ваш исходник кучу скрытых от разработчика непрозрачных прослоек, сильно тормозащих написанное ПО.
Тоесть концепт многих современных IDE, это популярно говоря ультимативный "java-стайл", когда независимо от Вашего желания в угоду преносимости кода фатально снижается его производительность. Отсюда и довольно типичный результат, когда для того же самого функционала системные требования ПО растут, с годами, в десятки раз.
Особенно чувствителен эффект "современных IDE" во встроенном ПО микроконтроллеров, причем если к Arduino-IDE, заточенной под первоначальное вхождение, претензий нет, то к STM-овской Cube-IDE, предназначенной вроде как не только начинающим, вопросы уже есть.
Как по мне, так и внутриросийский Яндекс теряет привлекательность, простейший пример - если вы соблюдаете элементарную цифровую гигиену, то уже на втором запросе в поисковике появляется "Ой с воздушным шариком", у конкурентов Яндекса этого нет. При желании примеры странноватой паранойи Яндекса, мягко говоря не добавляющей желания обращатся к Яндексу можно продолжить...
Насчет внутреннего нагрева, без термокожуха, это статпогрешность.
Когда нужно не "несколько раз", с непредсказуемым отказом сколько именно, а чтобы гарантировать "долго и надежно" применяют термостатируемые кожухи видеокамер, все уличное виденаблюдение примерно так и устроено, хотя в средней полосе минус 50 это экзотика да и таких экстремальных тепературных контрастов в уличном наблюдении тоже нет.
За бортом на высоте 10 км примерно минус 50 Цельсия, что заметно меньше, чем на что расчитана камера(а это в лучшем случае минус 35). На один раз полетать конечно хватит, но долго это врядли протянет, особенно учитывая выпадание конденсата внутри корпуса, поскольку конструкция камер, что на фото еще и не расчитана на резкие перепады температуры.
То что алгоритмически может быть выполнено узлом на микроконтороллере, с простейшей прошивкой, причем работающей с железом напрямую, и занимающей в исходнике 2-3 листа А4 12-тым кеглем, возлагается на Малинку, мало того что аппаратно куда более сложную, так еще с кучей слоев абстракции(разработанных отнюдь не под высоконадежные применения), которые создатель системы понятно особо не контролирует.
ДИП34А не плох, по сравнению с зиг-би, особенно по стойкости ЕМП, но я не просто про конкретное железо, я про я архитектуру. Малинка работающая по воздуху всеми способами, включая вай-фай, да еще подключенная к Интернету, это сплошная дыра в элементарных аспектах отказоустойчивости(все через одноплатник, при любом глюке которого система в лучшем случае зависнет, в худшем пойдет в разнос), совместимости(представьте подобные системы с каналами "по воздуху" в каждой квартире типичного человейника в мегаполисе), про информационную безопасность такого по сути конструктора более подходящего для первоначального обучения школьников, вообще речь не идет. Причем все на уровне концепции такой системы.
Единственное что меня сдерживает от приобретения такого устройства это морально устаревшее разрешение экрана 720p(хотя физический размер экрана вполне себе 10.1"), делающее крайне некомфортным работу с многочисленным современным софтом. Замечу что именно работа на полноценном десктопном Линуксе(в силу специфики Линукса под ARM руками скомпилировать и собрать в пакет можно практический любой нужный софт). Но 720p и современные GUI-интерфейсы это боль.
Посмотрел что официально пишут в Линукс-man разных лет про resize, там по сути говорится что команда с таким синтаксисом официально есть, но так же есть и терминалы её не поддерживающие.
https://stackdiary.com/linux-docs/resize/
https://linux.die.net/man/1/resize
Команда resize, по меньшей мере в системах полностью поддерживающих синтаксис bash, поскольку это часть его синтаксиса, устанавливаем кастомный размер текущего окна терминала ВхШ в символах.
У меня Линукс Минт 20.04 с простым xcfe, графическим окружением и дефолтный терминал из xcfe, он такую команду понимает сразу.
У меня iverilog 10.3
Опечатка, лишний символ
#!/usr/bin/env bash
В первой строке
Крэш 2 и 5 сценариев от размера окна совсем не зависит и ругается на другое:
vvp: vthread.cc:3405: bool of_LOAD_DAR_VEC4(vthread_t, vvp_code_t): Проверочное утверждение «darray» не выполнено.
make[1]: *** [/usr/local/lib/python3.8/dist-packages/cocotb/share/makefiles/simulators/Makefile.icarus:95: results.xml] Аварийный останов (сделан дамп памяти)
make[1]: выход из каталога «/home/aax/tmp/hdlgadgets-main»
make: *** [/usr/local/lib/python3.8/dist-packages/cocotb/share/makefiles/Makefile.inc:40: sim] Ошибка 2
По поводу пункта 1, начало start. bash
#!/usr/bin/env bashr
resize -s 32 120
clear
1). В bash скрипте нужно установить кастомный размер терминального окна минимум 120 символов по горизонтали и 32 по вертикали. Иначе любой сценарий при типично дефолтном разрешении 80х24 вылетит со специфическом руганью питоновского интерпретатора, в которой вообще говоря не каждый плисовод разбирается.
2). На текущих версиях Cocotb, хоть установленных по инструкции из pip репозитория, хоть самой новой непосредственно с гитхаба крэшатся примеры номер 2 и номер 5.
Проверял на Минт 20.04 с Python 3.8
Отличная статья! На мой взгляд подобную штуку, возможно не такую винтажную, но позволяющюю писать программы в машинных кодах, следует применять на лабораторках в ВУЗе, по всем специальностям, где требуется глубокое понимание программирования. Это даст и незаменимое понимание принципов построения и применения высокоуровневых языков, оптимизации программ и т.д.
У Яндекса это и без vpn. У меня по умолчанию DuckDuckGo. Для российского почтового адреса предпочитаю Рамблер, внешнего Proton.
Про "Не только в угоду переносимости, еще в угоду скорости разработки и простоты поддержки/расширения этого кода" благодарю за развитие мысли. Это тоже ультимативный "java-стайл". Другой вопрос, java-стайл, несмотря на ряд его достоинств далеко не универсален.
Строго по определению IDE — это интегрированная среда разработки, (integrated development environment). Она может быть минималистичной, а может включать в свой состав фремворки и прочие средства разработки ПО.
Не думаю, что я что-то путаю фраза звучит "Как vim удалось выжить, учитывая множество появившихся за эти годы современных IDE?". Что же касается "Cube-IDE", "Arduino-IDE", то эту устоявшуюся классификацию и терминологию, как вы понимаете не я сегодня изобрел. А вопрос мой "Cube-IDE" сводится к тому, что эта официальная вендорская IDE заточена лишь под "java-стайл". Иной стиль написания программ в ней не назовешь удобным и практичным.
Как vim удалось выжить, учитывая множество появившихся за эти годы современных IDE? На мой скромный взгляд, потому что он не навешивет на Ваш исходник кучу скрытых от разработчика непрозрачных прослоек, сильно тормозащих написанное ПО.
Тоесть концепт многих современных IDE, это популярно говоря ультимативный "java-стайл", когда независимо от Вашего желания в угоду преносимости кода фатально снижается его производительность. Отсюда и довольно типичный результат, когда для того же самого функционала системные требования ПО растут, с годами, в десятки раз.
Особенно чувствителен эффект "современных IDE" во встроенном ПО микроконтроллеров, причем если к Arduino-IDE, заточенной под первоначальное вхождение, претензий нет, то к STM-овской Cube-IDE, предназначенной вроде как не только начинающим, вопросы уже есть.
Как по мне, так и внутриросийский Яндекс теряет привлекательность, простейший пример - если вы соблюдаете элементарную цифровую гигиену, то уже на втором запросе в поисковике появляется "Ой с воздушным шариком", у конкурентов Яндекса этого нет. При желании примеры странноватой паранойи Яндекса, мягко говоря не добавляющей желания обращатся к Яндексу можно продолжить...
Насчет внутреннего нагрева, без термокожуха, это статпогрешность.
Когда нужно не "несколько раз", с непредсказуемым отказом сколько именно, а чтобы гарантировать "долго и надежно" применяют термостатируемые кожухи видеокамер, все уличное виденаблюдение примерно так и устроено, хотя в средней полосе минус 50 это экзотика да и таких экстремальных тепературных контрастов в уличном наблюдении тоже нет.
За бортом на высоте 10 км примерно минус 50 Цельсия, что заметно меньше, чем на что расчитана камера(а это в лучшем случае минус 35). На один раз полетать конечно хватит, но долго это врядли протянет, особенно учитывая выпадание конденсата внутри корпуса, поскольку конструкция камер, что на фото еще и не расчитана на резкие перепады температуры.
А что с термостатированием? Какая температура при полете была в основном боксе, и что с видеокамерами?
То что алгоритмически может быть выполнено узлом на микроконтороллере, с простейшей прошивкой, причем работающей с железом напрямую, и занимающей в исходнике 2-3 листа А4 12-тым кеглем, возлагается на Малинку, мало того что аппаратно куда более сложную, так еще с кучей слоев абстракции(разработанных отнюдь не под высоконадежные применения), которые создатель системы понятно особо не контролирует.
ДИП34А не плох, по сравнению с зиг-би, особенно по стойкости ЕМП, но я не просто про конкретное железо, я про я архитектуру. Малинка работающая по воздуху всеми способами, включая вай-фай, да еще подключенная к Интернету, это сплошная дыра в элементарных аспектах отказоустойчивости(все через одноплатник, при любом глюке которого система в лучшем случае зависнет, в худшем пойдет в разнос), совместимости(представьте подобные системы с каналами "по воздуху" в каждой квартире типичного человейника в мегаполисе), про информационную безопасность такого по сути конструктора более подходящего для первоначального обучения школьников, вообще речь не идет. Причем все на уровне концепции такой системы.
Единственное что меня сдерживает от приобретения такого устройства это морально устаревшее разрешение экрана 720p(хотя физический размер экрана вполне себе 10.1"), делающее крайне некомфортным работу с многочисленным современным софтом. Замечу что именно работа на полноценном десктопном Линуксе(в силу специфики Линукса под ARM руками скомпилировать и собрать в пакет можно практический любой нужный софт). Но 720p и современные GUI-интерфейсы это боль.