KEJML: tak zas tak ambiciózní to není, dnes jsou jazyky dost složitý, takže pořád jsou lidi, kteří jen primitivně skriptujou v shellu, což je overkill směrem na druhou stranu.

spíš mám po letech chuť něco naprogramovat. podle kámoše co dělá v PHPse dnes všechno píše spíš v node.js... ale cílem je přesně to,co jsem popsal: lidi mají někde PHPhosting a potřebujou to, co usmolej, hned deploynout. nicméně, když se budou učit to moje prostředí, tak jim paralelně vyjede i zdroják v C pro FastCGI, nebo (snad) i ten node.js

nebude to nic extra složitýho, spíš prostě webová platforma.. bindingy na mysql a čtení formulářů, apod...

XCHAOS: jednak se vyhnu lock-inu na jedne platforme (coz je nakonec i gcc, jakkoliv svobodne) - poslechnete, Kefalin, co vy si predstavujete pod takym "Lock-in na jedne platforme"? Protoze GCC je schopny generovat kod pro procesory od AVR pres x86 az po treba IBM mainframy. Ja tam ten "lock-in" nejak nevidim, tak se tesim, az mi to vysvetlis 8)

No kazdopadne se tesim, az ten projekt v nejaky funkcni podobe predstavis. Kdy tak zhruba to bude? 8))

XCHAOS: Když máš v klubu právo mazat, vidíš všechny, včetně ignorovaných, jinak bys nemohl zodpovědně zastávat moderátorskou roli.

XCHAOS: Jazyk, co se bude prodávat do několika jiných jazyků - velice ambiciózní projekt. Jakou si představuješ aplikaci v praxi? Takhle z fleku mne nenapadá situace, kdy bych si řekl, že přesně tohle bych potřeboval.

REDGUY: chtel bych treba napsat i neco jinyho, nez generator iptables... ale pokud te to opravdu vzdava, tak snahu o nejake zjednoduseni C asi pomalu vzdam a uvazuju ted spis o generatoru kodu pro vice platform (tedy definovat si vlastni primitivni jazyk, napsat jeho parser, a generovat z nej kod pro C, PHP, Python, atakdal).

Tahle cesta je zajimava z vice duvodu: jednak se vyhnu lock-inu na jedne platforme (coz je nakonec i gcc, jakkoliv svobodne), jednak umozni srovnat vykon ruznych platforem provadejicich fakticky to same, jednak jsou mozne budouci optimalizace dilcich targetu bez nutnosti prepisovat hromady zdrojaku... no a v neposledni rade, je jasne, ze treba nejake binarni fastcgi bude vzdycky provozovat jen par geeku, zatimco siroke masy si nainstalujou jen to, co jim bude chodit na PHP hostingu.

Takovy code generator, i kdyz asi bude natruc napsany v C (rychlost se u compileru snad porad jeste ceni), ovsem asi v tomhle klubu kupodivu bude offtopic.

SplitStacks - GCC Wiki
http://gcc.gnu.org/wiki/SplitStacks

tak jsem dospěl někam sem:
c - Print out value of stack pointer - Stack Overflow
https://stackoverflow.com/questions/20059673/print-out-value-of-stack-pointer

napadlo mi, že kdyby alokátor seskupoval alokace podle hodnoty stack pointeru v momentě alokace, tak by při prvním volání po návratu z funkce mohl nějak vyhodnotit, které položky může už zahodit - bylo by to překvapivě bezpečné i pro nestandardní způsoby opuštění funkce (longjmp). takovýto "pseudo garbage collection" by šlo iniciovat i mimo volání alokátoru, kdyby bylo potřeba, ale alokátory by ho volaly minimálně pokaždé, když by jim došla pre-alokovaná paměť...

v podstatě by šlo o to vždy označit kus heapu jako asociovaný s aktuální hodotou stack pointeru. přičemž odmazávat by se měla vždy především "poslední předchozí", dle logiky věci.. akorát mi tam hapruje, jak jí odlišit např. od předposlední, která ještě může být platná, pokud se v té poslední nealokovalo nic.

alokátory paměti by pak v podstatě pro běžný život stačily dva, zhruba ekvivalentní prastarým Basicovským levelům "local" a "global" (což mimochodem velmi dobře odpovídá C světu do sebe nevnořovaných funkcí). lokální alokátor by pak podle nejlepších C zvyklostí pro označování privátních a lokálních hodnot mohl začínat podtržítkem...

REDGUY: jak to že tě tady vidím, když tě už mám v ignore? :-(

jinak ano, zamýšlím se nad tím, googlím... a alloca() asi fakt nebude řešením pro moje pokusy o nějakou sadu zásad pro bezstarostné programování v C... ale více nebudu psát v odpovědi pro tebe.

XCHAOS:

man bash

a hledej ulimit, switch -s. A zamysli se nad organizaci pameti a tim, jake dusledky ma pro moznou velikost stacku 8))

ANT_39: no ale jak je to vůbec s velikostí stacku např. v Linuxu? to je tam pořád omezení na fixní limit jako kdysi v DOSu?

XCHAOS: S alloca a VLA je problem, ze pro prilis velky alokace se muzes snadno dostat mimo stack. Tusim v glibc a elfutils jsem normalne videl kod ve stylu if (x > a lot) malloc(x) else alloca(x) (a odpovidajici tomu free nebo nic). V linuxovym kernelu se dela na nahrade vsech pripadu alloca a VLA za alkoace na halde, mimo jine protoze ten stack overrun je potencialni bezpecnostni riziko.

popravdě, jestli ještě budu někdy cokoliv dělat se stringama v C, tak uvažuju o tomto:
Advantages of Alloca (The GNU C Library)
https://www.gnu.org/software/libc/manual/html_node/Advantages-of-Alloca.html

Ahoj, budu vdecny za jakykoliv nazor. Ted zrovna resim, proc mi interaktivni moc nabehne do prazdne obrazovky. Ale nejsem si jisty proc.
Je to prohlizec ans souboru pro utf-8 terminaly. Je to psany tak nejak zbesile, ale pro svoje ucely mi to staci.
http://elinks.xf.cz/pub/ansiu/

ALMAD: Neznal jsem, diky!
XCHAOS: Vo vypada, ze zpatky dostanes promisu.

ALMAD: Sice základní princip, že to mají v paměti, se mi líbí.. tohle ale zní trochu podezřele: Time-traveling RPC: Cap’n Proto features an RPC system that implements time travel such that call results are returned to the client before the request even arrives at the server!
:-)

REDGUY: tenhle kód...
#include "sqlite3-1.c"
#include "sqlite3-2.c"
#include "sqlite3-3.c"
#include "sqlite3-4.c"
#include "sqlite3-5.c"
#include "sqlite3-6.c"
#include "sqlite3-7.c"
....mi popravdě připomíná jeden můj header file :-)