DNF будет переписан на языке C

Причем конкретно на той странице не было ничего про (require gregor/time).

На той странице показаны +hours, -hours и примеры их применения.

(-hours (datetime 1970) 12)

datetime в основном модуле (вверху страницы описания нет require).

(+hours (time 22) 4)

time в отдельном модуле — написан вверху страницы описания.

datetime в основном модуле (вверху страницы описания нет require).
time в отдельном модуле — написан вверху страницы описания.

Да хватит уже, я и с первого раза понял, просто объяснил почему сразу не нашел почему не работает.

Почти так же смешно, как «все компиляторы Си для микрконтроллеров написаны на ассемблере». Уникальный у них может быть кодогенератор, но это только часть компилятора.

Тебе никто такого не писал, тебе написали, что, при создании (кросс)тулчейна под новую процессорную архитектуру, делают так:

• пишут асемблер, (лучше это делать на С/C++, см. дальше);
• пишут/адаптируют компилятор C/C++, который в итоге может генерировать этот самый ассемблер с вызовами libc, которой еще нет;
• пишут/адаптируют линковщик+binutils;
• пишут libc, там будет МНОГО кода на ассемблере, т.к. в целевой архитектуре может элементарно не быть аппаратной поддержки многих даже базовых типов Си (long, float, double, etc.),
• интегрируют это все.

Тебе никто такого не писал

Неужели?

Iron_Bug> на ассемблере нормально написаны многие сишные компиляторы
tailgunner> Назови Топ5
Iron_Bug> все компиляторы для микроконтроллеров. любые их реализации

тебе написали, что, при создании (кросс)тулчейна под новую процессорную архитектуру, делают так:

Я знаю, как делают.

Всё это позволяет вообще не беспокоиться об именах.

Спасибо, теперь понятно. Выглядит действительно удобно.

кроме С/C++/D/assembler , остальное сделано для лени программистов.

А ничего, что из перечисленного каждый пункт повышает «уровень лени», начиная от асемблера? И почему именно на D надо остановиться?

ЛОР, я тебя не узнаю. 12-я страница, а вы всё ещё обсуждаете нелисповые языки программирования и сравниваете пакманы с апт-гетами вместо того, чтобы смотреть в светлое будущее православного Guix.

Питон это интерпретируемый язык, как Java. Исполнительная среда оного — виртуальная махина машина. То есть, без установленного пакета «Питон» пакетный менеджер просто не запустится: «рыба должна же где-то плавать, а среды-то нет».

Для Си среда не нужна - это компилируемый язык.

если ты делаешь новую архитектуру, то тебе придётся делать и ассемблер, и компилятор. и это будет точно не паскаль.

C Iron Bug несогласен. Незнаю, как Лазарус и Дельфи, но Виртовский Оберон/Компонентный Паскаль превосходное средство для системного программирования. Но приходится констатировать, что в мире Линукса, БЗды, и «бытовых» микроконтроллеров господствует Си.

Iron_Bug> на ассемблере нормально написаны многие сишные компиляторы tailgunner> Назови Топ5 Iron_Bug> все компиляторы для микроконтроллеров. любые их реализации

Ага, ну то есть тебе сначала сказали, что для написания кросс-компилятора под микроконтроллерные архитектуры нужен ассемблер под эти самые архитектуры, потом тебе объяснили, почему он нужен, но ты нераспарсил и притворился троллем?

Или ты не в курсе, что тот же gcc бесполезен без libgcc, которая пишется на ассемблере целевой архитектуры под неё же?

Ясно@Понятно

Не дождешся. Лишподети срочно переквалифицировались в #rust#nogc#memorysafety-хипстеров!

Ага, ну то есть тебе сначала сказали, что для написания кросс-компилятора под микроконтроллерные архитектуры нужен ассемблер

Я привел линк на сообщения, хронология там очевидна.

но ты нераспарсил

Если ты не заметил, я переспросил. Ответ на это был вполне однозначный, хотя и удивительный.

Ясно@Понятно

Вот и прекрасно.

Iron_Bug ну-ну, полноте. на ассемблере нормально написаны многие сишные компиляторы. паскаль ненужен. он не курица и не яйцо. он - давно вымерший динозавр. про порядок сборки - рекомендую пару раз собрать LFS. tailgunner

Назови Топ5

Iron_Bug

все компиляторы для микроконтроллеров. любые их реализации. там не пять, там несколько сотен, наверное, можно накопать при желании. первое, что делает разработчик железяки - пишет ассемблер. потом пишет компилятор си. или адаптирует gcc под свои коды и вызовы. но так или иначе это смесь ассемблера и си.

То есть суть претензии в том, что тебе не привели список кросс-компиляторов, которые написаны с использованием асма целевых архитектур?

