Plone 3

Opublikowane przez Jarosław Zabiełło Sun, 26 Aug 2007 20:32:00 GMT

Niedawno wyszła finalna wersja świetnego CMSPlone 3. Pomijając nowe funkcjonalności, muszę przyznać że poprawa wydajności jest imponująca. Upgrade z poprzedniej wersji 2.5 także przebiegł błyskawicznie i bez problemów.

Czytaj dalej...

Tagi ,  | brak comments

Aplikacja webowa - wybór technologii

Opublikowane przez Jarosław Zabiełło Sat, 25 Aug 2007 19:22:00 GMT

Dość często spotykam się z prośbą o to, jaką technologię (i framework) bym polecił do tworzenia aplikacji webowych. Dziedzina aplikacji webowych rozwija się bardzo prężnie i trudno tak naprawdę przewidzieć, co będzie najlepszym wyborem za parę lat. Niniejszy artykuł stanowi krótkie podsumowanie moich doświadczeń w tej dziedzinie na dzień dzisiejszy.

Czytaj dalej...

Tagi , , , , ,  | 97 comments

Dive into Python po polsku

Opublikowane przez Jarosław Zabiełło Wed, 08 Aug 2007 10:55:00 GMT

Zostały zakończone prace nad przetłumaczeniem na język polski bardzo dobrego wprowadzenia do Pythona – Dive Into Python.

Tagi  | 3 comments

Darmowy Wing IDE 101

Opublikowane przez Jarosław Zabiełło Sat, 04 Aug 2007 16:10:00 GMT

Firma Wingware znana z jednego z najlepszych IDE do Pythona, wypuściła darmową, okrojoną wersję swojego produktu – Wing IDE 101. Niestety, pozbawili go tego, co jest największą siłą pełnej wersji Wing IDE Pro – doskonałego uzupełniania kodu (włącznie z kodem importowanych bibliotek standardowych). Czyli w sumie nie wróżę mu wielkiej popularności, bo inne, darmowe IDE, posiadają znacznie lepsze uzupełnianie kodu niż Wing IDE 101.

Tagi ,  | 5 comments

Ruby to czy Python?

Opublikowane przez Jarosław Zabiełło Sat, 16 Jun 2007 00:13:00 GMT

Od czasu do czasu w środowisku rubistów pojawia się propozycja dodania do Ruby elementów składni Pythona . Chociaż składnia Ruby jest bardzo ładna i czytelna, to czasami chciałoby się aby Ruby (opcjonalnie) dopuszczał używanie wcięć tak, jak w Pythonie.

Czytaj dalej...

Tagi ,  | 7 comments

Python, SOAP, REST i Rails

Opublikowane przez Jarosław Zabiełło Fri, 23 Mar 2007 00:50:00 GMT

Ostatnie problemy z podłączeniem się z poziomu Pythona do do web serwisów napisanych w C#/.NET zmusiły mnie do głębszego spojrzenia na kwestię promowanego przez Microsoft (i kiedyś Macromedię1) tworzenia aplikacji za pomocą web serwisów i związanego z nim protokołu SOAP. Może wpierw krótko naświetlę problem jaki napotkałem w Pythonie.

Czytaj dalej...

Tagi , , , ,  | 9 comments

MySQLdb i problem polskich znaków

Opublikowane przez Jarosław Zabiełło Fri, 16 Mar 2007 01:36:00 GMT

W końcu pojawiła się wersja stabilna pythonowej biblioteki MySQLdb 1.2.2. Co ciekawsze, jest dostępna instalacja w formie pakieru egg zarówno dla Pythona 2.4 jak i 2.5. Nie trzeba też już więcej używać instalatorów binarnych pod windozą. Wystarczy (zakładając że mamy zainstalowane setuptoolsy) wykonać komendę:

easy_install -U MySQL_python

Osoby używające Django i MySQL5 muszą pamiętać aby dodać dodatkową opcję do settings.py.

Czytaj dalej...

Tagi , ,  | 5 comments

Active Python 2.5

Opublikowane przez Jarosław Zabiełło Thu, 15 Mar 2007 08:31:00 GMT

