JANFROG: já teda fakt programuju radši po překapávanym kafi, jenže je fakt, že jsem toho poslední dobou moc nenaprogramoval (zhruba od doby, kdy jsem se odnaučil to kafe sladit)

jinak samozřejmě... každý řešíme problémy na jiném levelu - část toho, na co si stěžuješ, podle mě problém není (délky indentifikátorů, apod. - s tím jsem se fakt už léta nesetkal), část z toho je zřejmě problém vyřešit a pokud to umíte a někdo vám za to platí, no tak proč ne... jen tak dál.

XCHAOS:
FLEGMA: Otazka zni jinak - lze vybec programovat bez zeleneho caje? :-)

Vratim se k myslence generovani C kodu z nejakeho vyssiho. Uz par let pracuji s jedniim takovym generatorem (vyvoj toho generatoru) co preklada vyssi jazyk do C. Vysledny kod neni ani citelny ani extra rychly. Po zkusenostech co mame ted vime, ze dalsi generace tohoto nastroje bude generovat rovnou object file krom pripadu, kdy to opravdu jinak nejde (inline C v kodu ve vyssim jazyce) - a seriozne zvazujeme i moznost proste inline C nepodporovat, byt to je dle me jedna z killing features.

Problemy jsou v tom:
- ze kazdej prekladac ma jiny nazor na to, co jeden zdrojak znamena (1000+1 ifdefu v generovanem kodu),
- kazdy prekladac v kazde verzi ma mirne jiny frame layout (pro nas podstatne, pracujeme s tim).
- kazdy prekladac v kazde verzi ma jine bugy (znamena generuje v jistych pripadech invalidni kod).
- kazdy prekladac ma jine, dost male, interni limity na delky identifikatoru, stringovych literalu, identifkatoru maker apod.

Vysledny kod je stejne o neco pomalejsi, nez kdyz za behu vygenerujeme machine code a pustime.

Cili generovani C z vyssiho jazyka je snadne na zacatku a velmi limitujici na konci. Uz bych do toho nikdy nesel a kdyz ano, tak jen a pouze jako bootstrap mechanismus.

tento sýr má obávám se poněkud prošlé datum doporučené spotřeby :-)
Madrigal Database Documentation - C Language API
http://hawk.iszf.irk.ru/madrigal/madC.html

např.
C API
http://faircom.com/ace/ace_api_ctdb_t.php
The C API provides the function calls without object-oriented schema.

FLEGMA: tak já nemyslím, že je to úplně offtopic... spíš to ale souvisí s nočním programováním, kdy prostě potřebuješ zůstat vzhůru a ta kreativita souvisí s tím, že všude kolem noc a ticho, a celkově člověk děla v takovým jakoby transu. jenže do toho už se nějak nedokážu dostat, tak snadno jako dřív, takže ztratil půvab i ten kofein.

FLEGMA: to vím že existuje. já se v podstatě ptal na "cdbc" :-)

XCHAOS: Po zelenym caji se programuje vyborne - Sencha, Olong nebo Vietnamskej standard jsou provereny speedy. sry za OT

XCHAOS: Tos netrefil, java ma pro pristup k db univerzalni api, jmenuje se JDBC a je to wrapper nativniho db driveru, takze rychlost srovnatelna s C/C++.

JACHYMKO: bohužel, sql za chodu lepí poměrně hodně idiotů - v podstatě všechny existují freem CMS systémy jsou ubastelné v PHP a lepí MySQL dotazy za chodu, a hosting těhle bastlů je mimochodem multi-milionový business... co hosting, ale i jejich hloupé manageování... takže v podstatě to, o co se snažím, je přinést trochu blyštivější korálky na trh, kde zatím směna probíhá čistě pomocí leopardních kůží a pazourkových hrotů k šípům.

(kecám, po zeleným čaji se blbě programuje)

REDGUY: no... zrychlení... já jsem hodně "slow design" člověk. já netvrdím, že to nutně dělám kvůli rychlosti... ale tak nějak bych chtěl programovat enviroment friendly... zelený čaj místo předávkování Javou :-)

REDGUY: v podstatě, dá se říct... ano. šlo mi o oboje. přístup k existující databázi pomocí pre-compilovaných SQL dotazů by mi přišel... robustnější? no a SQL-like přístup k paměti mě přijde... no prostě pohodlný, jak to jinak nazvat? v SQL to prostě člověku začne přemýšlet samo.

Hele, XChaosi, at se bavime konkretne. Napis specifickej priklad, kde si myslis ze tvuj pristup by prinesl nejake vyznamne zrychleni.

JACHYMKO: v podstatě celý nápad je o tom, jestli by místo runtime interpretace SQL dotazu nešla dělat jeho pre-kompilace (minimálně by pre-kompiler mohl zabránit runtime chybám, které při lepení SQL query za chodu stejně vždy vznikají)

