Ух! чувствую, Вы очень увлечены своей идеей, но я до конца не понял, что же Вы хотите сделать. Ок, прокомментирую, то что понял :)))
Префиксные и постфиксные инкременты/декременты я в свое время реализовывал на рекурсивном спуске, значит они точно могут быть разобраны при помощи LL, но может не хватить LL(1), потребуется LL(k) для k>1. Наверное, хватит k=2. Поскольку JavaCC умеет генерировать LL(*) парсер, то есть с переменным k, то это не проблема.
Достоинство JavaCC — на выходе генератора получается довольно человеко-читаемый рекурсивный спуск, особенно при k=1, в отличие от yacc с их человеко-невоспринимаемыми таблицами. Но вот с модульностью, о чем был Ваш начальный вопрос все так же плохо. В JavaCC вся грамматика (лексика и синтаксис) языка должна быть описана одним файлом.
Как я понял Ваш самокат Вам нужно:
1. сперва сделать парсер языка, при помощи какого-то CC
2. затем на нем написать CC с Вашим языком, в качестве таргетного
И между 1 и 2 еще и компилятор или интерпретатор. Насколько мне известно Java примерно так и создавалась при помощи JavaCC.
При этом в качестве бонуса Вы хотите, чтобы в п.1 можно было генерировать как на Java машину, так и на .NET. Вот для решения этого бонуса, я думаю Вам лучше посмотреть на antlr. Он тоже LL(*), но в качестве таргета умеет и Java и C# и C++. Я с ним близко не знаком, но судя по репозиторию проект жив.
На всякий случай, LL по сравнению с LR это не хорошо и не плохо. Это просто по другому :) Просто надо учитывать, что в общем случае не каждую КС грамматику можно привести к LL. Хотя, большинство имеющих смысл таки да.
Учтите что javacc это генератор LL парсеров в отличие от семейства yacc которые дают парсер, основанный на LR, точнее LALR(1). Вообще, мне кажется Вы еще не определились с таргетным языком. Все таки F# или Java?
Как я понял автора, вопрос как раз и был в том, есть ли такие прокси сервера, которые умеют принимать трафик от браузера c ssl, ну соответсвенно, а кто есть те браузеры (если есть они есть), чтобы он могли к прокси серверу ходить с ssl.
Тайлинг поддерживаю!
Если без тайлинга, то я на Gnome2 или OS X вполне комфортно себя чувствую. Второго монитора мало, третьего тоже мало. А вот 6-9 рабочих столов на мониторе от 24 дюймов — это нормально.
Gnome2 все же лучше чем OS X, или не к ночи будет помянут Gnome3. :)
Есть серьезные проблемы с поддержкой 3D в драйверах для интегрированного видео от intel на Linux. Например, ubuntuforums.org/showthread.php?t=1968531
та система, на которой виндовая версия выдает 15-20 fps, linux-овая версия превращается в пошаговую стратегию (<2 fps).
Так, что все зависит от конкретной игрушки.
Если таки С++ и что-то типа сервиса (хотя зачем сервису кнопка?) :) то присоединяюсь к совету про POCO. Хотя в моем опыте использования была какая-то эпическая проблема, поиск которой занял несколько дней. За давностью лет (это было 4 года назад) уже не вспомню что именно, но причина была в отличиях реализации STL и компилятора VisualC++ vs GCC. То есть, и там и там код компилировался корректно, но вел себя по разному. Поэтому использование одинаковой фреймворки для разных платформ не гарантирует идентичности работы кода. Тестировать все равно надо.
Список тем, которые должны быть освещены в рамках учебного курса, конечно, указаны в ГОС. И в каждой конкретной дисциплине у конкретного преподавателя глубина рассмотрения каждой темы может отличаться. Сильно отличаться. Например, на тему «нормальные формы» можно потратить 16 часов лекций, а можно 15 минут (сказать: «есть 6+2 нормальных формы» займет еще меньше времени). Да и есть ли смысл изучать все 8 нормальных форм. Большинство преподавателей ограничивается третьей или, максимум, четвертой НФ. И этот вопрос (глубина проработки каждой темы) ГОС не регламентирует.
Более того. ГОС формируется тоже людьми. По каждой специальности есть некоторая профилирующая кафедра, преподаватели которой и определяют федеральную составляющую учебного плана специальности и наполнение каждой дисциплины (список тем). Может быть ТС как раз и работает на такой кафедре и ему поручили выяснить потребности индустрии. а? :))
Вы правы, вдумчиво надо.
Для Ubuntu, на пакетной базе которого основан Linux Mint с VirtualBox тоже не все гладко. Так-то, вообще, обновляется нормально через DKMS, но если _одновременно_ обновлять и ядро и VirtualBox, то получается нехорошо. модуль virtualbox пересобирается через DKMS с текущим ядром. И в результате после перезагрузки он (VirtualBox) не работает. Приходится пересобирать вручную.
Думаю, что есть еще софт, у которого есть с этим проблемы. Поэтому обновляю ядро только отдельно от всего.
Префиксные и постфиксные инкременты/декременты я в свое время реализовывал на рекурсивном спуске, значит они точно могут быть разобраны при помощи LL, но может не хватить LL(1), потребуется LL(k) для k>1. Наверное, хватит k=2. Поскольку JavaCC умеет генерировать LL(*) парсер, то есть с переменным k, то это не проблема.
Достоинство JavaCC — на выходе генератора получается довольно человеко-читаемый рекурсивный спуск, особенно при k=1, в отличие от yacc с их человеко-невоспринимаемыми таблицами. Но вот с модульностью, о чем был Ваш начальный вопрос все так же плохо. В JavaCC вся грамматика (лексика и синтаксис) языка должна быть описана одним файлом.
Как я понял Ваш самокат Вам нужно:
1. сперва сделать парсер языка, при помощи какого-то CC
2. затем на нем написать CC с Вашим языком, в качестве таргетного
И между 1 и 2 еще и компилятор или интерпретатор. Насколько мне известно Java примерно так и создавалась при помощи JavaCC.
При этом в качестве бонуса Вы хотите, чтобы в п.1 можно было генерировать как на Java машину, так и на .NET. Вот для решения этого бонуса, я думаю Вам лучше посмотреть на antlr. Он тоже LL(*), но в качестве таргета умеет и Java и C# и C++. Я с ним близко не знаком, но судя по репозиторию проект жив.