Скорее всего, в определённый момент мы просто переедем на гитхаб. К сожалению, у меня нет опыта руководства опенсорсными проектами, поэтому имеются естественные опасения в связи с переездом и открытием проекта для редактирования сообществом. С другой стороны, как говорил в одном интервью автор D Волтер Брайт, одна из вещей, о которых он жалеет — это то, что не отдал D сообществу раньше :)
По поводу вкусностей, присутствующих в других скриптовых языках: лямбды и замыкания со временем обязательно появятся. Пока в качестве альтернативы настоящим замыканиям можно использовать частичное применение — в Jancy можно захватывать произвольные контекстные аргументы в момент создания указателя на функцию.
Спасибо! Только Jancy — не интерпретатор, а именно транслятор. Пока это JIT-компилятор, а сохранение исполнимых бинарников — в планах и со временем допилится.
Псевдо-исключения, коды возврата и try/catch — это какая-то каша. И вообще, скриптовый язык с кодами возврата — это жуть. Вы-же LLVM используете. Не смогли выяснить как там генерировать код выбрасывающий и ловящий исключения? К тому же для x86-64 существует ABI стандарт, строго определяющий бинарный интерфейс для исключений.
Проблема с плюсовыми исключениями та, что для его работы требуется суметь пробежаться вниз по стековым фреймам, находясь глубоко внутри стека вызовов. Гарантии, что это удастся сделать, можно дать только в том случае, если в стеке вызовов присутсвуют только функции, скомпилированные одним и тем же компилятором.
Для примера — код, генерируемый llvm 3.3 не уживался с g++ 4.8.2 на x86_64: в определённый случаях c++ (1) -> jancy (2) -> c++ (3) exception из с++ (3) не ловился в с++ (1). А когда стек вызовов вообще мультиязыковый, использовать плюсовые исключения — ну ненадёжно. Самый безопасный и прозрачный подход — коды возврата и потоковые переменные. Над этим насыпано синтаксического сахара, чтоб не было «жути» ;)
Убедите меня, что ваш язык лучше Python-а. В питоне есть исключения (и лямбды, и ещё чего всякого), а у вас нет.
ОК, попробую :) Исключения в Jancy есть, но в виде синтаксического сахара. Лямбды будут. А вот что у нас уже сейчас лучше чем в Питоне, так это работа с бинарными данными: безопасная адресная арифметика и инкрементальный разбор регекспами. И интеграция с си бесшовная, лучше чем в питоне. А ещё у нас есть реактивное программирование ;)
Но вообще вы абсолютно правы — сравнивать надо с Питоном. Это наша область применимости.
Суть в близости нашего скриптового языка к си. Можно сказать, у нас скриптовый си с плюшками. Уникальных фич достаточно много (мы, на самом деле, подзатянули с «выходом в свет» с допиливанием уникальных фич)
безопасная адресная арифметика
встроенный генератор лексеров
реактивное программирование на уровне языка
И много нововведений по мелочи, как-то встроенная поддержка бигендианов, енумы для битовых флагов, указатели на функции с отложенным исполнением и другое. Здесь подробнее и с примерами: http://tibbo.com/jancy/features.html
Жаль что столько минусов — не думаю, что ваш коммент этого заслуживает. Я совершенно согласен, что языков понаваяно уже ого-го сколько, о чём и написал в самом первом абзаце. А то ли ещё будет! ;) Достаточность, однако, вопрос не такой однозначный. Всегда есть что улучшить, и всегда найдётся горячая голова, которая попробует это сделать. В нашем случае самый краткий ответ на вопрос «зачем?» — это создание скриптового языка с указателями и безопасной адресной арифметикой — такого пока не было.
Кстати, в Rust мы не метим. Думаю, что в будущем Rust (или что-то подобное) будет потихоньку теснить си на ниве системного программирования — это язык с по-настоящему прорывными концепциями в области управления памятью. У нас же — скриптовый язык. Мы метим в Питоны ;)
Почему вы называете его — язык для системных/сетевых программистов?
В тексте не смог найти пояснений на этот счет?
Тут важно уточнить. Jancy — не язык системного программирования, а скриптовый язык для системного/сетевого программирования. По области применимости он целит не в Rust, а в Питон. А пояснения были. Он может быть удобен для системного/сетевого программирования (как минимум, в ряде сценариев) по следующим причинам:
поддержка указателей на данные и адресной арифметики (самый лучший способ «гулять» по бинарным данным для анализа или генерации)
ABI-совместимость с C/C++ бибилотеками (вызывать системные функции проще чем в любом другом скриптовом языке)
Высокий уровень совместимости исходных кодов в с C (иногда можно вообще копипастить код и алгоритмы на С)
На самом деле, в языке есть и другие фишки, облегчающие написание асинхронных IO-приложений, но, пожалуй, в плане системных/сетевых скриптов эти три — основные.
Не кажется ли вам, что для сетевых программистов вход в мир Си и Ява очень трудный. Python в этом вопрос значительно проще и уже набрал хорошую популярность в среде сетевиков.
Это смотря откуда эти программисты пришли ;) Я всегда наоборот искал что-то си-подобное и подозреваю, что я в этом не одинок.
Python в этом вопрос значительно проще и уже набрал хорошую популярность в среде сетевиков.
Про простоту — см выше, си-подобные языки действительно имеют более высокий порог вхождения. Но это не столь релевантно, если человек УЖЕ приходит из си-мира. Jancy ориентируется именно на таких. А вот про популярность Питона у сетевиков — совершенно справедливо подмечено! Навряд ли я смогу это доказать, но думаю, что, одна из немаловажных причин этой популярности — это самый простой среди скриптовых языков вызов си из Питона. Так вот, Jancy идёт в этом направлении ещё дальше.
Как планируете развивать и строить комьюнити?
Это вопрос на миллион :) Как минимум — начать рассказывать, что вот-де есть такой скриптовый язык с указателями, поездить по конференциям, а в итоге мы, конечно, хотели бы найти увлечённых разработчиков, заинтересованных обсуждать, спорить, пробовать, а в идеале и присоединиться к работе над проектом.
Версия с поддержкой IPv6 во всех сокетных плагинах доступна для скачивания. Настройки присоединения к мультикастовым группам пока нет, но это тоже допилится в обозримом будущем.
К сожалению, у меня нет аккаунта на вашем трекере. Создам чуть попозже и тогда добавлю. Как я себе вижу это в IDE — помимо File View, отображающего структуру файловой системы, должен быть какой-нибудь Source Group View, отображающий структуру виртульных папок (в качетсве reference — смотреть что создаёт Visual Studio-генератор cmake-а).
Кому надо — будут использовать для навигации виртуальные папки, кому нет — можно работать с File View, как привыкли.
Не хочу начинать священную войну о том, как правильно организовывать структуру проекта, поэтому всё нижеследующее является моим личным имхо.
Разбивать файлы на группы можно по разным критериям. Соответственно, итоговые группы получаются разные. Разбиение с использованием директорий файловой системы даёт возможность применить только один какой-то критерий.
Впрочем, от абстракции к конкретике: где лично мне удобно использовать виртуальные папки.
Допустим, у нас есть библиотека. В ней есть публичные хедеры (.h) и исходники реализации (.cpp .h и т.д). Очевидно, публичные хедеры должны лежать в папке отдельной от исходников реализации. В то же время для редактирования удобнее видеть .cpp и соответвующий .h рядышком.
Вторая причина. Если библиотека нетривиальна, то всегда хочется группировать файлы по функционалу. Если группировать их с использованием директорий файловой системы, то становится неудобно использовать директорию include (например, в llvm вечно приходится искать, в какую подпапку они положили соответвующий хедер, особенно с учётом того что они любят тасовать файлы по папкам в каждом новом релизе). Я лично предпочитаю иметь одну большую папку include, а группировку в ней осуществлять виртуальными папками.
Впрочем, на вкус и цвет… Но подозреваю, что я не единственный любитель виртуальных папок :)
Для *nix-овой C++-разработки в настоящий момент использую NetBeans, но нахожусь в активном поиске (все проекты на cmake). Пробовал clion где-то полгода назад, но тогда он был достаточно нестабилен (по крайней мере, были проблемы с зависаниями на моих проектах). С удовольствием поиграюсь с новым релизом.
Скажите пожалуйста, планируется ли поддержка директивы cmake source_group (виртуальные папки)? К сожалению, на сегодняшний момент единственный способ использовать виртуальные папки — это Visual Studio-генератор (но это подходит только для Windows-разработки). Все поддерживающие cmake ИДЕшки почему-то принципиально игнорируют данную директиву и используют структуру папок директории проекта.
Если не планируется (или вопрос поддержки обсуждается) — занесите в wish-list плз.
Да вроде бы кардинальных изменений в работе с сокетами быть не должно (AF_INET->AF_INET6, sockaddr_in->sockaddr_in6, ну и обработка парсинга и форматирования IPv6 адресов). С мультикастами тоже посылка и приём поменяться вроде не должны, а вот настройку присоединения к группе надо добавить.
Впрочем, вполне мог что-то пропустить — практического опыта программирования ни IPv6, ни мультикастов у меня нет (но есть ощущение, что любые проблемы тут можно решить без глобальных переделок).
В любом случае соглашусь, что поддержку IPv6 надо для приличия допилить.
Несомненно, много чего ещё можно и нужно добавлять. Писали нинзю мы прежде всего под себя и свои собственные потребности. Так как наши встраиваемые модули в настоящий момент работают на IPv4 и не поддерживают мультикастовые группы, то и в нинзе эти вопросы остро пока не стояли (вообще я большой сторонник принципа «you ain't gonna need it»).
На каком уровне вы ожидаете поддержку IPv6? Парсинг и отображение IPv6-адресов допилим в ближайших релизах. Насколько актуальны мультикасты в плагине UDP Socket?
На самом деле, это была одна из целей публикации на хабре — обсудить акутальность и приоритет новых фич для дальнейшего развития продукта.
В архиве (tar.gz) зачем-то пути закодированы с точкой в начале
Спасибо за замечание, поправил сборочные скрипты. В следующем релизе будет как надо.
Плюс tar.gz не содержит инструкций по сборке (debian/*)
А вот тут не совсем понял. В таре ведь лежат уже собранные бинарники плюс скрипты (которые собирать не надо). Что вы имеете в виду под инструкциями по сборке?
Ну и главное, лицензия печальная. Почему не свободная? Было бы здорово быть во всех себя уважающих дистрибутивах, правда?
Сложный вопрос. Действительно, было бы крайне здорово присутсвовать в официальных репозиториях популярных дистрибутивов. С другой стороны, и вы, наверно, вполне можете понять наше стремление вернуть материальные и временные вложения в масштабную разработку.
Кстати, позволю себе с вами не согласится в том, что ситуация с лицензией печальная. Вообще лицензия для нинзи последовательно идёт по пути смягчения, и в нынешней версии для любого некоммерческого использования всё совершенно бесплатно; нет ограничений по времени, функционалу, как нет и никакого клянчания, наг-скринов или баннеров. Для коммерческого использования требуется единократное приобретение лицензии по цене, которую может позволить себе любой индивидуальный предприниматель (не говоря уже про полноценную компанию).
Спасибо за ссылку. Данным сниффером я не пользовался, но по секции «Examples» достаточно понятно, что он из себя представляет. Отличия от нашего продукта следующие:
justniffer — сниффер, основанный на pcap и заточенный под TCP. ioninja — проектировалась как универсальная отладочно-тестировочная утилита а-ля всё-в-одном (terminal, sniffer, serial, tcp, udp broadcast, generic files, windows named pipes и т.д.)
justniffer — утилита командной строки, а ioninja — утилита с графическии интерфейсом. Нельзя сказать что один подход однозначно лучше или хуже: в одном случаев удобнее первое, в другом — второе. Но согласитесь, иногда удобный GUI проще в использовании, а иногда без GUI вообще не обойтись (hex-редактор?)
justniffer — не предоставляет собственно «программируемости», вместо этого есть возможность скармливать выхлоп сниффера внешнему скрипту (или любой другой программе). ioninja — утилита со встроенным скриптовым языком (кстати, ожидаю вопросы «почему не питон, луа и т.д.» — тема интересная, с удовольствием поспорю ;)
Возможно, что-то проглядел, но вообще разница между продуктами достаточно ощутимая.
По поводу вкусностей, присутствующих в других скриптовых языках: лямбды и замыкания со временем обязательно появятся. Пока в качестве альтернативы настоящим замыканиям можно использовать частичное применение — в Jancy можно захватывать произвольные контекстные аргументы в момент создания указателя на функцию.
Проблема с плюсовыми исключениями та, что для его работы требуется суметь пробежаться вниз по стековым фреймам, находясь глубоко внутри стека вызовов. Гарантии, что это удастся сделать, можно дать только в том случае, если в стеке вызовов присутсвуют только функции, скомпилированные одним и тем же компилятором.
Для примера — код, генерируемый llvm 3.3 не уживался с g++ 4.8.2 на x86_64: в определённый случаях c++ (1) -> jancy (2) -> c++ (3) exception из с++ (3) не ловился в с++ (1). А когда стек вызовов вообще мультиязыковый, использовать плюсовые исключения — ну ненадёжно. Самый безопасный и прозрачный подход — коды возврата и потоковые переменные. Над этим насыпано синтаксического сахара, чтоб не было «жути» ;)
ОК, попробую :) Исключения в Jancy есть, но в виде синтаксического сахара. Лямбды будут. А вот что у нас уже сейчас лучше чем в Питоне, так это работа с бинарными данными: безопасная адресная арифметика и инкрементальный разбор регекспами. И интеграция с си бесшовная, лучше чем в питоне. А ещё у нас есть реактивное программирование ;)
Но вообще вы абсолютно правы — сравнивать надо с Питоном. Это наша область применимости.
И много нововведений по мелочи, как-то встроенная поддержка бигендианов, енумы для битовых флагов, указатели на функции с отложенным исполнением и другое. Здесь подробнее и с примерами: http://tibbo.com/jancy/features.html
Кстати, в Rust мы не метим. Думаю, что в будущем Rust (или что-то подобное) будет потихоньку теснить си на ниве системного программирования — это язык с по-настоящему прорывными концепциями в области управления памятью. У нас же — скриптовый язык. Мы метим в Питоны ;)
Тут важно уточнить. Jancy — не язык системного программирования, а скриптовый язык для системного/сетевого программирования. По области применимости он целит не в Rust, а в Питон. А пояснения были. Он может быть удобен для системного/сетевого программирования (как минимум, в ряде сценариев) по следующим причинам:
На самом деле, в языке есть и другие фишки, облегчающие написание асинхронных IO-приложений, но, пожалуй, в плане системных/сетевых скриптов эти три — основные.
Это смотря откуда эти программисты пришли ;) Я всегда наоборот искал что-то си-подобное и подозреваю, что я в этом не одинок.
Про простоту — см выше, си-подобные языки действительно имеют более высокий порог вхождения. Но это не столь релевантно, если человек УЖЕ приходит из си-мира. Jancy ориентируется именно на таких. А вот про популярность Питона у сетевиков — совершенно справедливо подмечено! Навряд ли я смогу это доказать, но думаю, что, одна из немаловажных причин этой популярности — это самый простой среди скриптовых языков вызов си из Питона. Так вот, Jancy идёт в этом направлении ещё дальше.
Это вопрос на миллион :) Как минимум — начать рассказывать, что вот-де есть такой скриптовый язык с указателями, поездить по конференциям, а в итоге мы, конечно, хотели бы найти увлечённых разработчиков, заинтересованных обсуждать, спорить, пробовать, а в идеале и присоединиться к работе над проектом.
Кому надо — будут использовать для навигации виртуальные папки, кому нет — можно работать с File View, как привыкли.
Разбивать файлы на группы можно по разным критериям. Соответственно, итоговые группы получаются разные. Разбиение с использованием директорий файловой системы даёт возможность применить только один какой-то критерий.
Впрочем, от абстракции к конкретике: где лично мне удобно использовать виртуальные папки.
Допустим, у нас есть библиотека. В ней есть публичные хедеры (.h) и исходники реализации (.cpp .h и т.д). Очевидно, публичные хедеры должны лежать в папке отдельной от исходников реализации. В то же время для редактирования удобнее видеть .cpp и соответвующий .h рядышком.
Вторая причина. Если библиотека нетривиальна, то всегда хочется группировать файлы по функционалу. Если группировать их с использованием директорий файловой системы, то становится неудобно использовать директорию include (например, в llvm вечно приходится искать, в какую подпапку они положили соответвующий хедер, особенно с учётом того что они любят тасовать файлы по папкам в каждом новом релизе). Я лично предпочитаю иметь одну большую папку include, а группировку в ней осуществлять виртуальными папками.
Впрочем, на вкус и цвет… Но подозреваю, что я не единственный любитель виртуальных папок :)
Скажите пожалуйста, планируется ли поддержка директивы cmake source_group (виртуальные папки)? К сожалению, на сегодняшний момент единственный способ использовать виртуальные папки — это Visual Studio-генератор (но это подходит только для Windows-разработки). Все поддерживающие cmake ИДЕшки почему-то принципиально игнорируют данную директиву и используют структуру папок директории проекта.
Если не планируется (или вопрос поддержки обсуждается) — занесите в wish-list плз.
Впрочем, вполне мог что-то пропустить — практического опыта программирования ни IPv6, ни мультикастов у меня нет (но есть ощущение, что любые проблемы тут можно решить без глобальных переделок).
В любом случае соглашусь, что поддержку IPv6 надо для приличия допилить.
На каком уровне вы ожидаете поддержку IPv6? Парсинг и отображение IPv6-адресов допилим в ближайших релизах. Насколько актуальны мультикасты в плагине UDP Socket?
На самом деле, это была одна из целей публикации на хабре — обсудить акутальность и приоритет новых фич для дальнейшего развития продукта.
Спасибо за замечание, поправил сборочные скрипты. В следующем релизе будет как надо.
А вот тут не совсем понял. В таре ведь лежат уже собранные бинарники плюс скрипты (которые собирать не надо). Что вы имеете в виду под инструкциями по сборке?
Сложный вопрос. Действительно, было бы крайне здорово присутсвовать в официальных репозиториях популярных дистрибутивов. С другой стороны, и вы, наверно, вполне можете понять наше стремление вернуть материальные и временные вложения в масштабную разработку.
Кстати, позволю себе с вами не согласится в том, что ситуация с лицензией печальная. Вообще лицензия для нинзи последовательно идёт по пути смягчения, и в нынешней версии для любого некоммерческого использования всё совершенно бесплатно; нет ограничений по времени, функционалу, как нет и никакого клянчания, наг-скринов или баннеров. Для коммерческого использования требуется единократное приобретение лицензии по цене, которую может позволить себе любой индивидуальный предприниматель (не говоря уже про полноценную компанию).
Возможно, что-то проглядел, но вообще разница между продуктами достаточно ощутимая.