je to úplně stejná logika, jako že zdroják programu můžeš buď interpretovat nebo kompilovat

XCHAOS: Coze? Takze ti ve skutecnosti nejde o neSQL pristup k SQL databazi, ale o SQL-like (ale ne pres ascii reprezentaci sql prikazu) pristup k datum v pameti?

JACHYMKO: no... toto řeší upgrade na novou verzi toho mého hypotetického "parseru SQL" - v podstatě to jen proženeš jiným parserem, a vygenerují se ti bindingy na jinou databázovou knihovnu :-)

REDGUY: tak víceméně, o tomhle mluvím. jen jsem líný programovat "ručně" něco, co umím zapsat jednoduchým SQL dotazem. viz můj nápad s generováním kódu na základě SQL dotazu: v podstatě stejně, jako nezapisuješ strojové instrukce, ale necháváš si je kompilerem generovat z C (či C++) zdrojáku, tak já bych nechtěl zapisovat složitou C syntax na procházení datových struktur - ale chtěl bych si ji nechat vygenerovat z SQL zdrojáku. (samozřejmě tam jsou zádrhele - třeba namespace C programu vs. namespace tabulek - neříkám, že je to jednoduché, ale nějaký markup by na to vymyslet šlo)

FLEGMA: viz to co jsem psal: já bych se ani nebránil vygenerování té C-syntaxe z konvenčního textového SQL dotazu: dokonce by na to určitě šlo udělat nějaký markup, který by ti zdroják před-kompiloval, pokud by si změnil ty SQL dotazy v nějakém specificky naformátovaném "komentáři", předcházejícím generovanou sekvenci (prostě zase makra, akorát tentokrát na jiném levelu :-)

že se to používá, jsem tušil.. před lety jsem si vyměnil pár mailů s Ondřejem Čadou, který si mi vytahoval tím, že jeho úžasný C++ framework umí právě tohle (akorát si nejsem jistý, jestli jen pomocí přetěžování C++ operátorů neřetězil ten SQL dotaz - ale to zřejmě právě bylo jednotné API pro různé implementaci)

vlastně celý můj dotaz byl "existuje něco takového např. pro MySQL"? protože protlačování výsledku přes sockety to zase může (trochu brzdit) - pokud by to byla databáze ve sdílené paměti (v tomto jsou Unixy/Linuxy dobré a já jsem v používání shmget() začátečník), tak pochopitelně: výsledek dotazu pak může být složen z pointerů na původní umístění v paměti a nic se nemusí kopírovat.

DAVIDOWITCH: jo a ne. hele, já sice pokládám C-zdroják za slušný "základní level" visualizace, skrze který si prohlížet "co se děje uvnitř" (rozhodně nejsem nadšenec pro nějaké binární výpisy, disassemble, apod. - to je prostě už moc "pod zemí", pro mě, když bych se v něčem takovém musel hrabat... je to pro mě fail asi jako když macintoshista musí sáhnout na něco jiného než myš a tlačítko jabko na klávesnici). Ale vůbec netvrdím, že všechen C zdroják musí být napsaný ručně: sám pracuju např. na generátoru C zdrojáků z HTML šablon... a existuje spousta jiných nástrojů, co něco generují.

např. GIMP umožňuje uložit ikonky ve formě C zdrojáku, existují parsery syntaxe, které generují C procedury on fly, apod. - mě by vůbec nevadilo, kdybych měl nějaký nástroj (např. commandline, či na webu), do kterého bych napsal normální SQL dotaz, a ono by mi to (na stdout, do clipboardu nebo tak) vygenerovalo sekvenci těch C procedur, které dělají s datovou strukturou to samé. já vůbec nejsem odpůrce generovaného zdrojového kódu!

JACHYMKO: no víceméně si docela nastínil, jak si takové C API pro SQL představuju :-) (i když samozřejmě, šlo by to jistě vylepšit několika dobře promyšlenými makry preprocesoru)

hele, tohle není o tom, aby to bylo user-friendly... pokud někdo píše dotazy přímo v SQL, tak nejspíš stejně frontend napíše taky v nějakém vyšším jazyce. ber to třeba tak, že se snažím o cosi jako "sportovní výkon" - soustředit co nejvíce lidí na serveru u mě doma nebo prostě aspoň na mém osobním serveru ("na BBSce", chceš-li ... či na IRC, cokoliv) a s co největším uživatelským komfortem (odpovídajícím téhle době) i s pokud možno realtime odezvou.

samozřejmě ti může připadat víc cool mít to celé hostované na nějaké serverové farmě... ale to je jako srovnávat nějakou sportovní událost s jízdou vlakem.