Нука-нука, где это было?Цитата:
Сообщение от Oleg N. Cher
Вид для печати
Нука-нука, где это было?Цитата:
Сообщение от Oleg N. Cher
Да дорожи, кто ж тебе мешает-то? Как баба, ей-богу: сам придумал- сам обиделся.Цитата:
Сообщение от Oleg N. Cher
Я не обиделся. Каждый кулик своё болото хвалит. Маленькое и малоуютное для других. Особенно на первый взгляд.
А чего на мое болото наехал? Показалось, что в твое плюнул? Ну так приведи пример где я говорил что-то плохое о ZXDev.Цитата:
Сообщение от Oleg N. Cher
Еще раз спрашиваю: приведи пример моей критики ZXDev.Цитата:
Сообщение от Oleg N. Cher
Для альтернативно одаренных: не критики Oberon, процедурного подхода а именно продукта.
И этот человек мне пеняет, что я невнимательно читаю...Цитата:
Сообщение от Oleg N. Cher
http://zx-pk.ru/showpost.php?p=717891&postcount=59
Ты как-то стереотипно мыслишь. По-твоему, если ты уколол человека иголкой, то он должен отомстить тебе непременно тем же способом? А я тебя уверяю - вовсе нет, можно и любым другим удобным.Цитата:
Сообщение от Vitamin
Олег, а все-же скажи, почему нельзя причесать исходники zxdev и оформить 1 раз корректное разбиение файлов по ф-циям и нормальные хедеры и не делать это каждый раз при каждой компиляции да еще и с диким оверхедом?
Ну здрасьте, опять двадцать пять. А ты ответь что значит в твоём понимании "нормальные хедеры" и "с диким оверхедом"?
Второй вопрос. Почему ты всё ещё не запускал ZXDev? Барьер вхождения?
Поясняю. Раз ZXDev - это Оберон-среда, то логично делать всё в Оберон-стиле. Писать библиотеки и модули на Обероне. Модуль на Обероне != одна сишная функция, помещённая в один маленький текстовый файл.
Мы хотим писать на Обероне, но вынуждены по некоторым причинам транслировать Оберон-исходники в Си. Поскольку у нас есть желание иметь возможность разрабатывать библиотеки и на Обероне, и на Си, мы вырабатываем единостильный подход. А ещё у нас есть желание не терять возможность использовать старые Си-компиляторы, например, Turbo C. А конкретно для Спека мы включили в дистрибутив SDCC, который навязывает нам понятие "модуль == одна функция в одном текстовом файле". А мы хотим транслировать Оберон-модули в Си и собирать их автоматически. А с одного Оберон-модуля получается такой оттранслированный сишный исходник, который не содержит в себе предпосылок для "умной линковки". Оберон-модуль - это более цельная единица, чем сишная функция, зачем-то засунутая в отдельный текстовый файл, понимаешь? И ничего с этим не поделаешь. Но это и не недостаток, я считаю.
Манечка "разрезать библиотеку на кусочки по функциям" навязывается тебе инструментарием. Я это делаю утилитой и автоматически. Ты это делаешь ручками. Какой в этом смысл, объясни? А я тебе скажу. Ты так привык, и ничего пересматривать не хочешь. Ну и бог с тобой.
P.S. Vitamin'у. Ты какой-то неадекват. То ты Absolutely agree! с тем, что программировать в ООП-стиле можно и без прямой поддержки ООП в языке, то заставляешь меня показывать тебе как это может быть устроено на Си. Я что, обязан это для тебя делать? Обязан отвечать за каждую букву всех постов, которые ты по диагонали прочёл на Оберон-форуме? Вопрос риторический, можешь не отвечать.
А как мое agree, на которое ты ссылаешься связано с данным заявлением? Журнализд-стайл?Цитата:
Сообщение от Oleg N. Cher
Хочется проверить, знает ли человек то, о чем говорит. В твоем случае- не знает.Цитата:
Сообщение от Oleg N. Cher
Другими словами, умный транслятор Оберона в C не может на выходе дать много маленьких файлов по одной функции или хотя бы файлов с cut-линиями, а дружное сообщество динамично развивающегося кросс-платформенного Оберона не собирается модифицировать транслятор для возможности сборки компакнтых программ под ретро-платформы?Цитата:
Сообщение от Oleg N. Cher
Просто сопоставил два твои высказывания и нашёл в них одни придирки и самовыпячивание.Цитата:
Сообщение от Vitamin
Но зато знает где это посмотреть. И уверен, что другие знают. Кому надо. А кому не надо - тому и не надо. И нечего ради таких напрягаться.Цитата:
Сообщение от Vitamin
---------- Post added at 22:52 ---------- Previous post was at 22:51 ----------
Alex Rider, даже чуть не так. Умный транслятор Оберона в C силами одного дружного чела, динамично развивающего оный транслятор научился давать на выходе файлы с cut-линиями, но дело оказалось мудрёным, а сборка компактных программ под ретро-платформы - мало востребованной, посему подход и не получил должного развития. Хотя всё возможно.
Это означает: не включаем в хедеры то, что там не нужно, не включаем в файлы исходного кода то что там ненужно. Не показываем конечному юзеру те ф-ции которые ему не нужны (скрываем реализацию служебных структур и частей кода).Цитата:
Сообщение от Oleg N. Cher
Я и Витамин уже 100500 раз это писали.
Я не нашел ни слова документации в репозитории как это собрать. Все бинарники находящиеся там на моем powerpc G5 не запускаются т.к. собраны под и386.Цитата:
Сообщение от Oleg N. Cher
Вопрос без которого нельзя на вот то что ты написал ответить: ты каждый раз переписываешь библиотеки которые юзаются у тебя в zxdev? в смысле они каждый раз экспортируются по-новой в С-исходники и каждый раз собираются?Цитата:
Сообщение от Oleg N. Cher
Если так то мой подход неверный. Если нет - не вижу проблемы доработать после экспорта напильником то что получилось для:
1) удобочитаемости и нормальной структурированности
2) исключению необходимости резать это все каждый раз каждую сборку.
3) скрытию системных и внутренних структур и ф-ций от конечного пользователя.
4) ускорению сборки в силу пп 2 и 3.
PS: Ответь мне, ты сам-то что пересмотрел в своих привычках за время треда?
А то, я смотрю, вместо ответа на простой вопрос ты начинаешь метать во всех подряд какашки и пытаться найти где там тебя и твой обожаемый мертвый язык так оскорбили и обидели...
Ага. Значит я, по-твоему, включаю в хедеры то, что мне не нужно и не включаю то, что нужно. Надо же. Сам понял чего сказал?Цитата:
Сообщение от Q-Master
Но вообще хедеры генерируются автоматически с обероновских интерфейсов, так что я их даже не пишу ручками. Просто некоторые иногда дополнительно редактирую.
Всё правильно, ненужное скрываем. Это есть инкапсуляция.Цитата:
Сообщение от Q-Master
Вы не сказали ничего дельного по этому вопросу. Даже язык Си не требует помещения каждой функции в отдельный исходник. Ты же напираешь на необходимость это обязательно делать. Да, с SDCC по-другому пока и не сладить, но лучше бы ты задумался над тем как лучше сформулировать feature request разработчикам SDCC.Цитата:
Сообщение от Q-Master
Ну что конкретно ты предлагаешь? И не дури мозг. Вовсе не "невключать то что ненужно включать то что нужно", а "помещать каждую функцию в отдельный файл". Ну хорошо. Будет в папке Lib не 44 файла, а 544. Легче кому от этого станет? Придётся имена всей этой тучи файлов хранить в мейк-файле (и постоянно его редактировать, дополняя новыми именами). Это что - удобно настолько, чтобы к этому стремиться? Нет, батенька. Это просто для тебя привычней. Ещё какие достоинства будут?
Угу, угу. Витамин тоже в глаза никогда не видел ни винды, ни i386, представляясь линухойдом. Пока не прокололся, приаттачив презентацию ppt.Цитата:
Сообщение от Q-Master
Не могу рассматривать такой ответ иначе как дешёвую рисовку.
Да.Цитата:
Сообщение от Q-Master
Но с некоторыми "но".
Библиотека, написанная на Обероне, собирается именно так, как ты сказал. Разрезание тоже работает, но с некоторыми ограничениями.
Поэтому исключительно для того чтобы юзать "умную линковку" используется полу-автоматическая генерация. Т.е. то, что нагенерил Ofront, ручками переносится в сишный исходник и редактируется для добавления "линий разреза". Иногда используется сишный препроцессор. Это для шика. Например, чтобы без перекомпиляции использовать разные опции работы библиотеки. С некоторыми ограничениями это можно юзать и из Оберона.
Наконец, чисто сишные библиотеки. Ну какой смысл резать их на сто кусочков? Чтобы подсластить жизнь утилите. Проклинаемый тобой оверхед - у тебя в голове, я уже писал, что авторазрезание даже на сто кусков занимает меньше секунды.
Ну и асмовые библиотеки. В сишной обёртке. Тоже нет никакого резона иметь каждую функцию в отдельном файле. Ну нету смысла в этом. Так делают, я снова повторюсь, только для того чтобы угодить плохому компилятору.
Для этого у нас есть интерфейсы. Ты давно заглядывал в промежуточный код, сгенеренный любимым FreePascal?Цитата:
Сообщение от Q-Master
Я ещё раз повторюсь. Интерфейсы генерируются автоматически. Чтобы у нас были доп. фишки (например, связанные с макропроцессором) - мы можем доработать напильником. Я так и делаю. Но не для всех библиотек, а только для некоторых.
Пользователь не пересобирает библиотек. Как правило, это делает разработчик библиотек. Даже если пользователь пересобирает библиотеку - он делает это одним нажатием кнопки. Голова не болит. Разве что батничек подправить. Но в нём нету ста имён кусков файлов исходника.Цитата:
Сообщение от Q-Master
Я повторюсь. Пользователь оперирует даже не хедерами. Интерфейсами. В них нет ничего лишнего. Но может быть много полезного, вплоть до комментариев, созданных с помощью автодокументирования (как в Javadoc).Цитата:
Сообщение от Q-Master
Т.е. из-за неприемлемости потратить полсекунды на работу утилиты разрезания ты предлагаешь вместо этого удесятерить количество файлов и усложнить процесс их сборки вынужденной необходимостью постоянно править имена в мейк-файле?Цитата:
Сообщение от Q-Master
Слушай, у меня ужасное подозрение. Это твоя идея фикс. Грамотный разработчик зрит в корень. И уж точно усмотрит более приоритетные направления разработки. А их сотни. А что предлагаешь ты? Чепуху, вобщем.
Ещё более укрепился в своём почитании библейского принципа "око за око, зуб за зуб", и знаешь, правило верное - не подводит.Цитата:
Сообщение от Q-Master
А ты сталкивался с тем, что кто-то, рьяно рвущийся дать тебе совет, не вполне понимает что именно ты делаешь? А, соответственно, и не заслуживает более достойного ответа. А другие на меня и не в обиде. За это я спокоен. И благодарен за хорошие советы. С этим всё в порядке.Цитата:
Сообщение от Q-Master
Я с этими скриптами и разбиением вожусь уже не один год. А, по-твоему, адекватный человек будет давать советы по усовершенствованию продукта, который он не то что юзает ежедневно, а вообще даже не смотрел?
Так, риторика.
Поставлю в подпись.Цитата:
Сообщение от Oleg N. Cher
Alex Rider, чтобы ты понял как хреново обстоят дела с "умной линковкой" в сишном мире, нужно сказать, что в таком развивающемся компиляторе как Tiny C (tcc) её нету вообще. И разработчики не хотят добавлять эту фичу. Вообще не считая это чем-то важным. Более того, я не уверен, что она есть даже в MINGW. По крайней мере, люди пишут об этом. http://forum.ixbt.com/post.cgi?id=print:26:42363. В качестве эксперимента предлагаю это проверить. Я проверял. Правда, на старой версии MINGW. И действительно - fdata-sections, -ffunction-sections увеличивают размер библиотеки, а ключик --gc-sections не работает должным образом. И с fdata-sections, -ffunction-sections бинарь получается ещё жирнее, чем без них. И меня это не удивляет - килобайты давно уже никто не считает.
Так что это есть серьёзная проблема сразу для целой кучки сишных компиляторов, а вовсе не для одного. И пусть Q-Maйster не лезет сюда со своей вижл студией последней версии, а витамин со своим Clang. Мимо. Я говорю про MINGW, где ключики не срабатывают. Идите туда оба и пробейте эту фичу. Потом сделайте то же самое для SDCC. Тогда я вас похвалю. Может быть.
Мне кажется, самой большой проблемой здесь есть помещение static функций в библиотеку. Т.е. они должны видеться извне для подключения их к тем функциям, которые имеют на это право, но не должны видеться для других функций.
И я, разумеется, могу повлиять на эту ситуацию только очень ограниченным образом. Думаю, такой feature request будут отпинывать ногами куда подальше. Я говорю это не голословно, ибо уже делал такие реквесты.
Так что SDCC просто поддерживает старые добрые сишные традиции. "Режьте, братцы, режьте". Исходник на кусочки. Но спасибо хоть так, могло быть вообще никак.
---------- Post added at 01:38 ---------- Previous post was at 01:28 ----------
То есть получается, Alex, что ты заставляешь (или просишь) меня делать то, что не могут (или не хотят) сделать сообщества разработчиков сишных компиляторов, состоящие из десятка и более человек. Ну и где твоя гуманность? Хоть помощь предложи для приличия.
Впрочем, а как именно ты предлагаешь сделать "умную линковку"? Просто чтобы транслятор выдавал сразу кусочки, т.е. дублировал функциональность моей утилиты-резалки? А смысл в этом какой-то есть, кроме удовлетворения эго ку-майстера? Который даже не будет пользоваться этим, ибо у него powerpc G5.
Огорчу тебя еще раз. Я не юзаю вижуал студию и не юзал ни разу в жизни. Под твоим любимым мингв стандартно юзается gcc, а не tcc чего-бы ты ни говорил. В гцц такой проблемы практически нет. Заюзай таки самую новую версию мингв и скачай новый gcc под него. Насколько я вижу это 4.8.1. Там все есть.Цитата:
Сообщение от Oleg N. Cher
А ты собери мне под debian linux для powerpc процессоров и я попробую это. То что я даже вменяемой документации по сборке этого всего не нашел это уже как-бы показывает дружественность проекта.Цитата:
Сообщение от Oleg N. Cher
PS: поскольку ты собираешь все каждый раз по-новой, то мой подход не катит. Хотя я и не очень понимаю в чем смысл пересборки и пересоздания сишных исходников каждый раз.
PPS: поскольку "дружественность" твоего восприятия любого совета просто ужасна - я не буду более тут ничего писать. надеюсь что проект с такой "поддержкой" таки выплывет.
Юзаю 4.8.1 с http://sourceforge.net/projects/mingwbuilds/ - там эта опция влияет только на размер .pdbЦитата:
Сообщение от Q-Master
Если дебужную инфу хранить в бинаре, то да, размер уменьшится.
А я не уверен, что там есть умная линковка для винды. Пробовать специально не буду, разве что когда-нибудь по какой-то оказии.Цитата:
Сообщение от Q-Master
Его нельзя собрать для линукса. Это чисто виндоуз-проект. Что касается дружественности - я не господь бог и не могу сделать всё для всех, и чтобы всем понравилось. Это невозможно по определению.Цитата:
Сообщение от Q-Master
А ты понимаешь смысл трансляции одного языка в другой?Цитата:
Сообщение от Q-Master
Какие советы и какой тон - такая и реакция. ;)Цитата:
Сообщение от Q-Master
Из здешних форумчан я благодарен Eltaron'у. Благодаря его совету в ZXDev появилась возможность передавать константные параметры внутрь функций в регистрах. И хотя такой возможности нет в SDCC - мы достигли этого с помощью препроцессора.
Ещё я благодарен Reobne. Благодаря его совету появилась возможность юзать inline-ассемблер прямо из Оберон-исходника. Причём без переделки транслятора - тоже с помощью макропроцессора.
Это хорошие советы. Твой же совет держать каждую функцию в отдельном файле - он, как бы помягче сказать, не очень. Ну да, твоя помойка будет принципиально отличаться от моей только удесятерённым количеством файлов. Причём ты даже не рискнёшь сказать, что это идеологически правильно и в духе Си. Просто сложил их так, чтобы не резать каждый раз.
Занимаясь Обероном я кое-что понял. А именно то, что проблему нужно решать в месте её возникновения. Любой другой подход будет навесным. А значит - нужно внедрять умную линковку в Си-компиляторы. Это самое правильное решение, которому не видится никакой другой разумной альтернативы. Ну будет выдавать Ofront кучу исходников. Т.е. будет делать то же самое, что и утилита. Смысл? Жизнь станет легче, что ли?
Если внедрить смартлинковку в Си-компилятор по каким-то причинам невозможно или затруднительно - иначе как утилитой, которая переформатирует исходник и приведёт его в вид, потребный для линковки, вопроса не решить. Да, моя утилита примитивна. Но что же делать? Давайте напишем вместе более умную утилиту. Давайте сформируем feature request в сообщество SDCC. Я не возражаю. Давайте что-нибудь сделаем в этом направлении.