ugrás a tartalomhoz

php szerkesztés

Szita Szilárd · 2013. Május. 2. (Cs), 19.11
sziasztok valaki már próbálta szerkesztení magát a php nyelvet?
ki mit alkotott?
hogy lehet fordítani?
‹ Könyvtár tartalom listázása phpshell ›
 ■
1

Gondold át újra

Pepita · 2013. Május. 2. (Cs), 19.27
Mit értesz a nyelv szerkesztése alatt?
Ha arra gondolsz, hogy az értelmezőt átírod (otthon, magadnak), akkor gondold át mégegyszer a dolgot, mert kissé butaság.
Nagyon sokan fejlesztik a PHP-t, sok-sok programozói munkaórában, mégis van mikor több év is eltelik két verzió kiadása között. Ha keresgélsz, fogsz találni bizonyára magyar fejlesztőt is, aki részese (volt) ennek a csapatnak, de ez nem szerkesztési művelet. Itt a többség használja a különböző programnyelveket; amúgy is van annyi(féle), hogy találsz a célodnak megfelelőt, nem kell saját nyelvet írni, pláne nem "átszerkeszteni". Persze saját modulokat, osztályokat szinte mindenki írt, de nem a PHP bővítésére vagy átalakítására, hanem felhasználásra.
6

Úgy értem mint

Szita Szilárd · 2013. Május. 2. (Cs), 21.39
Úgy értem mint pl a facebook ha jól olvastam ők egyedi php-val dolgoztak.
7

HipHop

MadBence · 2013. Május. 3. (P), 01.41
Szerintem a HipHop-ra gondolsz. Az egy olyan okosság, ami PHP kódból C++ kódot fordít, amit lefordítva nyilván sokkal gyorsabb kódot kapunk. Hátránya az, hogy fordítani kell, azaz ha nem vigyázunk, nem csak egy kávé fő le, amíg elkészül az aktuális build. Pont ez miatt annyira már nem elterjedt.
Helyette van a HHVM, ami PHP kódból valamilyen bytekódot készít, amit egy arra alkalmas virtuális gép futtathat (ez az architektúra van többek között a Java, C# mögött is)
8

hiphop

Hidvégi Gábor · 2013. Május. 3. (P), 08.25
Nekem szimpatikus lenne a HipHop és akár a HHVM is, de amióta megláttam az utóbbi függőségi listáját, erős fenntartásaim vannak. Amikor – talán tavaly – először próbálkoztam a HipHoppal, és próbáltam feltelepíteni, már az is nagyon sokmindenre támaszkodott, és voltak olyan könyvtárak, amelyeket nem is lehetett a kívánt verzióban egyszerűen megszerezni.
9

Dependency hell

vbence · 2013. Május. 3. (P), 09.22
Ahogy látom ez inkább fejlesztői döntés, mint az architektúra velejárója. Ahelyett, hogy fordításkor írná, ki, hogy pl nem használhatsz memcached-et, a biztonság kedvéért felrakja a leggyakrabban használt kiterjesztéseket.

Ha szoktál fordítgatni az adott rendszerben akkor sok -dev végű csomag már eleve fent van (plusz olyanok, mint a wget vagy openssl szinte minden rendszerben megtalálható).

Nekem sem szimpatikus a "dependency hell", ne érts félre, de ez sajnos az opensource velejárója valamilyen szinten. Ha (majd egyszer) egy disztribúció elhatározza, hogy csomagolja, már sokkal könnyebb lesz a bekerülés.
10

-dev

Hidvégi Gábor · 2013. Május. 3. (P), 09.32
Nemrég kezdtem el komolyabban linux-szal foglalkozni, és csomagkezelővel legfeljebb MC-t telepítek, pont az ilyen függőségi problémák miatt. Volt egy fejlesztői szerverünk, amire három-négy éve tettük fel a szoftvereket, s azokat a Debian csomagokat azóta már archiválták. Nemrég szerettem volna PHP gyorsítót tenni rá, de gyakorlat híján nem volt egyszerű megtalálni a módját, jópár régi csomagot már nem lehetett telepíteni így sem.

Emiatt egy jóideje már mindent magam fordítok, a forrást meg otthagyom a masinán, mert az a biztos.
11

Forrsából

vbence · 2013. Május. 3. (P), 09.48
Főleg Debiannal nem egyszerű. Ha stabil distrót hasznátok akkor már telepításkor szinte elavult a csomagok legtöbbje (legalábbis ha új technológiák kipróbálása a cél).

FreeBSDnél ez a folyamat sokkal fájdalommentesebb, ott az a gyakorlat, hogy a base systemen kívül minden forrásból fordul amit felteszel.

Amúgy ez nem feltétlenül baj. Aki friss technológiákat szeretne kipróbálni az tarthat egy "testing" rendszert. Ha egy új technológia megérett arra, hogy éles környezetben használják akkor a distribúciók részéről is támogatottabb lesz.
14

Aki friss technológiákat

Hidvégi Gábor · 2013. Május. 3. (P), 10.57
Aki friss technológiákat szeretne kipróbálni
Kipróbáltam már sok szoftver sok változatát, de egyre kevésbé vagyok meggyőződve arról, hogy az újabb az szükségszerűen jobb.
15

Ez inkább a tudás hiánya,

BlaZe · 2013. Május. 4. (Szo), 09.09
Ez inkább a tudás hiánya, mintsem a csomagos telepítés korlátja. Egyrészt több év alatt a debian is verziót vált, nem tudom mit hogy használtatok, de azért a debiannak nem short-term supportja van. Illetve vannak különböző backportok is stb.

Éles szerveren általában nem rohanunk az upgrade-ekkel, csak akkor teszünk fel valamit, amikor már elég stabilnak gondoljuk, debiannál is ezért sem dobálják bele az új verziókat azonnal. Egyébként az utóbbi időben mintha nem lennének akkora elcsúszásban, mint rég voltak. Pl van már 9-es pg is egy ideje.

Szerintem ha van valaki, sőt egy csapat, aki forrásból fordított rendszert karbantart, akkor még lehet oké a dolog, egyébként hosszú távon egy pokol :) De ha van rá csapat, akkor se úgy működik, hogy feltolom a forrást minden gépre, ott configure,make,make install, aztán majd jó lesz :) Próbáltuk mi is, embertelen szopás tud lenni egy verziófrissítés. Valamint van olyan nézet, hogy éles vason nem hogy forrást, de fordítót sem ajánlott tartani... Mondjuk a gentosok erről nem tudom mit gondolnak :)
12