Или ты думал, что Iron_Bug имеет в виду, что компилятор Си для AVR должен быть написан на асме AVR?

Давай ты просто скажешь, как ты понял фразу «на ассемблере нормально написаны многие сишные компиляторы». Не объясняй мне ничего о том, как всё есть на самом деле - я знаю об этом не хуже тебя, не спрашивай меня о том, в чем мои претензии - у меня их нет. Просто скажи - как ты понял процитированную фразу.

libgcc, которая пишется на ассемблере целевой архитектуры

WAT?

https://github.com/gcc-mirror/gcc/tree/master/libgcc

Я понял, что Iron_Bug слажала и вместо:

«с использованием ассемблера целевых архитектур написано много компиляторов»

написала «на ассемблере нормально написаны многие сишные компиляторы»

а ты вместо уточняющего вопроса об исчерпывающем или хотя бы более полном списке использованных языков начал придираться к словам, и понеслось...

Добра тебе.

WAT?

https://github.com/gcc-mirror/gcc/blob/master/libgcc/soft-fp/soft-fp.h

#ifdef _LIBC
# include <sfp-machine.h>
#elif defined __KERNEL__
/* The Linux kernel uses asm/ names for architecture-specific
   files.  */
# include <asm/sfp-machine.h>
#else
# include "sfp-machine.h"
#endif

«с использованием ассемблера целевых архитектур написано много компиляторов»

Это такая же бредовая фраза, как и оригинал. Кросс-компиляторы не пишутся с использованием целевого ассемблера - с его использованием пишутся целевые библиотеки (и, естественно, целевой ассемблер может эмитироваться компилятором в качестве объектного кода) // К.О.

начал придираться к словам, и понеслось...

Ага, надо было истолковать слова оппонента так, чтобы они подходили к картине мира, которая у меня сложилась. Замечательный подход - похоже, ты его практикуешь.

И чо? Почти вся библиотека на С, а использование asm/sfp-machine.h опционально.

WAT?

http://lxr.free-electrons.com/source/arch/powerpc/include/asm/sfp-machine.h

Ты не знаком с директивами препроцессора? Оно соберется и без хедеров ядра.

Колобок, ты будто бы святое писание тут интерпретируешь. Всё было предельно конкретно сказано. Царица сишки зарапортовалась, её рассуждения на тему разработки компиляторов слишком наивны и поверхностны. Ну видно же, что человек в теме ни в зуб ногой, где-то что-то слышал, но подает себя как мегапрофи. Ламерство как оно есть.

А теперь под AVR: https://android.googlesource.com/toolchain/gcc/ /3f73d6ef90458b45bbbb33ef4c2b...

Где твой Б-г теперь?

Тоньше надо...

А теперь под AVR: https://android.googlesource.com/toolchain/gcc/ /3f73d6ef90458b45bbbb33ef4c2b...
Где твой Б-г теперь?

Офигеть, ты нашел файл на ассемблере в сишной библиотеке :)

Тоньше надо...

Черт :( Ну ладно, но было трудно не придраться к фразе про «пишется на ассемблере».

Тут мякотка в том, что без этого файла нельзя будет работать на AVR, во всяком случае без переписывания бэкэнда GCC.

Это такая же бредовая фраза, как и оригинал.

Но уже гораздо ближе к истине.

Кросс-компиляторы не пишутся с использованием целевого ассемблера - с его использованием пишутся целевые библиотеки (и, естественно, целевой ассемблер может эмитироваться компилятором в качестве объектного кода)

Это понятно, но в данном случае:

GCC provides a low-level runtime library, libgcc.a or libgcc_s.so.1 on some platforms. GCC generates calls to routines in this library automatically, whenever it needs to perform some operation that is too complicated to emit inline code for.

Это не просто реализация printf какого-нибудь, это реализация базовых вещей, таких, как операторы +-*/%...

То есть, без printf и memcpy из libc можно обойтись, а без кода из libgcc, — нет, поэтому libgcc.a, — это неотъемлемая часть gcc-avr, например, создатели gcc это сами признают.

Всем чмоки в этом чате!

Намекает, что в RedHat сидят заскорузлые деды, которые до сих пор изображают Си++ вручную.

Вы тоже видели эти «структуры» со ссылками на функции внутри?

Что только не придумают чтобы на с++ не писать =)))

«структуры» со ссылками на функции внутри?

Смех-то какой!

если аппаратной поддержки нет, то как это дело реализуется программно?

вот допустим конпеляю я во фряхе на своем старющем x86_64 под новенький распбэри (arm v7 neon) как такое происходит, в х86_64 же нет армовских инструкций?

Лишподети срочно переквалифицировались в #rust#nogc#memorysafety-хипстеров!

