Varianta nastavit core_pattern v /proc/sys je az to posledni co bych udelal.

Tohle asi neni spravny misto, ale treba ma nekdo zkusenost ... podelanej systemd ... jak se da vycistit systemd-journal od starych coredumpu? A taky neda se nejak systemd donutit aby mi dump hazel rovnou do aktualniho adresare a ja nemusel furt dokola psat coredumpctl .. smeruju otazku hlavne na vyvojare z redhatu,. pac tam uz systemd jede ne, alespon fedora urcite? :)

WILD_A: no, jde o interface nad dynamickými objekty v čistém C, kdy voláš:
(objekt->interface->metoda *)(objekt, parametry)
jde s tím dělat různé srandičky, jako polymorfismus mezi objekty se stejným typem interfacu. v C ale narazíš na to, že nemůžeš přetížit aritmetické operátory, apod. na druhou stranu, různá podivná chování při např. matematickými operacemi mezi čísly a stringem jsou nejčastější příčiny divných překvapení ve většině dynamicky typovaných skriptovacích jazyků. takže nevím, jestli se o soutěže o ještě větší zmatení zapojovat, a neponechat prostě matematické operátory primitivním číselným typům a nepracovat s objekty zásadně jinak)

(stejně mám vymyšlené makro, které to, co jsem popsal výše, zvládne expandovat bez "double evaluation" problému, kterým C preprocesor trpí... takže tím bude možné zavolat metodu objektu vráceného jinou metodou... samozřejmě, hezké to není, ale ani vygenerovaný C kód by to stejně moc jinak dělat nemohl)

např. call(metoda2, call(metoda1, objekt, parametry), parametry) - za předpokladu, že oproti tomu, co je zvykem v jiných objektových jazycích, je tam pořadí typu "metoda , objekt" místo "objekt.metoda" ... ale to je právě v duchu C, kde se struktury předávají jako parametry funkcím.

jen nevím, jestli tomu makru říkat "call()" nebo stručněji "go()" - logické je imho call, protože to není žádné goto (JMP) ale klasické volání funkce s returnem.

no ale dokud nereleasnu něco použitelného, tak jsem na tom trochu jako Rossi s tou studenou funkcí :-) každopádně ten pocit, že v C "vím, co vygenerovaný kód přesně dělá" (min. teda v paměti) je hrozně návykový a člověku se nechce to opouštět, když to jednou zná.

WILD_A: tj staci lex/yacc a vyrabet clang AST a je to v podstate hotovy.

XCHAOS: pokud bys vzal ten clang, libtooling nebo jak se jmenuje ta knihovna a vyrabel to AST parsovanim vlastniho jazyka a pak jen vypliv C kod tak by to mohlo vyhovovat ne? Nevim jak ten C kod teda vypada, ale rekl bych, ze by to mohlo byt docela srozumitelny, je to preci jen furt C.

Jinak naprosto šokující je pro mě tenhle způsob zneužití preprocessoru:
99 Bottles of Beer | Language C/C++ Preprocessor
http://www.99-bottles-of-beer.net/language-c-c++-preprocessor-996.html
já sám se naučil s preprocesorem pár triků (dejme tomu žonglovat s proměnným počtem míčků a vybrat z nich vždy ten první řadě). tenhle člověk ale umí vytáhnout z klobouku slona (s využitím 8slonů, v průběhu procesu)

DANIELSOFT: jéééé :-)
(jak jinak by taky šlo přeložit http://www.99-bottles-of-beer.net/language-c-c++-preprocessor-115.html ... )

DANIELSOFT: a teďka ještě vidím v man gcc

-E Stop after the preprocessing stage; do not run the compiler proper. The output is in the form of preprocessed source code, which
is sent to the standard output.

Input files which don’t require preprocessing are ignored.

já popravdě pořád ještě bojuju s pokušením místo generování C kódu vymyslet nějakou sadu C99 maker a funkcí a typedefů, která mi umožní psát pro mě příjemný kód, který se přímo přeloží jako C zdroják :-) ale pohybuju se s tím dost v kruhu, přiznám se - když člověk jednou přičichne k jednoduchosti pythonu, tak pro něj C začne být najednou pracné :)

(jinak parserů textu jsem v životě napsal už několik, a nepokládám to za extra složité - ostatně kontextové gramatiky a zásobníkové automaty jsou jedna z věcí, ze kterých jsem na VŠ zrovna nepropadl ...a může být pro mě jednodušší nějaký vlastní napsat, než se učit nějaký cizí... jde v podstatě jen o to, aby se tam nemuselo volání metody objektu "číselná konstanta" psát 0..něco nebo (0).něco - jako v Javě - protože 0.něco je chybný zápis plovoucí desetinné čárky :-))

jedna z věcí, na kterých trvám, je ale rozhodně to, aby pro mě vygenerovaný C mezi-kód byl srozumitelný (ať už ho vygeneruju parserem, nebo makry)

BTW, lze zavolat gcc v režimu "pouze C preprocesor"? to by mi pro debugování čehosi, v čem se vrtám, docela dost pomohlo .-)

ANT_39: Myslel jsem si to, nikdy jsem na to totiz nenarazil.
V tomhle je ten clang dobrej, prace s AST je tam snadna.

WILD_A: Ne, GCC generovat C neumi.

XCHAOS: Pokud chces jen generovat C kod z neceho jinyho tak bych na to sel mozna pres clang, sice je to c++ ale celkem smysluplny a clang AST je masivni a da se v nem vyjadrit spousta veci a navic umi plivat z AST zase zpet C. (Coz u gcc nevim jestli jde). Ja clang pouzil jen na statickou analyzu teda, ale prislo mi to snadny a jasny.

ANT_39: to jsem neznal, dík...
Simplified Wrapper and Interface Generator
http://www.swig.org/

ANT_39: Jezis, to tam nemaj ani v pdf... tak latex :-)

XCHAOS: Jeste me napada, jestli by v tomhle ohledu neumel pomoct swig. Napsal bys backend pro tu svou notaci a nechal to vygenerovat C bindingy...? Hmm, nevim, ale mozna to stoji za podrobnejsi pruzkum.

WILD_A: tak gcc frontend by me zajmal.. ja mam vymyslenej dynamicky typovanej objektovej model pro cisty C (ne C++), a kdyby takovy kod slo generovat z nejaky lidsky syntaxe (typu Python), tak si myslim, ze by to bylo docela zajimavy... no ale mam ted rozpracovanych veci furu, takze tohle nema prioritu.

ANT_39: Brno mam rad, ale rodinu tam tedko z prahy neprestehuju, bohuzel ...
gcc je peknej mazec, zkousel jsem psat front end (jen ze zvedavosti) a ta hora maker moc srozumitelna nebyla, to je pravda, ale jinak vetsina veci co jsem videl byla v normalni GNU C coz se dobre da.
U C++ sablony nevadej pokud se to neprehani, jako treba v boostu, je to mnohdy elegatni reseni, ale aby se chybovy hlaseni compileru neveslo na 2-3 radky protoze se rozepsala nejaka sablona s kryptickym textem, to mi prijde uz trochu moc. Vzdyt i to LLVM se docela da a ze to je nabobtnalej projekt.