Po długiej przerwie pokazał się w końcu ActivePython 2.5, popularna, darmowa instalacja Pythona zawierająca PythonWin IDE (to tylko dla win32) i (jak zawsze) sporo dokumentacji oraz tutoriali w wygodnym formacie chm (m.in. zawarto książkę Diving into Python).

Tagi  | 3 comments

Irlandia, Python i Ruby

Opublikowane przez Jarosław Zabiełło Sun, 11 Mar 2007 00:02:00 GMT

W najbliższą środę o 19 w Dublinie ma mieć miejsce spotkanie miłośników Pythona. Dodatkowe informacje na Python Ireland i na założonym w tym celu Wiki . Jestem ciekaw jak w tym zdominowanym przez .NET miejscu działają lokalni pythonistas. Tak swoją droga, to chętnie bym pozbierał polskich (choć nie tylko) programistów w Irlandii aby stworzyć coś na wzór polskiego bootstrapa. Myślę że dużo sensu ma połączenie grup Pythona i Rubiego. Jeśli uda mi się dotrzeć na dublińskie spotkanie spróbuję poruszyć tą kwestię.

Appendix: Właśnie się dowiedziałem że dzień wcześniej ma miejsce spotkanie grupy Ruby Ireland. :)

Tagi , ,  | 7 comments

PHP w Pythonie (WSGI)

Opublikowane przez Jarosław Zabiełło Thu, 15 Feb 2007 00:29:00 GMT

Osobiście tego nie testowałem, ale brzmi interesująco: wphp to moduł WSGI możliwiający integrację języka PHP z dowolnym (pythonowym) frameworkiem opartym na standardzie WSGI.

Tagi , ,  | 14 comments

SQLAlchemy - pythonowy ORM

Opublikowane przez Jarosław Zabiełło Wed, 14 Feb 2007 00:31:00 GMT

Użytkownicy Railsów mają ułatwione zadanie z użyciem baz danych. Mają swój Active Record, ładny i czytelny ORM. Może nie posiada on ani szybkości ani możliwości takich jak pythonowy SQLAlchemy, ale jest względnie elegancki1 i prosty do nauki.

W świecie ORM’ów Pythona do niedawna królował SQLObject ale jest bardzo mocno wypierany przez znacznie potężniejszy SQLAlchemy. Niestet, SA nie jest specjalnie łatwy do opanowania. Szczególnie mętne są różne opisy rozpoczęcia pracy z SA. Preferownych jest wiele styli, zupełnie wbrew pythonowemu paradygmatowi o jednej, zalecanej drodze postępowania. Jest też moduł WSGI Alchemyware która działa w miarę dobrze z jednym wyjątkiem – źle działa z bazą MSSQL.

Elixir (SQLAlchemy + składnia Active Record)

Biblioteka Elixir ma szansę stać się hitem dla Pythona, bo jest wrapperem na mocny ORM jakim jest SQLAlchemy. Elixir udostępnia bardzo ładną składnię wzorowaną na railsowym Active Record.

Migrate (SQLAlchemy + migracje)

SQLAlchemy doczekało się też projektu implementującego wersjonowanie struktury bazy – Migrate


1 Można czepiać się składni :conditions => “która wymaga klepania SQL’a”, ale to można poprawić za pomocą pluginu ez_where. Szkoda że to nie jest standardowo dodane do Active Record.

Tagi ,  | 2 comments

Zbuduj własny framework WSGI

Opublikowane przez Jarosław Zabiełło Sat, 10 Feb 2007 11:36:00 GMT

A artykule Why so many Python web frameworks? pokazano jak 60 linijkach kodu Pythona zbudować własny framework MVC oparty o komponenty zgodne ze standardem WSGI (zobacz też A Do-It-Yourself Framework). Dzięki pojawiającej się coraz większej liście komponentów WSGI możemy uzyskać elastyczność znacznie przekraczającą monolityczne rozwiązania. Przykładem gotowego, dobrego frameworka, w pełni opartego na WSGI, jest Pylons.

Tagi ,  | 3 comments

Jython 2.2beta1

Opublikowane przez Jarosław Zabiełło Fri, 09 Feb 2007 21:51:00 GMT

Pogłoski o przedwczesnej śmierci Jythona (javowej implementacji Pythona), są chyba przesadzone. Właśnie wyszła kolejna wersja 2.2 beta1. Instalacja:

java -jar jython_installer-2.2b1.jar

