![]() |
Utvärdering av Phalanger 3.0 (.NET Kompilator för PHP5 med inslag av PHP6)
(Tråden är en fortsättning på diskussionen i tråden: http://www.wn.se/t1058306-15-2.html)
Jag flyttar diskussionen om Phalanger till en ny tråd för den blir lite OT i ursprungstråden. Det kan vara nyttigt att fokusera på utvärderingen utan att diskutera övriga frågor i tråden. |
Verktyget Phalanger hittar du här: (http://phalanger.codeplex.com/).
Phalaner är med andra ord en kompilator som skapar EXE- eller DLL-filer, eller webbsidor för IIS för Microsoft .NET-miljön, av programkod som skrivits enligt PHP5- eller PHP6-syntax. Det finns vissa diskrepenseer p g a att verktyget är ganska nytt och inte testat fullt ut. Jag har börjat testa verktyget för att se om jag kan hitta en användning för verktyget, primärt i mitt yrke som systemutvecklare. Jag planerar att dela med mig av mina erfarenheter här i tråden. Jag uppskattar om andra finner nöje i att testa verktyget och dela med sig av sina erfarenheter här i tråden. Jag har som mål att testa såna egenskaper som jag anser vara viktiga vid utveckling: - Objekttänkandet (Den objektorienterade eller objektbaserade paradigmen) - Kompilering - Typning - Komponenttänkande (dvs ej källkodsbaserade komponenter) - Integration i Microsoft Visual Studio - Kommandoradsinterface (CLI) - Interoperabilitet med .NET-miljön - Hur man skapar återanvändbara komponenter för PHP5- (& senare PHP6-syntax) - Hur man skapar återanvändbara komponenter för .NET - Hur man använder återanvändbara komponenter i PHP5- (& senare PHP6-syntax) - Hur man använder återanvändbara komponenter i .NET Eftersom jag inte är särskilt erfaren PHP utvecklare kommer jag inte att fokusera på egenskaper som (det får andra göra): - Bakåtkompatibilitet med äldre PHP-syntax - Överensstämmelse med loose typing-paradigmen - Scriptspråks-tänket |
Inslag av PHP6. Intressant.Snabb titt på deras wiki ser man att de inte ens stödjer PHP5.5. Sen undrar jag då vad som stöds från den väldigt ospikade listan på https://wiki.php.net/todo/php60 Eller du kanske hade något helt annat i åtanke? För inslag från något som inte ens finns låter lite konstigt.
Att native PHP extensions gör att man får köra allt i 32-bitar. Det skulle jag kalla produktionsodugligt för nya projekt. Intressant att du även har omdefinierat "komponenttänkande" till att bara täcka upp stängda miljöer. Jag förstår verkligen inte varför en komponent som kan buggfixas och felsökas är mindre av en komponent, men allt för sitt syfte? Jag är faktiskt rätt intresserad om du faktiskt finner något vettigt syfte alls för hela lösningen. Vill man köra en PHP applikation i en MS-miljö är ju PHP så öppet att du enkelt kör PHP under IIS. Därutöver verkar det mest som ett sätt att förstöra och begränsa ekosystemet och utvecklingsprocessen. Men om man som .NET utvecklare aldrig vill gilla PHP så kanske det är en bra egenskap? Men då förstår jag inte varför man inte håller sig borta helt ... Och ta nu inte detta som ett tal för PHP (som jag jobbar med nästan varje dag) eller mot .net (som jag satt med senast igår kväll). Det är endast menat emot Phalanger som jag inte ser den minsta lilla poäng att faktiskt lära sig. |
Jag har inte sett diskussionen i länkad tråd, inte heller sett, provat eller hört talas om Phalanger tidigare.
Däremot kan jag sett ett användningsområde: om man vill med PHP skapa .NET-baserade program som kan köras utan webbserver. (win8 appar eller liknande) Fast varför inte lära sig .NET i så fall? I övrigt håller jag med Clarence. |
Ser inte heller någon större vits med att "göra om" PHP-skript till .exe eller .dll-filer? Är det inte bättre att i så fall välja ett annat programmeringsspråk där detta är en mer naturlig del av sättet att utveckla för det specifika språket?
|
Nu har jag testat att skapa ett C# Class Library med en enkel class 'Hello' och en metod Say() som skriver ut en parameter på consolen.
Förutsättningen är jag har Visual studio 2010 och Phalanger 3.0 installerat. Jag började med att skapa ett projekt för C# Class Library, koden blev så här: Kod:
// File: CSHello.cs Kod:
<?php Tryckte på F5 för att testköra och så fick jag följande out put på consolen: Kod:
Hello! Fördelen är att den som nu föredrar att arbeta med syntaxen i PHP men vill komma åt funktionalitet i .NET Framework eller länka in komponenter skrivna i .NET, nu kan göra det. Man kan med andra ord använda färdigtestade komponenter från .NET men skriva syntaxen i PHP om man gillar det. |
Citat:
|
Citat:
Nej, jag tror nog digiart var den enda som lyckades hitta en fördel här. Men också den är ju verkligen ett extremt edge case. Om man har en färdigskriven PHP app med lite UI logik och vill använda den för en metro app och råkar ha använt tillräckligt stor del kod som stöds av Phalanger så kan man kanske snabbare få ut sin metro app. |
Citat:
Källkod som du kopierar från ett projekt till ett annat är inte att betrakta som "återanvändning" av färdigtestade komponenter, eftersom du då öppnar upp risken att någon (du själv inräknat) går in och gör ändringar i en källkodsfil men inte i de andra 150.... Källkoden är fortfarande hur öppen man vill att den ska vara, "open source" har inget motsatsförhållande till begreppet "färdigtestade komponenter". Jag såg även att det faktiskt finns stöd från PHP version 4.1 eller om det var 4.3 för klasserna COM, respektive DOTNET som gör att man kan instanciera Windows COM respektive DOTNET-DLLer. När jag testade i PHP 5.5.0 nu så fick jag det dock inte att fungera, men det kan ju bero på att jag inte ställt in PHP.INI på rätt sätt, jag håller på att undersöka. Men jag tycker Phalanger verkar lovande i alla fall. Nu har jag installerat och kört lite objektorienterad Python (dock okompilerat) i Visual Studio så jag har inte testat hur COM och DOTNET-klasserna funkar i PHP. Python verkar väldigt känsligt för kolumnpositioner på källkodsraderna, det är som att gå tillbaks till Cobol, som också var extremt känsligt för källkodens kolumnpositioner. |
Med open source finns alltid "risken" att någon ändrar i din färdigtestade kod... Det är ju en av de stora fördelarna. Du måste nog allt bli lite mer flexibel och öppen om du någonsin ska kunna ta till dig PHP.
|
Citat:
Med en bra arbetsstruktur har du dina bibliotek i VCS. Du har versionering av dina bibliotek. Du uttrycker explicit vilken major + minor du vill ha och uppgraderar bara patch. Externt inladdade bibliotek ligger separat och vill man göra en ändring i dom vet man att man gör ändringarna i bibliotekets källa och uppgraderar sin version utefter vad man gjort. Liksom med kompilerade komponenter går detta åt helvete om någon gör något helt galet. Att göra någon ändring i biblioteken i sitt egna projekt är precis lika dumt som att göra en ändring i en kompilerad komponents källkod för att sedan bara kompilera om och inkludera med samma version i sitt projekt. Citat:
|
Citat:
Givetvis pågår arbetet i den övriga utvecklingen, men man har en uppsättning binärfiler som ska med i n viss release som inte får ändras. Du får tänka på att det är många personer involverade (både utvecklare, kravställare, produktionstekniker, supportpersonal m.m.) alla måste vara synkroniserade på samma kodbas. Om något ändras så måste hela testet göras om från början. Därför vill man ha järnkoll på detta. Citat:
Python är ju trots allt betydligt trevligare än PHP och Ruby betydligt trevligare än Python. Även om Python och Ruby i övrigt har snarlik syntax. Jag upptäckte dock att Python har ändrat Syntax så man måste sätta ut paranteser på print(), i alla exempel jag hittar på internet så har man INTE parenteser så i stort sett ingen exempelkod funkar utan handpåläggning. Nåväl jag ska inte klaga så mycket på Python för jag håller på att testa språket. Jag har laddat ner Open Cobol (som stöder både Cobol 85 och Cobol 2002, men tyvärr har jag ingen körbar version i Windows-miljön (man måste sätta upp och kompilera med MinGW eller GCC och det har jag inte orkat, det är en massa inställningar man ska göra innan man kan kompilera och just nu orkar jag inte med det). Jag har kör den binära i Ubuntu och det funkade ju klockrent. Det finns en gigantisk kodbas med installerad Cobolkod som är i produktion, främst inom stora företag som Banker, försäkringsbolag, myndigheter, stora börsnoterade industriföretag. Dessa proggram rullar på i sina dagliga batchar och har så gjort sedan slutet av 1950-talet/början av 1960-talet när de första Cobol-liknande dialekterna dök upp (tror Cobol blev officiellt 1963...). Det kommer ta tusentals/kanske miljontals manår att ersätta den kodbasen... Så de byts ut modul för modul och inte förrän det inte går att köra vidare. Det funkade enkelt att länka ihop en vanlig ANSI C modul i Open Cobol. Jag hittade en bra Tutorial för Python som jag gått igenom och testkört alla exempel. Jag fick bra koll på hur syntaxen är uppbyggd. Enkel filhantering, felhanering m.m. Har inte testat Databasacess med Python ännu. Ruby känns betydligt större (ur teknisk synvinkel) och mer välgjort än både PHP och Python, mycket mer väl genomtänkt objekthantering. Känns som Ruby har betydligt bättre inkasling, arvsmekanismer m.m. Verkar mer okänslig för kolumnspositioner. Har dock inte fått require("namespace") att funka, men Load("filename") funkade bra. Hittade en riktigt bra webbplats ruby-doc.org som har gigantiskt med exempelkod, som jag håller på att traggla mig igenom. |
Citat:
|
Ja, programspråket ska ha en tolerans mot struntsaker, men skrika högt när man gör allvarliga fel.
Just kritiska kolumnpositioner har jag nog bara sett i Python och Cobol om jag minns rätt. De flesta andra programspråk brukar vara flexibla mot såna triviala fel, Men i Python och Cobol så har kolumnpositionerna betydelse så då gick det inte att vara snäll för Python i det läget. .... |
90% av indenteringen ser likadan ut i välskriven kod som i Python kod (notera att du oftast har valmöjligheter i var du bryter raderna i python). Sen att du tycker det är en struntsak huruvida din kod är lätt läsbar eller ej, det låter jag dig stå för (det finns ca 43243242342 undersökningar som visar på att en konsekvent indentering leder till bättre läsbarhet). Själv tycker jag inte om att de ersatt andra avgränsningstecken med tvånget av indentering - men det tror jag är för att mina ögon är så vana vid C/PHP/Java/C#/etc-tecknena. Men det är ett tydligt val som faktiskt går väldigt bra ihop med faktiska egenskaper hos programmerare.
Sen vet jag inte om du är medveten om att en versions-taggning i din VCS leder till precis samma sak som en kompilerad binär. Det är en förhållandevis självklar process om man har acceptanstester eller liknande för varje lanserad version. Binären är lite svårare att ändra i annat än byta namn och i värsta fall göra den oidentifierbar eller obrukbar, taggningen är lättare att följa då man kan ta sig en titt i historyn om någon ändrat något (en tagg är en tagg är en tagg, den SKALL ej förändras. För versioner under arbete använder man branches.) |
Citat:
Citat:
Citat:
|
Citat:
Python skrek högt om jag använde {tab} i stället för {space} för indenteringen, jag var tvungen att slå på automatisk omvandling till {space} för {tab}-tecknen för att det skulle gå att köra koden. Om jag minns rätt så är inte ens Cobol lika kinkig om man använder {tab} eller {space} vid indentering. Ruby verkar vara betydligt mer generös med definitionen och toleransen av whitespace.... Jag har dock fortfarande problem med require i Ruby, får det bara inte att fungera.... Filerna ligger i samma katalog. Jag har PATH till Ruby Bin-katalog, alla annan kod jag testkör med Ruby funkar klockrent "load" funkar men inte "require". Vad gör jag för fel? Jag kör version 2.0.0p195 från 2013-05-14. Kod:
# File: Trig.rb Kod:
# File: TrigTest.rb |
Citat:
Sen bör du ändå följa PEP8 om du skriver Python. Vilken säger åt dig att använda spaces (för att dess representation är konsekvent). Du ställer helt enkelt in din editor att använda spaces när du trycker på tab. Denna best practice återfinns i många style guidelines för en mängd språk. Att du får runtime errors med rent felaktig indentering är väl rätt självklart. Om alla dina avgränsare är indentering så kan man väl förvänta sig att de är korrekta. Annat är väl ungefär som att tycka att ) ska kunna ersätta } i C# när det ändå inte finns någon starting (. |
Just nu håller jag på med Ruby, gillar det bättre, men nu så har jag ett nytt dilemma, vilken databas API-ska jag använda? Har kollat på en del olika men RDBI verkar vara den senaste jag hittat, dock verkar den lite personberoende då det verkar vara 1 person som heter Eric Hollenbe som gör 99% av allt jobb.
De senaste 3 åren verkar det inte hänt så mycket i det projektet. Frågan är om det finns ett annat API för databaser som är lämpligare? |
Citat:
Postgres: http://rubygems.org/gems/pg MongoDB: http://rubygems.org/gems/mongo MySQL: http://rubygems.org/gems/mysql |
Jag använder MS SQL-Server, Access, MySQL.
Jag kör Windows 7 som operativ. |
Citat:
2. MS SQL-Server lirar nog inte så bra med Ruby. Prova med MySQL det ska funka bra! |
Citat:
Jag var först tvungen att installera DevKit, vilket är gjort, sen fick man upp något nytt kommandofönster och sen körde jag typ $ gem install mysql <ENTER> ...sen sa att driver för MySql är successfully installed, men inget av de exempelkoder jag kört funkar. Det gnäller på att det inte finns någon namespace rdbi/dbi.... Har sökt men inte hittat filen libmysql.dll i min Ryby installetion (c:\Program Files (x86)\Ruby200...). enligt doc så ska jag lägga filen libmysql.dll i ryby\bin.... men jag hittar inte libmysql.dll någonstans.... finns några *.rb-filer i driver-katalogen som jag lagt upp, men det var en helt USEL dokumentation och dokumentationen stämmer inte med verkligheten.... Jag har nu ägnat halva dagen åt att hitta en lösning för att köra mot MySQL i Ruby.... Jag känner mig frustrerad.... |
libmysql.dll hittar du i din MySQL-installation, inte i Ruby.
|
Citat:
Trodde det var rdbi, interface mot MySQL..... Men den gnäller fortfarande på namespace.... Följande kod har jag att testa med: Kod:
#!ruby20 Jag har lagt in lib filerna från "rdbi-1.2.0.pre0" till Rubys lib-katalog. Har även lagt in lib-filerna från "rdbi-driver-mysql-master" till Rubys lib-katalog. Har även kopierat in libmysql.dll i Ruby\bin från MySQL\lib. Men namespace rdbi\dbi hittas inte.... |
Skit i rdbi...
1. Installera en gem för mysql. Tex mysql2 (tror den ska vara lite bättre än mysql) https://github.com/brianmario/mysql2 2. Tuta och kör ;) Finns massa exempel på länken ovan. Citat:
|
Ruby-utveckling under Windows kan inte vara enkelt då ingen använder platformen.
|
Citat:
successfully installed.... Kod:
C:\Projects\Conny\Ruby\MySQL2\mysql2-master>gem install mysql2 Körde även koden enligt exempel i ReadMe-filen: Kod:
# File: mysql2_test.rb Kod:
C:\Projects\Conny\Ruby\Hello>ruby mysql2_test.rb Jag kör senaste version av Ruby dvs 2.0.0p195 |
Har du importerat mysql2 i din kod?
`require "mysql2"` |
Citat:
Använder jag require "mysql2" så får jag dock betydligt fler felrader enligt: Utan require: Kod:
Microsoft Windows [Version 6.1.7601] Kod:
Microsoft Windows [Version 6.1.7601] |
Jag kanske glömde nämna att jag även gått till Rybu-katalogen c:\Program Files (x86)\Ruby200 och kört:
Ruby dk.rb init och därefter: Ruby dk.rb install sen körde jag: Ruby dk.rb Review Allt rapporteras vara OK, men när jag försöker köra: Kod:
require "mysql2" Kod:
....require cannot load such file -- mysql2/2.0/mysql (Load Error) Intressant blev det dock när jag la till de två första raderna i följande kod: Kod:
#!usr/bin/Ruby20 Kod:
C:\Program Files (x86)\Ruby200\bin\Ruby.exe: no Ruby script found in input (Load Error) |
Jag körde återigen:
gem install mysql2 Config.yml som ligger i Ruby-katalogen ser ut så här: Kod:
# This configuration file contains the absolute path locations of all |
Citat:
Men som sagt... Kör för guds skull in Linux om du ska utveckla i Ruby. Det kommer spara dig åtskilliga timmar. |
Kan inte annat än hålla med. Skulle rekommendera en vagrant-installation, men för det behövs också Ruby :) Men en virtualbox installation med en headless ubuntu/debian/vadsom vore nog bra mycket smidigare än att jävlas i windows. I stort sett alla servrar som inte kör microsoft-applikationer (MSSQL, .NET osv) kör ju just *nix och därmed optimeras installationsförfaranden för just de plattformarna.
|
Linux är inte intressant och jag har Oracle Virtual Box installerad (med Ubuntu 12.04 LTS), men själva syftet är att installera och köra Ruby på just Windowsplattformen så att köra i Linux är helt ointressant.
Jag har kört C, C++, Cobol, Pascal, Visual Basic, C#, PHP i både Windows och Linuxplattformarna. Nu håller jag på med att få Ruby att fungera i Windows 7. Jag har fått alla tidigare testprogram att fungera i Ruby, men nu verkar det som att när man installerar gem-paket så ser allt bra ut förutom att inget av de externa men installerade gem-paketen fungerar att anropa via require("<gem-paket>"). Jag la upp det simplaste exemplet (med en require och en puts-rad) och testade: Kod:
#!usr/bin/ruby20 - Alla visas när man kör; gem list - Ingen av dem funkar med require("<gem-packet>") - Kommenterar jag bort alla rader med require, så funkar appen Funderingar: Jag har kollat på massor av webbsidor med instruktioner för hur man installerar Ruby, men det verkar vara en implicit kunskap om hur man bygger gem-paket efter installation som inte förmedlas på dessa webbsidor. Om jag förstått det hela rätt så kan man "bygga" om vissa komponenter man laddar ner för att göra dem till "paket" som kan inkluderas med require. Jag har inte hittat något fungerande exempel på hur det går till. När man laddar ner Ruby för Windows så medföljer MinGW som är en typ av Minimalistisk C kompilator för att native-kompilera C-program. Ruby i sig självt är skrivet i C. Precis som PHP och Python. |
Citat:
|
Ja nåt fel är det någonstans för jag ser att det finns andra som fått det att fungera:
Exempel: http://beans.seartipy.com/2008/06/09...ndows-vistaxp/ Jag testade att uppdatera gem-systemet i sig med kommandot: Kod:
gem update --system Sen körde jag uppdatering av de paket jag installerat: Kod:
gem update Jag såg bland annat att Bigdecimal uppdaterades och att jag fick följande information: Kod:
Updating installed gems Jag har förstått att det är <namespace> eller <module> man ska ha som parameter vid require(<parameter>) och att <gem-packetname> är något annat egentligen. men att det är vanligt att man döper dem till samma. Jag får forska vidare.... |
Nu tror jag att jag hittat en viktig orsak till problemet med require.
Jag misstänkte att det kunde ha med sökvägar till filerna att göra så jag grottade ner mig i filstrukturen. Jag har nu installerat Ruby i katalogen "C:\Projects\Ruby200" Det visar sig att modulerna som följer med Ruby från start ligger i katalogen: Kod:
C:\\Projects\\Ruby200\\lib\\ruby\\2.0.0\\ Kod:
C:\Projects\Ruby200\lib\ruby\gems\2.0.0\gems\csvkit-0.1.3\lib\csvkit.rb" Kod:
require("open3") # funkar för open3 ingår från början i Ruby Kod:
require("C:\\Projects\\Ruby200\\lib\\ruby\\gems\\2.0.0\\gems\\csvkit-0.1.3\\lib\\csvkit") Nu får jag inget körfel när jag specar sökvägen hela vägen ner till csvkit.rb som modulens laddfil heter. Nu har jag i alla fall förstått vad felet beror på i grunden. Nu är nästa steg att ta reda på hur man kan lösa problemet. Jag läste även att Ryby-projektet sedan version 1.9.2 har gjort en break på bakåtkompatibiliteten för sökvägarna. Så exempelvis current directory (".\") inte längre ingår i sökpathen. Det borde finnas en inställning jag kan ändra för att detta ska fungera globalt, för mig, men har inte hittat den ännu. Men om jag förstår det rätt så ligger alla extra installerade gems flera nivåer djupare i filstrukturen och man måste veta exakt version och så för att det ska gå att inkludera i källkoden. Jag har inte hittat någon dokumentation på detta ännu, men det borde rimligen finnas någonstans. |
Skulle inte den här tråden handla om Phalanger...?
Nu är det över 3 sidor som det ens nämndes i råden. Senaste sidorna har istället handlar om Ruby som har extremt lite att göra med både PHP och .Net, och därmed även Phalanger. Vi borde försöka ha lite bättre forumdisciplin här tycker jag :) |
Citat:
Kod:
File.join('din', 'path', 'här') Citat:
Conny: Du kanske ska skapa en egen tråd för Ruby istället? |
Alla tider är GMT +2. Klockan är nu 17:57. |
Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson