caxapa.ru :: Пиплы, смотрите, что я нарыл!!!! ->(в буке вычитал). PDF::Writer for Ruby. Пакет программ, который позволяет "напрограммировать" документ в PDF!!! Без ДЖАВЫ!!! Это то, о чем я давно мечтал - относительно простой программно управляемый способ создания

Evgeny_CD, Архитектор (16.12.2007 22:21, просмотров: 173) ответил Evgeny_CD на Буку по Ruby купил. Интересное чтиво! ->

Пиплы, смотрите, что я нарыл!!!! ->(в буке вычитал). PDF::Writer for Ruby. Пакет программ, который позволяет "напрограммировать" документ в PDF!!! Без ДЖАВЫ!!! Это то, о чем я давно мечтал - относительно простой программно управляемый способ создания Без монстров класса OpenOffice, LaTeX. Типа редактора Q (если помнит кто такой времен M$ DOS). Для пЫтона что-то похожее есть? Жаль, что с unicode у этого божественного пакета, похоже, засада.

Ответить

- юникод -- это ахиллесова пята Руби. Гы-гы, добро пожаловать в реальный мир. Для питона есть конечно PyPdf от ReportLab. - bialix(16.12.2007 22:33)
  - Вау! Вот оно! Тоже самое можно и на пЫтоне! -> - Evgeny_CD(16.12.2007 22:50, ссылка)
    - вы смешной. для питона есть столько либ и рапперов вокруг других полезных либ, что меня больше удивляет факт, когда я не могу чего-то найти, чем наоборот. - bialix(16.12.2007 22:57, ссылка)
      - Ну это тоже парадоксы познания. :) Размышляя о системах написания документации, вкуривая (и чертыхаясь) книжки по LaTeX, я что-то понял в мире документации. До этого, я не знал, как может выглядеть то, что я хочу. :) Потом в башке выстроилась Evgeny_CD(297 знак., 16.12.2007 23:05)
        
        Господи, да что такого с ООП нотацией? То, что func(&obj, param) меняется на obj.func(param) ? Или то, что классы могут надстраиваться один над другим? Или перегрузка операторов? Виртуальные (вызываемые через таблицу указателей) функции? =AlexD=(130 знак., 17.12.2007 08:52)
        
        Дело не в нотации, а в методологии. В башке выстраивалась именно она. После этого можно и осознанию нотаций переходить :) - Evgeny_CD(17.12.2007 13:47)
        
        В том и беда, что методология в большинстве книг по Си++ хромает на обе ноги. Отсюда и невразумительный код во многих проектах, помноженный на сложность самого языка :-( - =AlexD=(17.12.2007 14:08)
        
        а оправданна ли она -- эта сложность? вот в чем вопрос. - bialix_(17.12.2007 14:50)
        
        Отож. Я этих буков прочитал некоторое количество. Пока буквально несколько дней назад у меня в башке что-то не замкнуло - для меня они были тарабарщиной (именно посему мне интуитивно и не нравился С++ - неизведанное пугает). Теперь перешел на другой Evgeny_CD(11 знак., 17.12.2007 14:15)
        
        Весьма забавный и поучительный сайт -> - =AlexD=(17.12.2007 14:21, ссылка)
        
        must read!!! -> - Evgeny_CD(17.12.2007 15:05, ссылка)
        
        Особенно понравилось - Tумблер(17.12.2007 21:15, ссылка)
        
        на 100% сотвествует моим мыслям! "Американцы пишут в инструкциях к микроволновым печам «В печи нельзя сушить кошку». Я бы предложил на всех книгах по C++ писать «В C++ нельзя программировать на C». Большинство программистов, считающих себя «программистам Evgeny_CD(61 знак., 17.12.2007 15:01)
        
        Unix и Linux — вообще отдельная песня. Заставлять пользователя собственноручно скомпилировать программу перед ее использованием — верх бескультурия и безответственности. Операционная система с таким подходом не может быть ориентирована на нормального Ruslan(133 знак., 17.12.2007 15:14)
        
        В самой компиляции ничего неразумного нет. Наоборот, это грамотный способ выжать все именно из вашей системы. Но!!! Этот процесс должен быть 100% одинаковый везде (как расположение кнопок на клаве)и должен быть полностью автоматическим (make файл юзер и Evgeny_CD(17 знак., 17.12.2007 15:55)
        
        Но для того, чтобы это работало, как ни смешно, надо иметь некий центр в виде M$. Чтобы все системные либы выходили из одного центра, вместе с исходниками. Чтобы не было бардака с 1001 несовместимым дистрибутивом. Вот тогда будет ляпота. Но только без Evgeny_CD(19 знак., 19.12.2007 14:34)
        
        Линукс давно ставил? "Откинтесь на спинку кресла..." - Vit(17.12.2007 15:22)
        
        как бы они уже от этого давно отошли. линуксовые юзеры уже давно больше полагаются на готовые пакеты (по виндузному -- это значит на инсталляторы). для меня самого это было открытием годик назад. - bialix_(17.12.2007 15:20)
        
        Пакет, который в том числе проводит самокомпиляцию - это грамотно. - Evgeny_CD(17.12.2007 15:56)
        
        Есть и бинарные и сорцовые пакеты. - Vit(17.12.2007 16:17)
        
        Сорцовые - сильно интересно понять, как у них там все устроено. Когда вся ОСь крутится вокруг некоей суперсистемы на пЫтоне (Gentoo ->) - это понятно. А иначе - слабопонятно. - Evgeny_CD(17.12.2007 16:28, ссылка)
        
        Есть пакеты, а есть порты. Я их не особенно разделяю, но формально это разные вещи. - Vit(17.12.2007 16:47)
        
        Почитайте о LFS - Ruslan(17.12.2007 16:33)
        
        Занятный проект. Давно хотелось бы сним разобраться, да руки не доходят/ -> - Evgeny_CD(17.12.2007 16:36, ссылка)
        
        Иерархия классов - одна из самых сильных сторон ООП (для меня в текущий момент понимания). Это то, чего мне сильно не хватает в plain C. - Evgeny_CD(17.12.2007 11:09)
        
        Впрочем, иерархия пространств имён - тоже кульно. - =AlexD=(17.12.2007 12:18)
        
        иерархия? хотя бы просто пространства имен использовать. а то в плюсах они есть, но их как-то вяло пользуют. все стараются по сишной привычке все скопом свалить из заголовка в си-код. - bialix_(17.12.2007 12:31)
        
        Дык класс и создаёт пространство имён внутри себя. Что ужЕ хорошо. Ну а издержки похожести Си и Си++ сам автор плюсов предвидел. - =AlexD=(17.12.2007 12:39)
        
        только внутри класса почемуто никто явно пространства имен не пользует. поэтому оно как бы есть и как бы нема. вместо того, чтобы явно писать this->var, придумывают всякие нотации типа m_var. bialix_(263 знак., 17.12.2007 14:50)
        
        Я не всегда понимаю, о чём ты говоришь, и это тот самый случай :-). this - это указатель на экземпляр, который скрытно передаётся в методы класса, и заменить его ничем низя. Разве что дублировать в параметрах методов, что будет уже маразмом. - =AlexD=(17.12.2007 15:46)
        
        Вся фишка в том, что в Питоне этот указатель передается явно. И его нужно все время использовать. В плюсах же ты внутри тела метода волен использовать его или нет. Это не есть гуд. Это нарушение идеи пространства имен. Получаются какие-то магические bialix_(83 знак., 17.12.2007 16:41)
        
        Ну точно, на разных языках говорим :-). Я не понимаю проблемы , о которой ты говоришь. Честно. Возможно это какие-то чисто питоновские боли. Или кривизна извилин у меня не та. Не знаю. - =AlexD=(18.12.2007 10:08)
        
        если ты ее не понимаешь, значит ты с ней не сталкивался. возможно, это хорошо для тебя. я не хочу убеждать тебя, что ложка существует. это будет просто напрасная трата времени для нас обоих. По ссылке сравнение объектной модели двух языков, если интересно - bialix_(18.12.2007 15:55, ссылка)
        
        Я вижу отличия, но я не вижу ПРОБЛЕМЫ. =AlexD=(1026 знак., 19.12.2007 08:19)
        
        ложки не существует. - bialix_(19.12.2007 12:49)
        
        Видишь ли, абстрактные разговоры в стиле "ну это все знают" не канают. Я готов поменять свою точку зрения, если будет приведён пример кода, который демонстрирует твою правоту. Иначе это всего лишь слабо обоснованное твоё личное предубеждение. - =AlexD=(19.12.2007 14:01)
        
        видишь ли, поскольку я на плюсах давно не пишу, то и примеров под руками у меня нет. поэтому -- ты безусловно прав-прав-прав. А я чушь спорол. на этом и завершим этот бесполезный треп. - bialix(19.12.2007 20:06, ссылка)
        
        Непонятно, в чем именно - нарушение ? Tумблер(377 знак., 17.12.2007 19:34)
        
        В том то вся жопа и есть. Т.е. если даже сильно продвинутый чувак читает буку по С++, он быстро охренеет от количества фич, что-то поймет, на остальное забьет болт, и как-то будет программить. ВНАЧАЛЕ ему надо в самом обобщенном виде объяснить методолгию Evgeny_CD(161 знак., 17.12.2007 12:35)
        
        Любая иерархия - это способ не сойти с ума и добиться результата в более менее сложном проекте. В голове любого продвинутого человека она есть. Вопрос в том, чтобы с минимальными издержками перенести ее в тулчейн. - Evgeny_CD(17.12.2007 12:20)
        
        О да, приведение типов указателей от больших структур к более мелким подструктурам, полностью контролируемое, надёжное, и скрытое от глаз - это весчь. Сам пользую с удовольствием. - =AlexD=(17.12.2007 12:16)
        
        +1 - Evgeny_CD(17.12.2007 12:21)
        
        +1. ООП можно на чём угодно делать, даже на asm. Чем ниже, тем бОльший уровень контроля со стороны программиста, за счёт усложнения кода. - VVB(17.12.2007 09:00)
        
        ООП состоит из 1) стиля мышления 2) поддержки технологии тулчейном. Лично для меня определяющим является именно стиль мышления, глубинное понимание сути. Я полность согласен, что при наличии хорошего тулчейна писать в ООП можно и на asm. Сила Evgeny_CD(251 знак., 17.12.2007 11:06)

Средства и методы разработки