Tagi , ,  | 4 comments

Porównanie wydajności frameworków

Opublikowane przez Jarosław Zabiełło Sun, 04 Feb 2007 21:54:00 GMT

Ciekawe i dosyć dokładne porównanie wydajności paru frameworków:

Django bez trudu zdeklasowało konkurencję. Szkoda, że w porównaniu nie uwzględniono Pylonsów i CakePHP. Bardzo też dziwne, że nowy Rails 1.2.1 w tych testach jest mocno wolniejszy od starszej wersji 1.1.6. Frameworki pehapowe okazały się najwolniejsze. Najgorszy okazał się pehapowy Symfony. Jest skomplikowany i wolny, 35x wolniejszy od Django!

Tagi , , , , , , , ,  | 15 comments

Szablony i wzorzec MVC - cz. III

Opublikowane przez Jarosław Zabiełło Sun, 14 Jan 2007 03:25:00 GMT

W poprzedniej części omówiono szablony dedykowane głównie do współpracy z designerami bojącymi się programować. Były to albo szablony wkładające swoją logikę do znaczników XML/XHTML (ZPT, SimpleTAL, Kid, Genshi, MasterView, PHP TAL), albo szablony posiadające swój własny, specjalizowany język (Smarty, Django, Jinja, Liquid). W założeniu taki język miał być prostym substytutem języka używanego w warstwie kontrolera. Szablony tego typu może są wygodne dla designera, ale na pewno nie dla programisty, który musi je przygotować. Po pierwsze, trzeba się uczyć kolejnego języka… szablonów. Po drugie, wszystkie tego typu języki są ograniczające dla programisty. Mimo że pozornie prostsze, w praktyce są bardziej złożone i to nawet dla designera. Np. szablony Django i Jinja nie posiadają żadnej składni na określenie trywialnego warunku większości, mniejszości:

{{ x }} jest 
{% if x > y %} 
    większe 
{% else %} 
    mniejsze 
{% endif %} 
od {{ y }}

Powoduje to masę kłopotów dla programisty1. Prymitywna składnia szablonu wymusza więc kupę dodatkowej pracy. O ileż prościej jest użyć po prostu pełnej składni języka tak jak to robią szablony Cheetah:

$x jest 
# if x > y 
    większe 
# else 
    mniejsze 
# endif  
od $y

Dochodzimy tu więc do sytuacji kiedy byśmy chcieli coś bardziej elastycznego – pełnego dostępu do języka programowania. Taka sytuacja jest pożądana wtedy kiedy i tak szablony budują programiści na podstawie dostarczonego czystego kodu HTML od designerów.

PHP

Język PHP jest dosyć specyficzny, bo w istocie jest to język szablonów. Tzn. pierwotnie tak został stworzony, ale z czasem się skomplikował że dostąpił miana języka skryptowego. Ale jego korzenie widać w składni, która z definicji jest zagnieżdżaniem instrukcji PHP wewnątrz kodu HTML. Idąc tym tropem, niektórzy pomyśleli, że nie ma sensu wymyślać dodatkową składnię. Wystarczy użyć PHP w odpowiedni sposób. I tak powstały szablony Savant.

Właściwie to Savant nie powinny nazywać się szablonami, bo to nic innego jak PHP użyty w taki sposób, aby rozdzielić warstwę prezentacji, od wartwy logiki biznesowej. A skoro to PHP, to odpada nauka dodatkowej składni oraz potrzeby kompilacji specjalizowanego języka szablonów do końcowego kodu PHP (jak to ma miejsce w szablonach Smarty).

Czy takie podejście jest lepsze, czy gorsze, to już każdy może sobie ocenić. Moim zdaniem PHP ma na tyle mętną składnię, że warstwa prezentacji używająca Smarty2 jest bardziej czytelna niż czysty PHP jaki używają Savant.

Ruby

Kiedy mówimy o Ruby w kontekście stron internetowych to najczęściej mamy na myśli jego najsłynniejszy framework – Rails. Ruby sam w sobie nie jest związany z HTML tak jak PHP. Rails do szablonów używa biblioteki ERb (ang. “embed Ruby”, czyli “zagnieżdżony Ruby”) Składnia jest bardzo podobna do PHP, JSP czy ASP. Ruby jest tu językiem zagnieżdżonym w HTML.

