Это ж, блин, уникальная возможность получить по-разному работающий (или вообще неработающий) код, различающийся исключительно количеством пробелов. Ну гениально же!
Уголок программиста (1 онлайн
- Автор темы PianoIst
- Дата начала
неистово плюсуюЭто ж, блин, уникальная возможность получить по-разному работающий (или вообще неработающий) код, различающийся исключительно количеством пробелов. Ну гениально же!
особено если продукт вылазит за пару десятокв килолок хотяб - этот вот все непотребство - адовый ад
Я только пытаюсь предположить, зачем так придумано. Сам я тоже привык к синтаксису, подобному C, C++, java, C#.
Да я понимаю, у меня вообще ни к кому никаких претензий нет. Если вдруг такое впечатление сложилось, то эт зря.
Мне тимлид прислал код на рефакторинг и добавление фич давече. 4К строк с очень хорошим фолдингом и структуризацией.
Правда, не без копипасты, ну да ладно. Я поседел, пока вникал вообще, два рабочих дня ушло.
Нет уж, лучше в модулях все хранить, чтоб модуль умещался в 500-600 строк, тогда структура как на ладони, хоть и файлов дофига.
А в 500-600 строках идентацию сохранить - раз плюнуть.
Ну и попутно модули и пакеты, хоть этого и не требуют, но как бы намекают на то, что они не испольуют никаких глобальных переменных. Тогда и юнит-тестирование не превращается в ад, и можно спокойно проследить весь путь данных через код. А не гадать, зачем мы берем значение из another_global_array[29]
все проекты начинаются красиво, модульность, стройная иерархия классов и прочая, да)))
в общем - я полагаю что каждый язык хорош для своей области и задач
Хотя сколько раз орали что вот он очередной "убийца с++" - да так все и ушли в туман
PS на мой взгляд обильное использованяи интерпретаторов (зачастую с открытым исходным кодом) кроется не в их превосходстве над старичками - а в том что это единственный доступный и простой способ привинтить поддержку скриптов к своим продуктам (тот же контакт)
PPS глобальные массивы это беспредел - есть же более-менее элегантные или хотя бы легко читаемые\поддерживаемые пути решения для всяческих складов и обменов данными между модулями. Тем более сейчас когда многопоточность плотно входит в нашу нелегкую жизнь
если быть чистоплотным - то они такими и заканчиваются
Вот, допустим, 6-месячный проект для контакта, который компилируется в ~100 000 строк для вставки (в общей сложости каждой из 12*8 крутилок применяется в зависимости от ситуации 1 из 30 скинов и меняется 1 120 контрол параметров, попутно, на каждой крутится персональный расчет LFO и т.д.)
По-моему, вполне читабельно и рефакторебельно
P.S. Сейчас копаюсь в исходниках KSP Sublime, тоже очень приятно. Ниллс не дурак, писал хорошо
Вложения
А посоветуйте, что почитать по написанию тестов? Чет у меня мозги в это сторону пока плохо работают.
Не, я понимаю, что все водится к достаточно простой схеме: Взять тестируемый код и впихнуть в него данные, которые должны к нему попасть.
Но когда пытаюсь это делать в реальном проекте - вообще сообразить не могу, что делать. То ли архитектура дурацкая, то ли лыжи не едут.
Не, я понимаю, что все водится к достаточно простой схеме: Взять тестируемый код и впихнуть в него данные, которые должны к нему попасть.
Но когда пытаюсь это делать в реальном проекте - вообще сообразить не могу, что делать. То ли архитектура дурацкая, то ли лыжи не едут.
Ещё можно поглядеть тест работы в схематичном виде в DRAKON EDITORE как живой пример, cpp_test и т.п. алгоритмы.Программа написана на Tcl и частично сгенерирована сама в себе, с открытым кодом ,может генерировать схему в язык,можно дописать свой генератор,всё доступно для просмотра,но Tcl-это что-то с чем-то,с наскоку не освоить,документации толковой мало(русской).
Так, смотрю много толковых ребят, рискну спросить здесь.
Есть одна идея, которую хочется реализовать даже чисто для себя. Связана она грубо говоря с быстрым и умным поиском на десктопе. Но в целом у приложения будет достаточно внушительный функционал, даже если брать только версию для про-аудио.
Так вот вопрос: знаю html+css+js и наткнулся на electron.js, который работает грубо говоря как Хром.
Плюсы:
- можно будет легко и удобно связать в будущем сайт софтины и саму софтину (в частности настройки для определённого аккаунта и многое другое)
Минусов я не знаю, т.к. я не писатель на C++/C#. Джаву не предлагайте Приложение должно быть под мак и винду.
Вопрос: кто-то что-то посоветует на счёт разработки кроссплатформенного приложения под десктоп, которое:
- будет плотно работать с файловой системой
- должно быть очень отзывчивым по интерфейсу
Или лучше не экспериментировать и пойти нативным путём?
Обосновано, если можно.
Спасибо.
Есть одна идея, которую хочется реализовать даже чисто для себя. Связана она грубо говоря с быстрым и умным поиском на десктопе. Но в целом у приложения будет достаточно внушительный функционал, даже если брать только версию для про-аудио.
Так вот вопрос: знаю html+css+js и наткнулся на electron.js, который работает грубо говоря как Хром.
Плюсы:
- можно будет легко и удобно связать в будущем сайт софтины и саму софтину (в частности настройки для определённого аккаунта и многое другое)
Минусов я не знаю, т.к. я не писатель на C++/C#. Джаву не предлагайте
Приложение должно быть под мак и винду.Вопрос: кто-то что-то посоветует на счёт разработки кроссплатформенного приложения под десктоп, которое:
- будет плотно работать с файловой системой
- должно быть очень отзывчивым по интерфейсу
Или лучше не экспериментировать и пойти нативным путём?
Обосновано, если можно.
Спасибо.
Конкретно эта функция от языка не очень зависит.
Не ясно что вы подразумеваете. Сам по себе интерфейс при любом раскладе быстрый. Тупить он начинает, когда ожидает выполнения задачи перед выводом следующего состояния.
А задачи я не понял. Можно подробнее?
Да ладно. Или на ноде или на чём-то другом. Я ж просто указал, что с джс работал в вебе, но от веба устал очень.
Ну так то "секрет фирмы", но кратко ведь описал в посте. Первоначально это просто быстрый специализированный поиск определённых типов файлов.
а в этом есть очень рациональное ерно
Код:
<path>\KSP_doc\Source>python -m unittest discover -v -s ".\tests" -t "."
tests.test_main (unittest.loader._FailedTest) ... ERROR
test_MakeIndex (tests.test_make.WriteTest) ... ok
test_WriteFile (tests.test_make.WriteTest) ... ok
======================================================================
ERROR: tests.test_main (unittest.loader._FailedTest)
----------------------------------------------------------------------
ImportError: Failed to import test module: tests.test_main
Traceback (most recent call last):
File "C:\Users\Levitanus\AppData\Local\Programs\Python\Python36-32\lib\unittest\loader.py", line 428, in _find_test_path
module = self._get_module_from_name(name)
File "C:\Users\Levitanus\AppData\Local\Programs\Python\Python36-32\lib\unittest\loader.py", line 369, in _get_module_from_name
__import__(name)
File "<path>\KSP_doc\Source\tests\test_main.py", line 4, in <module>
import main
File "<path>\KSP_doc\Source\main.py", line 74
def WriteDocstringToFile(self, Lines, objList, objClass)
^
SyntaxError: invalid syntax
----------------------------------------------------------------------
Ran 3 tests in 0.016s
FAILED (errors=1)
<path>\KSP_doc\Source>python -m unittest discover -v -s ".\tests" -t "."
test_CheckDockstring (tests.test_main.FileTest) ... ERROR
test_CheckImport (tests.test_main.FileTest) ... ok
test_MakeIndex (tests.test_make.WriteTest) ... ok
test_WriteFile (tests.test_make.WriteTest) ... ok
======================================================================
ERROR: test_CheckDockstring (tests.test_main.FileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "<path>\KSP_doc\Source\tests\test_main.py", line 62, in test_CheckDockstring
self.file.CheckDocstrings(test_source)
File "<path>\KSP_doc\Source\main.py", line 72, in CheckDocstrings
WriteDocstringToFile(Lines, self.Docstrings, self.Docstring)
NameError: name 'WriteDocstringToFile' is not defined
----------------------------------------------------------------------
Ran 4 tests in 0.019s
FAILED (errors=1)
<path>\KSP_doc\Source>python -m unittest discover -v -s ".\tests" -t "."
test_CheckDockstring (tests.test_main.FileTest) ... ok
test_CheckImport (tests.test_main.FileTest) ... ok
test_MakeIndex (tests.test_make.WriteTest) ... ok
test_WriteFile (tests.test_make.WriteTest) ... ok
----------------------------------------------------------------------
Ran 4 tests in 0.019s
OK
Последнее редактирование:
ну так иначе бы столько книжек не писали бы люди вумные для нас неразумных на эту тему )))а в этом есть очень рациональное ерно
А что-где поискать про реализацию кучи своими руками?
Я тут в третий раз пытаюсь улучшить контактовский скрипт процессор) В первый раз был ахтунг с хорошим посылом на макросах, второй раз делал парсер с компилятором поверх парсера с компилятором, что было заметно лучше, но медленно, в силу изобретения велосипеда.
Сейчас я решил, что все уже придумано до нас, и есть смысл все, что возможно на этапе препроцессора отдать уже готовому питону, а на компилятор подавать уже относительно готовенький код KSP.
В принципе, идея получилась годная, хоть и реализована процентов на 20. Готовы прообразы типов данных, составление и развертывание синтаксического дерева в готовый код, стек для локальных переменных, аллокация сложных объектов, на уровне концепта обрисована аллокация функций, короче, многообещающая получается машинка)
Сейчас я задумался о реалиации динамической памяти. Но, коль таковой изначально в KSP не предусмотрено, надо (хотя я уже задумываюсь, надо ли) изобретать велосипед. И нашел пару статей про совсем машинные реализации, но чет пока переваривать сложно. Может есть уже какие реализации, или алгоритмы, человечески описанные?
Я тут в третий раз пытаюсь улучшить контактовский скрипт процессор) В первый раз был ахтунг с хорошим посылом на макросах, второй раз делал парсер с компилятором поверх парсера с компилятором, что было заметно лучше, но медленно, в силу изобретения велосипеда.
Сейчас я решил, что все уже придумано до нас, и есть смысл все, что возможно на этапе препроцессора отдать уже готовому питону, а на компилятор подавать уже относительно готовенький код KSP.
В принципе, идея получилась годная, хоть и реализована процентов на 20. Готовы прообразы типов данных, составление и развертывание синтаксического дерева в готовый код, стек для локальных переменных, аллокация сложных объектов, на уровне концепта обрисована аллокация функций, короче, многообещающая получается машинка)
Сейчас я задумался о реалиации динамической памяти. Но, коль таковой изначально в KSP не предусмотрено, надо (хотя я уже задумываюсь, надо ли) изобретать велосипед. И нашел пару статей про совсем машинные реализации, но чет пока переваривать сложно. Может есть уже какие реализации, или алгоритмы, человечески описанные?
А у нас чет не очень приживается этот подход. Требование писать юниттесты поставили, но мало кто реальные юнитесты пишет. Обычно делают фейк сводящийся к RETURN YES. + подход к разработке нужно менять. Пишется сначала тест, потом код. А обычно все происходит с точностью до наоборот - сначала код, потом фейковый юниттест, лишбы успеть в срок. Причем код обычно слабо подготовлен к тестированию юниттестами, ибо процедуры - простыни по 1000 строк))) попробуй их протетсируй.
Последнее редактирование:
@bytie, попробуйте язык Rust или D, на них есть переписаные vst sdk.
Rust это типа какой-то навороченый javascript, сильно невникал но примеры показали что нет предела беспределу))))
@PianoIst, ковыряйте под питон Numpy, матрицы, ассоциативные массивы и parse kit в помощь!
Сейчас лень искать по винту, но думаю вы сможете сами нагуглить статьи с примерами как реализовать кучу или стэк с помощью numpy.
Я сейчас подался в CSound и его пристройку к риперу, пока на приплюснутом ковыряюсь, в питоне уже за пару месяцев начинаю путатся))))
Rust это типа какой-то навороченый javascript, сильно невникал но примеры показали что нет предела беспределу))))
@PianoIst, ковыряйте под питон Numpy, матрицы, ассоциативные массивы и parse kit в помощь!
Сейчас лень искать по винту, но думаю вы сможете сами нагуглить статьи с примерами как реализовать кучу или стэк с помощью numpy.
Я сейчас подался в CSound и его пристройку к риперу, пока на приплюснутом ковыряюсь, в питоне уже за пару месяцев начинаю путатся))))
@Alex_028, видимо, я либо не там искал, либо неправильно объяснил.
Меня интересует не бинарное дерево, это мне понятно. Мне интересна куча в смысле - выделенная память под динамическое создание объектов.
В общем виде я понял, что должно быть что-то вроде
Но когда велосипед изобретается совсем с нуля, боязно как-то
Меня интересует не бинарное дерево, это мне понятно. Мне интересна куча в смысле - выделенная память под динамическое создание объектов.
В общем виде я понял, что должно быть что-то вроде
Код:
heap[size]
blocks[size/2, size/2, size/2] // индекс в куче, размер, свободен\занят
func alloc(obj){
local size := get obj size
for block in blocks{
if block[2] == free and block[1] > size{
local nextblock := block
block := [block[0], size, used]
owerride next blocks (nextblock, size) // уменьшаем размер свободного блока на размер выделенного, и сдвигаем все следующие блоки на одну ячейку
return block[0]
break
}
}
}
други, а я вот нуб, и хочу просвятиться- а как програмятся плаги VST - как я это представляю: пишется сначало код (в том же C++допустим), а потом скачивается конвертор с сайта штайни и весь код перегоняется в dll или как-то это иначе происходит?
@SuperDroid, есть такая штука - vst sdk, это набор инструкций для взаимодействия хоста с плагином и обратно.
С его помощью пишут код который потом компилируют в .dll.
Juce это фреймворк уже с кучей готовых функций для отрисовки пользовательского интерфейса, некоторыми алгоритмами синтеза и работы с аудио-видео-midi форматами.
Без vst sdk Juce может компилироваться только как standalone, т.е. как экзешник.
Вот отличный блог про вступление в vst:
http://martin-finke.de/blog/tags/making_audio_plugins.html
@PianoIst, что-то подобное уже есть, при чем в последней версии Active state python 2.7.13 встречал либу для динамической генерации бинарного дерева, сразу в памяти все шуршит. Увы невникал, вечером посмотрю по винту что у меня из готовых кодов валяется, может что-то вам пригодится.
С его помощью пишут код который потом компилируют в .dll.
Juce это фреймворк уже с кучей готовых функций для отрисовки пользовательского интерфейса, некоторыми алгоритмами синтеза и работы с аудио-видео-midi форматами.
Без vst sdk Juce может компилироваться только как standalone, т.е. как экзешник.
Вот отличный блог про вступление в vst:
http://martin-finke.de/blog/tags/making_audio_plugins.html
@PianoIst, что-то подобное уже есть, при чем в последней версии Active state python 2.7.13 встречал либу для динамической генерации бинарного дерева, сразу в памяти все шуршит. Увы невникал, вечером посмотрю по винту что у меня из готовых кодов валяется, может что-то вам пригодится.