Függőségek

Poetro · 2013. Május. 3. (P), 10.37
Azért a PHP-nak is hasonlóan nagy a függőségi rendszere. Ha fordítottál már PHP-t nulláról, akkor láthattad, hogy nem egy egyszerű történet. Nekem elég nagy szenvedés, config fájl és forráskód módosítás után sikerült csak pl. Cygwin alatt lefordítani az 5.3.6-ot
13

Igaz, ott is el lehet

Hidvégi Gábor · 2013. Május. 3. (P), 10.54
Igaz, ott is el lehet szállni, szerencsére nekünk nem sok modulra volt szükségünk, így elég volt ennyit kiadni:
pkg_add libxml libmcrypt libtool autoconf-2.68
A libtool kivételével a többit is azóta fordítom.

Cygwint még nem próbáltam, Windows alatt Visual Studio Express két vagy három változatával kísérleteztem, igazából a fordítórendszer összehozása volt a leghosszabb, aztán gond nélkül ment minden. Egyébként sebességben nem vettem észre javulást az újabb VS-ekben, így nyugodtan lehet a régebbieket használni (amik jóval kevesebb erőforrással beérik).
16

Homályos

Pepita · 2013. Május. 6. (H), 23.30
Lehet, hogy velem van a baj, de én nem tudom megérteni, hogy mi értelme lehet annak, hogy
PHP kódból valamilyen bytekódot készít
?!

Akkor miért nem egy olyan nyelven programozok, ami arra a bytekódra fordul? Minél többször (több lépcsőben) fordítok egy forráskódból, annál gagyibb a végeredmény. Persze lehet magyarázni, hogy az a kód már készen van, de azért ennek a másrafordításnak inkább nagyobbacska rendszeren van jelentősége, ott meg több a fejlesztői erőforrás is. A PHP amúgy sem egy jól optimalizálható nyelv (gyengén típusos, stb), szóval kutyából nem lesz (jó) szalonna.
17