<%= x %> jest 
<% if x > y %> 
    większe 
<% else %>
    mniejsze 
<% end %>
od <%= y %>

Python

Jeśli chodzi o Pythona to istnieje cała masa systemów szablonowych. Ograniczę się do paru, tych bardziej interesujących.

Spyce

Szablony Spyce zostało stworzone jako pythonowa konkurencja dla PHP. Podobnie potrafią przeplatać język (tu: Pythona) z tagami HTML. Najbardziej oczywista przewaga Spyce wynika z faktu używania języka Python, który jest znacznie lepiej zaprojektowany i posiada dużo więcej możliwości niż PHP. Spyce potrafii budować własne znaczniki (custom tags, podobnie jak to potrafią javowe JSP) oraz łatwiej w nich zbudować komponenty, kod do wielokrotnego użytku.

Myghty

Szablony Myghty powstały pierwotnie jako pythonowa implementacja systemu komponentowego Mason dla Perla. Mimo wielu podobieństw, Myghty są znacznie potężniejsze o Masona, np. intensywnie wykorzystują obiektowość Pythona (zobacz różnice). Od początku Myghty powstało z myślą o dużych obciążeniach, ciężkich, profesjonalnych zastosowaniach. Mają doskonały własny cache, są bardzo szybkie, odporne na wątki, świetnie się nadają do tworzenia komponentów.

Programiści Pythona bardzo cenią sobie filozofię tego języka (która podkreśla prostotę, oczywistość i elegancję składni). Problem w tym, że Myghty dla pythonowców jest zbyt podobne do Perla. Są za mało “pythonic” – pythonowe. Dodatkowo, poprzez podkreślanie swojej komponentowości, Myghty niektórym zbyt kojarzy się z filozofią komponentową frameworku ASP.NET (a wzorzec MVC wydaje się być bardziej przejrzysty niż wzorzec sterowanych zdarzeniami komponentów). Myghty, jako system komponentowy, może być używane w stylu MVC, ale nie jest to takie naturalne i oczywiste. (Na szczęście, wszystko zmienił Pylons który zapewnia przejrzystą pracę zgodną z wzorcem MVC i Myghty są tam zredukowane tylko do obsługi szablonów szablonów. Sterowaniem zajmują się kontrolery Pylonsa a nie Myghty).

Cheetah

Szablony Cheetah posiadają jedną z najbardziej czytelnych i eleganckich składni. Autorzy wzorowali się trochę na javowych Velocity i Webmacro. Tym, którzy cenią sobie czystość Pythona z prostotą składni szablonów z pewnością Cheetah mogą przypaść do gustu. Przez dłuższy czas były moimi ulubionymi szablonami i do te pory lubię ich klarowność. Cheetah posiadają elegancką składnię obiektowego budowania szablonów potomnych na bazie już istniejących. Myghty też to potrafi, ale Cheetah to ma bardzo czytelnie zrobione. Cheetah są również bardzo szybkie.

Mako

