всё возможно. на таких расстояниях большой потенциал между землями возникает, особенно в городской застройке. Кстати говоря они выпустили под конец своего существования грозозащиту, так её вроде до сих пор торгуют. У нас она используется(кое где ещё).
а так это вы про ту первую статью! ну да, я и забыл про неё. это мне нужно было как то на хабр попасть. мне та статья показалсь интересной и в тему, тем более что там статья была из двух частей, одна была переведена а вторая нет. И в той статье как бы смысл не про конкретно Ракет, а про всю лисп экосистему. А так я собирался расскзать про программирование на Схеме в Гимпе. это был первый цикл, в результате которого родилась идея создать ООП тоже на схеме. вот делюсь результатами.
В Racket тоже самое можно сделать, просто эта статья является частью серии статей в которой я описываю создание объектно-ориентированной системы в GIMP Script-fu или tinyscheme. Её можно перенести на ракет, но нужны будут небольшие изменения.
А миксины это уже не мало! Это уже удобно. Кстати история была такая что создатели CLOS, любили заходить в кафе-мороженное и брали там мороженное с различными добавками варьенья, джемов и шоколада и чего то ещё не знаю, и захотели чтобы в их системе было также, к основному объекту можно было добавлять любые ингридиенты. И подмешивания произошли именно с этой истории. Кстати говоря, через множественное наследование, реалиуется всё то что в Джаве реализуется через множественное наследование интерфейсов. только тут мы можем унаследовать и реализацию и необходимые ей стостояния.
вопрос в том как реализован сет? можно просто список!!! я такие реализации встречал. Можно хеш-таблица, это будет быстро, но медленнее чем массив. но экономичнее по памяти. Или сет через бинарные деревья. но опять таки это всё медленнее. я предложил вариант, с максимальным использованием памяти, но максимальным по производительности, т.е с минимальной вычислительной нагрузкой.
самого быстрого способа нахождения гласной в строке - ЗДЕСЬ НЕТ! самый быстрый способ это использование массива, где индексом будет код буквы(ну или его смещение относительно первой буквы алфавита), а элементами логические значения, на месте гласных истина, согласных ложь.
большинство изображений сделано при отрисовке контуров с помощью pencil карандашом, а то и с помощью заполнения контура shape, а карандаш это таже кисть но с резкими краями. да в этом случае алиасинг будет плохой. А вот когда рисовал звезду, там контур рисовался кистью и внутренний узкий, и внешний широкий, там с алиасингом всё в порядке.
честно, я не придавал этому значения, мне важнее было код написать. деталей работы с гимпом я не касался.
Спасибо за замечание! Вы правы, в данной статье НЕТ НАСЛЕДОВАНИЯ. т.е я его не реализовывал, и обозначенная в самом начале статьи проблема решается через сигнал, допустим :draw, которые различные классы объектов, должны реализовать самостоятельно, таким образом каждый объект, будет исполнять свой код, а основная программа просто для любого объекта посылать им сигнал :draw. Тут как бы дело не в наследовании, которое в обычном ООП обеспечивает нам перегрузку методов, и в свою очередь при этом обеспечивается, полиморфное поведение. Здесь просто интерфейс "виртуальных" сигналов, обработку которых должен обеспечить каждый класс.
Другое дело, что наследование помогло бы нам избежать дублирования кода, который мы могли бы определить как поведение для базового класса, а различающийся код, определять в наследниках. Но на то это и простая реализация, что бы не влезать в дебри реализации наследования. Я вот пока не знаю как описать то что я написал в obj4.scm, где и реализовано наследование, причём множественное, да что там говорить практически аналог CLOS по возможностям, но без MOP. С помощью этой системы я прорешал примеры из книги "Теория вычисления для программистов" Тома Стюарта. А код там выполнен на Ruby. И по выразительности моего кода, я бы не сказал что он сильно уступает коду на Ruby. Но вот пример:
Совершенно с Вами согласен, данный подход предложен в SICP, здесь я пытался его лишь повторить и предложить к нему синтаксический сахар, в виде макроса который формирует функцию диспетчеризации сообщений.
И вот ещё что, вы простите, поленились, в структуре mat3_t вы задали коэффициэнты матрицы через вектор. это, честно говоря какой то нонсенс. структуры для того и создаются что бы именовать свои поля, компилятор потом всё это корректно обработает. Поэтому если будете переделывать проименуйте отдельно каждый коэффицэнт как нибудь так mIJ, где I номер строки J номер столбца, или как нибудь подобно. Вам потом самому будет проще разбираться с алгоритмом.
Спасибо большое, действительно полезное использование. Я не решал таких задач, поэтому не знал. Авторам статьи надо было с этого начинать, и реализовывать не сам двусвязный список, а именно LRU кеши. Тогда было бы значительно интереснее.
К сожалению не всё так просто. Если подходить к рисованию игровых сцен спрайтами как в Doom, то игровых персонажей рисовать можно.(посчитать уменьшающий масштаб от расстояния). Но вот с отрисовкой сцены возникнут проблемы, дело в том что проективные построения не линейны, и прорисовать их с помощью gimp-item-transform-matrix не получится. Но есть хорошая новость - в гимпе есть аналогичная линейному преобразованию функция, для перспективных проекций - gimp-item-transform-perspective. Я с ней не работал, т.к. она не входила решаемую мной задачу, вернее выходила за её рамки, но в принципе проверить её работоспособность вполне себе можно.
Спасибо за комментарий, CFDG не рассматривал, просто я делал упражнение из SICP, поэтому и выбрал этот язык, а CFDG, насколько я понял возник гораздо позже. Но идея его реализовать в GIMP весьма интересная. Я подумаю, может быть может быть и его реализую.
спасибо друзья, было очень познавательно.
Интересно, но очень сложно!
всё возможно. на таких расстояниях большой потенциал между землями возникает, особенно в городской застройке. Кстати говоря они выпустили под конец своего существования грозозащиту, так её вроде до сих пор торгуют. У нас она используется(кое где ещё).
может IolaPLN? это вроде разработка, аналог ADSL, как раз родилась в резульате работ вот над этим LR лонг рейнж.
а так это вы про ту первую статью! ну да, я и забыл про неё. это мне нужно было как то на хабр попасть. мне та статья показалсь интересной и в тему, тем более что там статья была из двух частей, одна была переведена а вторая нет. И в той статье как бы смысл не про конкретно Ракет, а про всю лисп экосистему. А так я собирался расскзать про программирование на Схеме в Гимпе. это был первый цикл, в результате которого родилась идея создать ООП тоже на схеме. вот делюсь результатами.
В Racket тоже самое можно сделать, просто эта статья является частью серии статей в которой я описываю создание объектно-ориентированной системы в GIMP Script-fu или tinyscheme. Её можно перенести на ракет, но нужны будут небольшие изменения.
спасибо за обзор!
30 лет назад было отечественное решение IOLANET25LR. Славный был кооператив, делали сетевое оборудование мирового уровня.
А миксины это уже не мало! Это уже удобно. Кстати история была такая что создатели CLOS, любили заходить в кафе-мороженное и брали там мороженное с различными добавками варьенья, джемов и шоколада и чего то ещё не знаю, и захотели чтобы в их системе было также, к основному объекту можно было добавлять любые ингридиенты. И подмешивания произошли именно с этой истории. Кстати говоря, через множественное наследование, реалиуется всё то что в Джаве реализуется через множественное наследование интерфейсов. только тут мы можем унаследовать и реализацию и необходимые ей стостояния.
вопрос в том как реализован сет? можно просто список!!! я такие реализации встречал. Можно хеш-таблица, это будет быстро, но медленнее чем массив. но экономичнее по памяти. Или сет через бинарные деревья. но опять таки это всё медленнее. я предложил вариант, с максимальным использованием памяти, но максимальным по производительности, т.е с минимальной вычислительной нагрузкой.
самого быстрого способа нахождения гласной в строке - ЗДЕСЬ НЕТ! самый быстрый способ это использование массива, где индексом будет код буквы(ну или его смещение относительно первой буквы алфавита), а элементами логические значения, на месте гласных истина, согласных ложь.
большинство изображений сделано при отрисовке контуров с помощью pencil карандашом, а то и с помощью заполнения контура shape, а карандаш это таже кисть но с резкими краями. да в этом случае алиасинг будет плохой. А вот когда рисовал звезду, там контур рисовался кистью и внутренний узкий, и внешний широкий, там с алиасингом всё в порядке.
честно, я не придавал этому значения, мне важнее было код написать. деталей работы с гимпом я не касался.
Спасибо за замечание! Вы правы, в данной статье НЕТ НАСЛЕДОВАНИЯ. т.е я его не реализовывал, и обозначенная в самом начале статьи проблема решается через сигнал, допустим :draw, которые различные классы объектов, должны реализовать самостоятельно, таким образом каждый объект, будет исполнять свой код, а основная программа просто для любого объекта посылать им сигнал :draw. Тут как бы дело не в наследовании, которое в обычном ООП обеспечивает нам перегрузку методов, и в свою очередь при этом обеспечивается, полиморфное поведение. Здесь просто интерфейс "виртуальных" сигналов, обработку которых должен обеспечить каждый класс.
Другое дело, что наследование помогло бы нам избежать дублирования кода, который мы могли бы определить как поведение для базового класса, а различающийся код, определять в наследниках. Но на то это и простая реализация, что бы не влезать в дебри реализации наследования. Я вот пока не знаю как описать то что я написал в obj4.scm, где и реализовано наследование, причём множественное, да что там говорить практически аналог CLOS по возможностям, но без MOP. С помощью этой системы я прорешал примеры из книги "Теория вычисления для программистов" Тома Стюарта. А код там выполнен на Ruby. И по выразительности моего кода, я бы не сказал что он сильно уступает коду на Ruby. Но вот пример:
но в отличии от автора, я выполнял денотацию не в Ruby, а в Scheme. И этот код выполнялся в GIMP script-fu.
Совершенно с Вами согласен, данный подход предложен в SICP, здесь я пытался его лишь повторить и предложить к нему синтаксический сахар, в виде макроса который формирует функцию диспетчеризации сообщений.
Я вот смотрю у вас списки через монады реализуются, а как обстоят дела с массивами и хеш-таблицами?
И вот ещё что, вы простите, поленились, в структуре mat3_t вы задали коэффициэнты матрицы через вектор. это, честно говоря какой то нонсенс. структуры для того и создаются что бы именовать свои поля, компилятор потом всё это корректно обработает. Поэтому если будете переделывать проименуйте отдельно каждый коэффицэнт как нибудь так mIJ, где I номер строки J номер столбца, или как нибудь подобно. Вам потом самому будет проще разбираться с алгоритмом.
видно что самостоятельная работа. Обычно для трёхмерных преобразований используют 4х мерные матрицы, чтобы учесть всякие масштабирования объектов.
Спасибо большое, действительно полезное использование. Я не решал таких задач, поэтому не знал. Авторам статьи надо было с этого начинать, и реализовывать не сам двусвязный список, а именно LRU кеши. Тогда было бы значительно интереснее.
К сожалению не всё так просто. Если подходить к рисованию игровых сцен спрайтами как в Doom, то игровых персонажей рисовать можно.(посчитать уменьшающий масштаб от расстояния). Но вот с отрисовкой сцены возникнут проблемы, дело в том что проективные построения не линейны, и прорисовать их с помощью gimp-item-transform-matrix не получится. Но есть хорошая новость - в гимпе есть аналогичная линейному преобразованию функция, для перспективных проекций - gimp-item-transform-perspective. Я с ней не работал, т.к. она не входила решаемую мной задачу, вернее выходила за её рамки, но в принципе проверить её работоспособность вполне себе можно.
Спасибо за комментарий, CFDG не рассматривал, просто я делал упражнение из SICP, поэтому и выбрал этот язык, а CFDG, насколько я понял возник гораздо позже. Но идея его реализовать в GIMP весьма интересная. Я подумаю, может быть может быть и его реализую.