Сомневаюсь, что есть заметное пересечение.

Это очень сильное колдунство.

Православный Guix мёртв, как и само православие.

«если ты освоил си, то питон точно освоишь. а вот обратное неверно»

)))))))) Знаю личностей, которые осилили процедурный кодинг на сцях, но ООП в их извилинах не приживаеццо. Судя по-всему, ввиду более простой парадигмы, Цэ требует меньше извилин ;)

Для Си среда не нужна - это компилируемый язык.

Для хелловорда, а что-то посложнее обычно тянет кучу либ с зависимостями. В сях даже нормальных 64 битных целочисленных переменных из коробки нету, всё надо подключать вручную - ну прямо 8-16 битный компилятор на стероидах.

В сях даже нормальных 64 битных целочисленных переменных из коробки нету

Щито?

вознёй с адресами и байтиками

Высокоуровневое программирование - это возня с объектами.

кто перекладывает байтики, за пару дней питон освоит, если ему приспичит. а вот наоборот, увы, не получится.

А что, для написания чего то на питоне целевые API изучать не надо?

Для хелловорда, а что-то посложнее обычно тянет кучу либ с зависимостями. В сях даже нормальных 64 битных целочисленных переменных из коробки нету, всё надо подключать вручную - ну прямо 8-16 битный компилятор на стероидах.

Ну если грамотно кодировать, то некоторые возможости можно выразить средствими языка. К тому же статическую компиляцию никто не отменял. Опять же при грамотном кодировании менеджер пакетов не должен тянуть кучу либ. Менеджер пакетов — это не сложный объект.

Darcs торомозной by design, народ тут не причём.
Но ему уже быструю альтернативу пилят: https://pijul.org/

mersinvald

Сколько я подобных обещаний слышал про portage — не счесть

У портежей как минимум две альтернативные реализации уже есть.

Darcs торомозной by design, народ тут не причём.

Не припомню, чтобы Дэвид это утверждал.

Что только не придумают чтобы на с++ не писать

И тем не менее эти «структуры» могут в сообщения, сигналы и нормальную интроспекцию из коробки. В отличие от.

У портежей как минимум две альтернативные реализации уже есть

И обе говно

К тому же статическую компиляцию никто не отменял.

В линуксах это не модно. Да и модульность линукса как-то больше настраивается на выкидывание функционала, нежели на его добавление различными средствами. Например, статически слинкованными компонентами. Если сравнивать модульность винды и линукса, то в первой необходимые компоненты обычно добавляются, а во втором - вычитаются лишние из некоего разрешённого дистрового максимума, посему, на каждый чих нужно менять максимум А на максимум Б, то есть обновлять всю систему ради какой-то мелочи. Пришло обновление программе на плюсах (например, клиенту десуры) требующее суперпупер-замечательный линковщик, и звиздец, меняй версию дистра, потому что вычитанием из имеющегося максимума такая проблема не лечится.

Пакман умеет поиск пакетов в репах по пути к файлу, по маскам, по pkgconfig(glib-2.0)?

По маске - да, последний поиск - хз, что такое (по файлу? Если да, то отдельной тулзой предоставляется). Репозитории на разделены на 100500 ненужных сущностей.

А проверку пакетов на конфликты перед началом установки?

Вообще-то, да.

Я уж молчу, что он совсем недавно научился проверке по цифровой подписи.

Пн фев 29 11:11:20 MSK 2016

4.0.0 2011-10-13

// мимокрокодил

git - это тот, который на 50% написан на shell, да?

pkgcore (свежий) вроде пытается быть вменяемой заменой.

Есть примеры из реального мира где код написанный на С поддерживается десятилетиями и широко используется. Ни шарпы ни хаскели-шмаскели рядом не валялись. А про Васик вы знатно пошутили, оценил.

Ну так всё верно, сначала написали прототип на питоне, обкатали в продакшоне, посмотрели что как, а теперь выкидывают и переписывают на си.

Всё верно делают, короче.

Напишут на Си. Обкатают в продакшене. А потом начнут переделывать на C++ без исключений как разработчики gcc.

Нормальное развитие.

Одна проблемя шаг от программы на python к программе Си очень сложный.

Использование Python приводит к неудобной для Си архитектуре. По этому его (шаг) разбили на два. Если заранее знаешь, что будет переписано на Си, то лучше поискать более другой язык.

long long int i; // ISO/IEC 9899:1999 64 bit signed integer;

unsigned long long int u; // ISO/IEC 9899:1999 64 bit unsigned integer;

#include <stdint.h>

int64_t i64; // ISO/IEC 9899:1999 64 bit signed integer;

uint64_t u64; // ISO/IEC 9899:1999 64 bit unsigned integer;

Кефиродинамика - синоним олигофрении.