Mako to najmłodsze dziecko stworzone przez programistów Pylonsów. Powstały na bazie doświadczeń i najlepszych cech szablonów Myghty, Cheetah, Django/Jinja czy Smarty. Największą ich zaletą jest ogromna szybkość i pythonowa filozofia pracy. Programiści Pythona mogą zauważyć, że składnia Mako jest bardzo bliska sposobowi pracy w samym języku Python. Mako posiadają wielką łatwość tworzenia komponentów, ale w sposób bardzo podobny do tego jak Python wykorzystuje swoje moduły. Szablony można także rozszerzać na drodze obiektowego dziedziczenia. Dziedziczenie szablonów może być określane w sposób dynamiczny (tego już nie potrafią np. Cheetah). Dowolny fragment szablonu można również zamienić na komponent z własnym cache. Mako posiadają także składnię modyfikatorów, które spopularyzowane zostały przez Smarty. Działają one jak uniksowe pipes (${zmienna|filter}.

Mako automatycznie kompilują swój kod do modułów Pythona. Można je więc debugować tak jak zwykły kod Pythona (Cheeatah wymaga ręcznej kompilacji). Można je bez problemu używać jako niezależną bibliotekę. Nie są one zależne od jakiegokolwiek frameworku. Można je zintegrować z dowolnym frameworkiem używającym standardu3 WSGI. Użytkownicy frameworka Pylons prawie nic nie muszą robić, bo Mako są już tam przygotowane do pracy.

Ogólnie rzecz biorąc, Mako to – moim zdaniem – najlepszy aktualnie istniejący system szablonów dla Pythona.

Zaś co do frameworków… to coraz bardziej zaczynam nabierać pewności, że przyszłość nie należy ani do Django, ani do Railsów. Nic nie może równać się z możliwościami czystego, 100% frameworka WSGI. Takim jest np. Pylons. Ale o tym, i o “bitwie” Pylons vs. Django i Rails, napiszę już innym razem.

Appendix 2007-01-29: Zobacz też szablony Haml .


1 Poprawnie rzecz mówiąc, powinien napisać swojego helpera. Jeśli więc chcemy wyświetlić w pętli rekordy z bazy, a widok jest czuły na zawartość tych danych, to powinniśmy cała listę rekordów wrzucić do helplera, przeiterować w pętli, dodać dodatkową zmienną i dopiero tak zmodyfikowaną listę przekazać do szablonu.

2 Smarty mimo posiadania własnej składni pozwala na odpalanie pełnego języka PHP: {php}print phpinfo();{/php}. Tak praktyka jest jednak odradzana, bo wprowadza jeszcze większy bałagan niż już jest w PHP.

3 Zobacz artykuł Introducing WSGI: Python’s Secret Web Weapon oraz prezentację koncepcji WSGI na video.

Tagi , , , , , , , , , , , , ,  | 15 comments

Python vs. Ruby 1.9 YARV. Cz. II

Opublikowane przez Jarosław Zabiełło Sat, 06 Jan 2007 17:44:00 GMT

Z wcześniejszych testów wynikało że Ruby 1.9 (wykorzystujący wirtualną maszynę YARV) jest szybszy od Pythona. Aby zwolennicy Rubiego zbyt się nie cieszyli, przygotowałem test na wywołania rekurencyjne. Najcięższą jest tu funkcja rekurencyjna. Długość 7 znaków daje prawie 900 tys. wywołań rekurencyjnych i w miarę sensowne czasy aby coś zobaczyć. Postanowiłem ją wziąć na rozkład. Tym razem z 10 prób brany jest najlepszy (najkrótszy) wynik.

Python:

try:
  import psyco
  psyco.all()
except:
  pass

from time import time
def wariancje(s, n):
    if n==0:
      yield []
    else:
        for i in xrange(len(s)):
            for c in wariancje(s, n-1):
                yield [s[i]] + c
s = "abcdefg"
nelem = len(s)
i = 0
results = []
for unused in range(10):
  t = time()
  for s in wariancje(s, nelem):
    i += 1
  tmp = time() - t
  results.append(tmp)
  print tmp
print min(results), max(results), nelem, i

Ruby

def wariancje(s, n)
  if n == 0
    yield []
  else
    s.size.times do |i|
      wariancje(s, n-1) { |c| yield [s[i]] + c }
    end
  end
end
t = Time.now
s = "abcdefg"
size = s.size
i = 0
results = []
10.times do
  t = Time.now
  wariancje(s, size) do
    i += 1
  end
  tmp = Time.now - t
  results << tmp
  puts tmp
end
puts "\n#{results.min}, #{results.max}, #{size}, #{i}"

Rezultat:

  1. Python 2.5: 3.86356806755 s.
  2. Python 2.4 4.09678792953 s.
  3. Ruby 1.9: 6.418052 s.
  4. Ruby 1.8.5: 8.000223 s.

Tym razem Python nie dał szans Rubiemu. Jest od niego wyraźnie szybszy. Jednak na obronę można powiedzieć że YARV nie jest tu jeszcze zbyt zoptymalizowany. Wiele opcji optymalizacyjnych ma po prostu wyłączonych, Ruby 1.9 i YARV to na razie kod eksperymentalny. Na razie więc dominacja wydajnościowa Pythona jest niepodważalna.

Tagi , , ,  | 10 comments

Ruby 1.9 (YARV) vs. Python, Lua & PHP

Opublikowane przez Jarosław Zabiełło Mon, 01 Jan 2007 18:36:00 GMT

Korzystając z tego, że niedawno do repozytorium Rubiego został dodany YARV (wirtualna maszyna Rubiego) pokusiłem się o małe porównanie wydajności. Jako test użyłem prostego programu jaki pojawił się na liście pl.comp.lang.pyhon (musiałem tylko trochę zwiększyć pętle do 10 milionów iteracji, aby były widoczne jakieś wyniki) Użyty sprzęt: Athlon64 3700+, 64bit Ubuntu 6.0.6.

Sprawdziłem też z ciekawości PHP 5.2 na tym samym sprzęcie. Dla tak prostego testu powinien móc dać z siebie wszystko. Jest jednak wolniejszy od Rubiego 1.9.

Kod dla Pythona:

import time
t=time.time()
a=0
for i in xrange(10000000):
    a += i
print a
print time.time() - t
Kod dla Lua:
t = os.clock()
a = 0
for i = 1,10000000 do
    a=a+i
end
print(a)
print(os.clock() - t)

Kod dla Rubiego:

t = Time.now
a = 0
for i in 1..10_000_000
  a = a+i
end
puts a
puts Time.now - t

Kod dla PHP:

<?php
function microtime_float() {
 $time = microtime();
 return (double)substr($time, 11) + (double)substr($time, 0, 8);
}
$t =  microtime_float();
$a = 0;
for ($i = 0; $i < 10000000; $i++) {
  $a += $i;
}
print "$a\n";
print  microtime_float()- $t;
?>

Wyniki:

  1. Lua: 1.14 s
  2. Ruby 1.9: 1.49 s
  3. PHP 5.2: 1.74 s
  4. Python 2.5: 2.64 s
  5. Python 2.4.3: 2.72 s
  6. Ruby 1.8.5: 3.83 s.

Drugie podejście

Tym razem wynik uśredniam dla 10 prób. Zwiększyłem ilość iteracji do 20 mln. No i… Ruby 1.9 pobił wszystko. Zarówno Pythona jak i Lua! (PHP 5.2 po 30 sek. zgłosił timeout. Musiałem więc uśrednić po 5 wynikach.)

PYTHON

import time
def bench():
    a, t = 0, time.time()
    for i in xrange(20000000):
        a+=i
    return time.time()-t
result = 0
for i in range(10):
  result += bench()
print result / 10.0

RUBY

def bench
  a, t = 0, Time.now
  20_000_000.times { |i| a += i }
  Time.now - t
end
result = 0
10.times { |i| result += bench }
puts result / 10

LUA

function bench()
  a = 0
  t = os.time()
  for i = 1, 20000000 do
    a = a + i
  end
  return os.time() - t
end
result = 0
for x = 1,10 do
  result = result + bench()
end
print(result/10)

PHP

<?php
function bench() {
  $a = 0;
  $t =  time();
  for ($i = 0; $i < 20000000; $i++) $a += $i;
  return time() - $t;
}
$result = 0;
for ($x = 1; $x <= 5; $x++) $result += bench();
print $result / 5.0;
?>

Wyniki

  1. Ruby 1.9: 2.0953268 s.
  2. Lua 5.1: 2.4 s.
  3. Python 2.5: 2.49481592178 s.
  4. Python 2.4.3: 2.71687791348 s.
  5. PHP 5.2: 4.2 s.
  6. Ruby 1.8.5: 9.0153751 s.

Jestem ciekaw kiedy wyjdzie Rails dostosowany do Ruby 1.9. Zapowiada się bardzo obiecująco!

Posted in , ,  | Tagi , , , , ,  | 19 comments

Python 2.5 - mod_python, MySQLdb i PythonWin

Opublikowane przez Jarosław Zabiełło Tue, 26 Dec 2006 03:55:00 GMT

W końcu nie ma już chyba powodu aby nie używać nowego Pythona 2.5 pod windowsami. Od niedawna jest dostępna binarna instalka mod_pythona dla Apache 2.2. Jest też binarna instalka MySQLdb. Mimo że firma ActiveState coś zasnęła i zatrzymała się na razie na Pythonie 2.4.3, można sobie ściągnąć oddzielnie edytor PythonWin. Jest bardzo szybki i wygodny.

Posted in  | Tagi  | brak comments

Subversion /etc/init.d script

Opublikowane przez Jarosław Zabiełło Sat, 07 Oct 2006 00:57:00 GMT

Postanowiłem troszkę poprawić napisany wcześniej skrypt startowy do Subversion. Dorzuciłem też wersję w Pythonie.

#!/usr/bin/env ruby

VERBOSE = true
USER = "nobody"
APP = "/usr/bin/svnserve"
DIR = "/home/svn-repository"
PID = "/var/run/svnserve.pid"

def script action
  def start
    unless File.exists?(PID)
      system %Q|su -c "#{APP} -d -r #{DIR}" #{USER}|
      system "echo `pidof -o %PPID #{APP}` > #{PID}"
    end
  end
  def stop
    return false unless File.exists?(PID)
    system "/bin/kill -TERM #{File.read(PID)}"
    system "/bin/rm -f #{PID}"
    true
  end
  puts "#{APP} #{action}"  if VERBOSE
  $defout.flush # unbuffered output
  case action
    when :start
      start
    when :stop
      puts "#{File.basename(APP)} cannot be stopped because it cannot find #{PID}" unless stop
    when :restart
      stop
      start
  end
end

if %w{start stop restart}.include? ARGV.first
  script ARGV.first.to_sym
else
  puts "Usage: sudo #{__FILE__} {start|stop|restart}"
end

Ten sam skrypt w Pythonie:

#!/usr/bin/env python

import os, sys

VERBOSE = True
USER = "nobody"
APP = "/usr/bin/svnserve"
DIR = "/home/svn-repository"
PID = "/var/run/svnserve.pid"

def script(action):
  def start():
    if not os.path.exists(PID):
      os.system('su -c "%s -d -r %s" %s' % (APP, DIR, USER))
      os.system('echo `pidof -o %%PPID %s` > %s' % (APP, PID))
  def stop():
    if not os.path.exists(PID): return False
    os.system('/bin/kill -TERM %s' % file(PID).read())
    return True
  if VERBOSE: print "%s %s" % (APP, action),
  if action == 'start':
    start()
  elif action == 'stop':
    if not stop():
      print "%s cannot be stopped because it cannot find %s" % (os.path.basename(APP), PID)
  elif action == 'restart':
    stop()
    start()

if len(sys.argv) == 2 and sys.argv[1] in ('start', 'stop', 'restart'):
  script(sys.argv[1])
else:
  if VERBOSE:  print "Usage: sudo %s {start|stop|restart}" % sys.argv[0]

Posted in ,  | Tagi , ,  | 2 comments

IronPython 1.o

Opublikowane przez Jarosław Zabiełło Wed, 06 Sep 2006 15:10:00 GMT

W dniu wczorajszym (5 września 2006) światło dzienne ujrzała wersja 1.0 projektu Iron Python – implementacji języka Python działającej na platformie .NET i generującej kod 100% kompatybilny z CLR (Common Language Runtime).

Iron Python może być w zasadzie uważany za produkt sygnowany przez Microsoft (pliki DLL są podpisane certyfikatem cyfrowym firmy Microsoft) i jako taki na pewno zyskuje sobie spore grono zwolenników używających go zarówno jako języka do tworzenia aplikacji jak i języka do osadzania w swoich własnych aplikacjach.

Do uruchomienia IronPython’a wymagany jest .NET Framework w wersji 2.0, gdyż wykorzystuje on jej rozszerzenia, jak na przykład typy generyczne, czy metody dynamiczne. Deweloperzy otrzymują do ręki, podobnie jak w standardowym Pythonie, interaktywną konsolę z interpreterem języka, ale także możliwość statycznej kompilacji do plików wykonywalnych “exe”, czy bibliotek “dll”. Pomimo zgodności samego języka, obie implementacje jednak się różnią, jak choćby nieobecnością wielu standardowych modułów. Szczegółowe informacje o różnicach można znaleźć na witrynie projektu.

Zobacz artykuł “Microsoft i dynamiczne języki”.

Zobacz stronę “Jim Hugunin’s Thinking Dynamic ” zawierającą informację autora IronPythona o wydaniu wersji 1.0.

Zobacz prezentację wideo: The Screening Room. #8 August 2006: IronPython (dodane: 10 września 2006)

Posted in  | Tagi , ,  | 1 comment

Starsze wpisy: 1 2 3