Ne a PHP nyelvet nézd, hanem

pp · 2013. Május. 7. (K), 06.13
Ne a PHP nyelvet nézd, hanem a PHP-t mint eszközt a számos kiegészítővel. (nem beszélve mondjuk egy kész PHP alkalmazásról)

Ezért éri meg ezt a furcsa megoldást használni.
18

Igen,

Pepita · 2013. Május. 9. (Cs), 20.02
a kész progi, ill. a "megszokás" részben indokolhatja, de eléggé furcsa. (<- Nagyon helyes jelző rá!:))
19

Azt az eszközt, ami PHP

tgr · 2013. Május. 10. (P), 09.39
Azt az eszközt, ami PHP forráskódból bájtkódot készít, úgy hívják, hogy PHP.
21

Azt hiszem ezt

Pepita · 2013. Május. 12. (V), 19.34
minden eddig hozzászóló tudja. :)
20

Én nem tudom hogy pl a

MadBence · 2013. Május. 10. (P), 13.45
Én nem tudom hogy pl a facebooknak pl miért éri meg PHPban fejleszteni (valószínűleg pusztán azért, mert a meglévő kódbázist átportolni nem éri meg), de megéri nekik.
A bytekódra fordítás (illetve a JIT fortítás) azért éri meg, mert amikor a PHP értelmező futtat egy scriptet, akkor először beolvassa a tartalmát, megnézi szintaktikailag helyes-e, szépen feldolgozza a függvényeket, változókat, vezérlési szerkezeteket, függvényhívásokat, és valami bytekódot (ezt valami pszeudo-assemby nyelvként kell elképzelni) köp ki magából, amit végül futtat. Ez lassú.
Helyette előre le lehet fordítani az egészet, futás közben pedig a lassú részeket (ez a program saját maga méri) akár natív(!) kódra tovább lehet fordítani.

(Nem vagyok expert a témában, szóval lehet, hogy néhol csúsztattam. lehet szólni érte, ha tényleg így van!)
22

Igen,

Pepita · 2013. Május. 12. (V), 19.35
valami ilyesmire gondoltam én is, továbbra is PP-vel értek egyet: ez is egy megoldás, csak furcsa.
2

Én egy ilyet

vbence · 2013. Május. 2. (Cs), 19.27
Én egy ilyet csináltam annó a php erőforrás-használat naplózására.
3

Hoppá

Pepita · 2013. Május. 2. (Cs), 19.31
Ha 5 perccel később jövök, akkor nem felejtem ki az 1-ből a kiterjesztés lehetőségét...
4

Késő bánat ;)

vbence · 2013. Május. 2. (Cs), 19.38
Késő bánat ;)
5

És...

vbence · 2013. Május. 2. (Cs), 19.42
Meg egy alkalommal élesben is szerkesztettem (persze csak a saját példányomat), amikor kitalálták (talán 5.1 -> 5.2), hogy legyen egy beépített DateTime osztály, minden prefix nélkül, és akinek van egy frameworkje, ami használja ezt a nevet az ###kukac##&#x>hatja.

Ekkor készült ez a műremek:
*** ext/date/php_date.c.bck     Sun Sep 10 19:01:51 2006
--- ext/date/php_date.c Wed Nov 29 13:31:17 2006
***************
*** 1448,1454 ****
  {
        zend_class_entry ce_date, ce_timezone;

!       INIT_CLASS_ENTRY(ce_date, "DateTime", date_funcs_date);
        ce_date.create_object = date_object_new_date;
        date_ce_date = zend_register_internal_class_ex(&ce_date, NULL, NULL TSRM
        memcpy(&date_object_handlers_date, zend_get_std_object_handlers(), sizeo
--- 1448,1455 ----
  {
        zend_class_entry ce_date, ce_timezone;

! //    INIT_CLASS_ENTRY(ce_date, "DateTime", date_funcs_date);
!       INIT_CLASS_ENTRY(ce_date, "DateTimePHP", date_funcs_date);
        ce_date.create_object = date_object_new_date;
        date_ce_date = zend_register_internal_class_ex(&ce_date, NULL, NULL TSRM
        memcpy(&date_object_handlers_date, zend_get_std_object_handlers(), sizeo