From michael.kroell at uibk.ac.at Thu May 3 01:27:31 2007 From: michael.kroell at uibk.ac.at (=?ISO-8859-1?Q?Michael_Kr=F6ll?=) Date: Thu, 03 May 2007 10:27:31 +0200 Subject: [Vienna-pm] Jobs In-Reply-To: <20070425053022.GG1160@domm2.zsi.at> References: <20070425053022.GG1160@domm2.zsi.at> Message-ID: <46399CF3.30404@uibk.ac.at> Thomas Klausner wrote: > Bei uns (3united / Verisign) sind 2 Perl-Jobs frei: Mittlerweile gibt's dort 4 freie Perl-Jobs! http://www.jobpilot.at/misc/adframe/jobpilot/7d7/8/1888061.htm Gesucht wird f?r die B?ros in Salzburg und Wien. Erfahrung im Bereich Web w?re auch ein Plus, ein neuer leicht angepasster Ausschreibungstext ist gerade unterwegs. Alle 4 w?rden im gleichen Team wie Domm und ich arbeiten. lg, michael -- 063A F25E B064 A98F A479 1690 78CD D023 5E2A 6688 http://zis.uibk.ac.at/.m/uibk.ac.at_pgp_pubkey.asc From gooly at gmx.at Mon May 7 06:15:45 2007 From: gooly at gmx.at (gooly at gmx.at) Date: Mon, 7 May 2007 15:15:45 +0200 Subject: [Vienna-pm] =?iso-8859-15?q?kl=2E_=2Ekde/Autostart_=C4rgernis?= Message-ID: <200705071515.45529.gooly@gmx.at> Hi, seit einiger Zeit (update auf KDE 9.5.6 ?) geht ein Programm nicht mehr, wenn es aus .kde/Autostart gestartet wird, es bricht ab ohne einen Mucks? Starte ich das selbe Programm aber selber, geht alles ohne Probleme? In meinem .kde/Autostart liegt mein startPrgs das auch ausgef?hrt wird. Es hat zZ nur zwei Zeilen: cd /home/cas/Perl/WEB_Perl/Tel ./chgTel.pl Login >/home.. /loginTel.log 2>&1 & Damit soll mein VoIP-Tel (IP:10.10.10.77) ein/ausgeschaltet werden.. Aber beim Einschalten des PC ist dies das letzte im Log-File: chgTel 3: startet Das hei?t, $ua->request(GET 'http://10.10.10.77/admin/basic'); wird nicht gestartet - beendet - sonst 'was? Das Tel selber r?hrt sich nicht. Wenn ich danach genau dies Programm selber ausf?hre, h?re ich als erstes kleine, leise Gr?usche und dann gehts es 'an'. Die 10 Sec Timeout habe ich na?rlich abgewartet. Den Anfang habe ich unten angef?gt. #! /usr/bin/perl # use LWP::UserAgent; use HTTP::Request::Common; use HTML::Form; $|++; print "chgTel 1:\tstartet\n" my $ua = LWP::UserAgent->new; print "chgTel 2:\tstartet\n" $ua->timeout(10); print "chgTel 3:\tstartet\n" my $res = $ua->request(GET 'http://10.10.10.77/admin/basic'); print "chgTel 4:\tstartet\n" if ($res->is_success) { print "chgTel 5:\tTel-Page loaded\n"; # or whatever } else { print "chgTel 6:\tTel-Page FAIL:$res->status_line< "; my $n = 0; while ( ! $res->is_success ) { print "."; sleep 2; $res = $ua->request(GET 'http://10.10.10.77/admin/basic'); die "uuups?? Kann die html-Seite nicht laden??\n" if ($n++ > 5); } print " OK\n"; } ... From michael.kroell at uibk.ac.at Tue May 8 02:04:22 2007 From: michael.kroell at uibk.ac.at (=?ISO-8859-1?Q?Michael_Kr=F6ll?=) Date: Tue, 08 May 2007 11:04:22 +0200 Subject: [Vienna-pm] YAPC Europe 2007 Reminder - CFP and CFH Deadlines Approaching Message-ID: <46403D16.3020104@uibk.ac.at> Hi, The deadline to submit Hackathon proposals for this year's YAPC Europe in Vienna is just around the corner. Please do not forget to submit your proposals by Sunday, 13th May 2007. Information on what we're looking for exactly and what we can offer to moderators (e.g. travel/accommodation refund) can be found at: http://vienna.yapceurope.org/ye2007/cfh.html The Call for Papers deadline is less than 3 weeks away from today: http://vienna.yapceurope.org/ye2007/cfp.html The theme for this year's conference is "Social Perl", which we hope will inspire submissions for this and related topics. If Perl has helped you or your company to get people together, or if you can report how Perl is "social" to other programming languages, or how Perl may profit from inspirations from other languages, we'd like to hear about it. Although this is our main topic for the conference, it will not be the only one, and as such we will also be accepting talks on just about any theme. Types of talks include 20 or 40 minutes talks, 60-90 minute tutorials, or 3 hour Hack-a-thons, BOFs or Workshops. There are still some slots free! Hope to see you in Vienna, Michael Kr?ll on behalf of Vienna.pm -- 063A F25E B064 A98F A479 1690 78CD D023 5E2A 6688 http://zis.uibk.ac.at/.m/uibk.ac.at_pgp_pubkey.asc From maros at k-1.com Tue May 15 01:55:33 2007 From: maros at k-1.com (=?ISO-8859-15?Q?Maros_Koll=E1r?=) Date: Tue, 15 May 2007 10:55:33 +0200 Subject: [Vienna-pm] I18N mit Perl Message-ID: <46497585.4090303@k-1.com> Hallo! ich bin gerade dabei eine gr??eres Framework auf dem mehrere Applikationen laufen zu internationalisieren. Diese I18N soll in bis zu mehreren Ebenen passieren: 1. Framework Basis (zb.: Framework::L10N) 2. Funktions Klassen im Framework (zb.: Framework::User::L10N) 3. Applikations Basisklassen (zb.: Myapp::L10N) 4. Funktionsklassen in der Applikation (zb.: Myapp::User::L10N) (5. Beliebig viele Klassen die von Funktionsklassen erben (zb.: Myapp::User::Admin::L10N)) Die Internationalisierung soll demenstprechung Vererbung beherschen. Wenn eine ?bersetzung nicht in der Applikationsklasse definiert ist dann soll die L10N aus der Basisklasse zum Zug kommen usw. Welches Perl Modul erf?llt diese Anforderungen, und kann au?erdem maketext (oder was ?hnliches)? Gibt es eventuell gute Tutorials? Beste Gr??e Maro? From domm at cpan.org Tue May 15 02:04:28 2007 From: domm at cpan.org (Thomas Klausner) Date: Tue, 15 May 2007 11:04:28 +0200 Subject: [Vienna-pm] I18N mit Perl In-Reply-To: <46497585.4090303@k-1.com> References: <46497585.4090303@k-1.com> Message-ID: <20070515090428.GT24297@domm2.zsi.at> Hi! On Tue, May 15, 2007 at 10:55:33AM +0200, Maros Koll?r wrote: > Hallo! SEAS! :-) > Die Internationalisierung soll demenstprechung Vererbung beherschen. > Wenn eine ?bersetzung nicht in der Applikationsklasse definiert ist dann > soll die L10N aus der Basisklasse zum Zug kommen usw. Welches Perl Modul > erf?llt diese Anforderungen, und kann au?erdem maketext (oder was > ?hnliches)? Gibt es eventuell gute Tutorials? Ganz genau weiss ich auch nix, aber das Locale::Maketext soll recht gut sein, zumindest finde ich diesen Artikel recht interessant: http://search.cpan.org/~petdance/Locale-Maketext-1.10/lib/Locale/Maketext/TPJ13.pod -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From domm at cpan.org Mon May 21 03:53:56 2007 From: domm at cpan.org (Thomas Klausner) Date: Mon, 21 May 2007 12:53:56 +0200 Subject: [Vienna-pm] Call for Votes: YAPC::Europe Hackathons Message-ID: <20070521105356.GD11302@i85.chello.at> Hi! Wie ihr vielleicht wisst, werden wir auf der YAPC::Europe 4 Hackathons anbieten: http://vienna.yapceurope.org/ye2007/cfh.html Wir haben 6 Proposals von 5 Leuten bekommen und haben uns gedacht, es waere doch nett, wenn alle Vienna.pm-Mitglieder (bzw alle, die *jetzt* auf dieser Liste subskribiert sind) mit abstimmen wuerden, welche der Hackathons ausgesucht werden sollen. Also: Weiter unten folgt die Kurzzuebersicht und die Beschreibung (soweit vorhanden) der einzelnen Hackathons. JedeR kann 1, 2, 3 und 4 Punkte vergeben. Die 4 Propsoals mit den meisten Punkten werden ausgewaehlt. Deadline fuer die Abstimmung ist DO, 24.5., 18:00 (CET) Bitte die Votes in der Form: Titel -> Punkte an die Adresse apw-orga at dmail.zsi.at schicken, also zB: i) Foo -> 4 Pkt k) Baz -> 3 Pkt m) Bar -> 2 Pkt o) Fuu -> 1 Pkt Und hier die "Kandidaten"! Hackathon-Proposals fuer YAPC::Europe 2007 ========================================== Uebersicht ---------- a) Perl6-in-Perl6 and Perl6-in-Perl5, Flavio S. Glock b) DBI, DBD::Oracle, John Scoles c) CPAN::Porters, Gabor Szabo d) Adding Tests to CPAN Modules, Gabor Szabo e) POE, Kidney Bingos f) OpenGuides, Kake ----------------------------------------------------------------- a) Perl6-in-Perl6 and Perl6-in-Perl5 ----------------------------------------------------------------- "Flavio S. Glock" I will be hosting the Perl6-in-Perl6 and Perl6-in-Perl5 hackathon in YAPC::SA (SouthAmerica) in a few days. It would nice for me if we could have a followup in Vienna. ----------------------------------------------------------------- b) DBI, DBD::Oracle ----------------------------------------------------------------- "John Scoles" I am interested the DBI, DBD::Oracle or perhaps CIG or even embedded C with Perl. I am currently the maintainer of DBD::Oracle and have worked closely with Tim Bunce and other in the DBI community. ----------------------------------------------------------------- c) CPAN::Porters ----------------------------------------------------------------- Gabor Szabo" This is a new project I have starter to work on. The objective is to increase the number of CPAN modules available as standard packages in the various Linux (BSD and other) distributions. I have started to create some stats http://www.szabgab.com/distributions/ and started to write some documents. By the time of the hackathon there should be already several CPAN modules available in Debian that I am maintaining. During the hackathon I would like to get more people involved and not only on Debian but for the other major distros as well. Maintaining such distros requires lots of manual administrative work but there is plenty of opportunities to create automations. One of the sub-projects is to make use of the dependency table created by CPANTS and maybe add some more code to CPANTS to collect some more information we need. (even if that does not directly contribute to the kwalitee factor of the modules) ----------------------------------------------------------------- d) Adding Tests to CPAN Modules ----------------------------------------------------------------- Gabor Szabo" Testing, that would be picking up several modules (probably from Phalanx http://qa.perl.org./phalanx/ but I am not sure yet) and starting to add tests to them. Tests initially might be released in CPAN::Test::Others but once the module author agrees they should go into the module itself. ----------------------------------------------------------------- e) POE ----------------------------------------------------------------- Kidney Bingos Proposal: ========= POE is a framework for cooperative, event driven multitasking in Perl. It lends itself to a mulitude of different applications and purposes including, but not limited to: - networking servers and clients; - network monitoring; - integration with existing event loops such as Glib, Event, Gtk, Tk, etc; A hackathon would be an opportunity for POE developers to: gather, discuss and exchange tips, tricks and best practises; work on long delayed POE related modules; provide advice and support to newer and novice POE users. I unfortunately can't say at this point what kind of hacking will be done. I intend to poll Rocco Caputo and the other POE developers regarding possible things to be done. Also participents on the day would probably have their own ideas. Regarding the short introduction, I intend to produce enough material to cover hopefully a diverse audience, which can be tailored on the day given the attending persons. About me: ========= I have been involved with POE development for a number of years now, including authoring and maintaining a large number of POE Components ( http://search.cpan.org/~bingos/ ) and using POE for work and public based projects. As well as that I have made a number of contributions to the POE code base. ----------------------------------------------------------------- f) OpenGuides ----------------------------------------------------------------- OpenGuides is a complete wiki-based application for running a website about some subject where geographical location is important. The most popular use at the moment is as a platform for a guide to a city - London, Oxford, Vienna, and Boston are among the major cities covered. The project has been running for over four years now, and has a small core team of programmers as well as a close-knit community of other interested parties including contributors to the various guides. The content of an OpenGuides website is managed by the Wiki::Toolkit suite of modules, and stored in your choice of SQLite, MySQL, or Postgres. OpenGuides itself provides structure and a UI layer on top of this. OpenGuides and Wiki::Toolkit are both written in Perl, and are available on CPAN. One of the major advantages of Openguides over other wiki software is its use of structured data, allowing complex queries such as "find me all the real ale pubs within 500m of King's Cross station which serve food at lunchtime" [0]. Most search results can be viewed either as a list or on a map, using the Google maps API [1]. [0] http://preview.tinyurl.com/22jlzu [1] http://preview.tinyurl.com/2rxqt8 We have many, many tasks which could be addressed at a hackfest, depending on the skills and interests of the participants. These include: - authentication Currently we use the traditional "wiki way" of not requiring any authentication at all; usernames are simply stored in a preference cookie by the user's browser. We'd like to add authentication as an option; OpenID is one possible way of going about this. - making it easier to extend the core OpenGuides package Many guide admins have written add-ons to supplement the capabilities of the OpenGuides distribution; some of these can be folded back into the core, while others only make sense for particular guides/cities/countries. Making it easier to write these extensions not only makes it more likely that people will hack on things that can eventually go into the core, it also makes it easier for people to create local extensions without having to fork the codebase. This task can be broken down into a number of possible subtasks, for example: - modularising our javascript snippets into libraries - creating an SQL query builder - refactoring the structured data handlers to allow customisation of the structured data fields - creating a template framework to allow a consistent look and feel between core OpenGuides and local extensions - "good enough" internationalisation OpenGuides' HTML is output by means of the Template Toolkit; we distribute the templates along with the Perl modules. Currently, these templates are all in English, and people wanting to run guides in different languages have to translate and maintain their own set of templates. All I'm thinking of at this stage is a way to let us distribute templates in multiple languages without significant repetition of presentation logic. - improving the full-text search The text search is handled at the Wiki::Toolkit level; the content of a page is tokenised and indexed when a page is saved. We need better canonicalisation of these tokens to allow fuzzy matching (to catch misspellings) and to make sure that punctuation is irrelevant in searching (e.g. King's Cross vs. Kings Cross). - page deletion Page deletion is irreversible at the moment, which is not a good thing. What we need to do is add "deletion" in at the Wiki::Toolkit level, by marking "deleted" pages/page versions as non-visible, and then making sure they don't get returned by queries unless specifically asked for. - JSON output / API We've always been very keen to allow data-sharing between OpenGuides and other applications. We have RDF output, but this isn't hugely programmer-friendly due to the amount of faff needed to actually get out usable information. Other, more programer-friendly outputs would be great; JSON might be a useful starting point. - non-Perl tasks Obviously this is a Perl-based conference and a Perl-based hackathon, but there are a number of other tasks which could be done by people who're interested in OpenGuides but don't feel comfortable diving straight into the code - or indeed non-Perl partners; I'll be providing one of these :) Non-Perl tasks include: template translation, user testing, writing documentation, coming up with new example designs/stylesheets. -------------------- END OF PROPOSALS ---------------------- -- #!/usr/bin/perl http://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From domm at cpan.org Thu May 24 05:31:54 2007 From: domm at cpan.org (Thomas Klausner) Date: Thu, 24 May 2007 14:31:54 +0200 Subject: [Vienna-pm] Call for Votes: YAPC::Europe Hackathons In-Reply-To: <20070521105356.GD11302@i85.chello.at> References: <20070521105356.GD11302@i85.chello.at> Message-ID: <20070524123154.GG32317@3u.vcorp.ad.vrsn.com> Hi! On Mon, May 21, 2007 at 12:53:56PM +0200, Thomas Klausner wrote: > ausgewaehlt. Deadline fuer die Abstimmung ist DO, 24.5., 18:00 (CET) Noch 3.5 Stunden! -- #!/usr/bin/perl http://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From domm at cpan.org Fri May 25 05:29:47 2007 From: domm at cpan.org (Thomas Klausner) Date: Fri, 25 May 2007 14:29:47 +0200 Subject: [Vienna-pm] pending Generalversammlung Message-ID: <20070525122947.GR6935@i85.chello.at> Hi! Wir 'muessen' wiedermal eine Generalversammlung machen und haben uns auf dem letzten YAPC-Orga Treffen MI, 13.6. als Datum ausgemacht. Aber die Location haben wir noch nicht besprochen. Irgendwelche Vorschlaege (mit WLAN!) ausser den ueblichen Verdaechtigen: - Roanhi - Aera - ?? -- #!/usr/bin/perl http://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From rl at brabbel.net Fri May 25 06:43:04 2007 From: rl at brabbel.net (Roland Lammel) Date: Fri, 25 May 2007 15:43:04 +0200 Subject: [Vienna-pm] pending Generalversammlung In-Reply-To: <20070525122947.GR6935@i85.chello.at> References: <20070525122947.GR6935@i85.chello.at> Message-ID: <9b51ffb30705250643p11d55e46xb6d32114b685f25a@mail.gmail.com> Zu dem Termin bin ich nicht in Austria (Trip durch Deutschland), d.h. ich kann ned teilnehmen. Ist das ein Problem so Generalversammlungsrechtetechnisch? Glaub nicht oder, vielleicht findet sich ja eine Vertretung. Ich werd die Finanzen vorbereiten, im Notfall m?ssen wir halt verschieben um 1 Woche. LG +rl On 5/25/07, Thomas Klausner wrote: > > Hi! > > Wir 'muessen' wiedermal eine Generalversammlung machen und haben uns auf > dem letzten YAPC-Orga Treffen MI, 13.6. als Datum ausgemacht. > > Aber die Location haben wir noch nicht besprochen. > > Irgendwelche Vorschlaege (mit WLAN!) ausser den ueblichen Verdaechtigen: > > - Roanhi > - Aera > - ?? > > > > -- > #!/usr/bin/perl http://domm.plix.at > for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} > _______________________________________________ > Vienna-pm mailing list > Vienna-pm at pm.org > http://mail.pm.org/mailman/listinfo/vienna-pm > -- Roland Lammel "Enjoy your job, make lots of money, work within the law. Choose any two." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/vienna-pm/attachments/20070525/7747ec48/attachment.html From gooly at gmx.at Fri May 25 09:09:18 2007 From: gooly at gmx.at (gooly at gmx.at) Date: Fri, 25 May 2007 18:09:18 +0200 Subject: [Vienna-pm] anmerkungen .. Message-ID: <200705251809.18277.gooly@gmx.at> Hallo, kurze Frage nach Einsch?tzungen.. Ich hab meinen kleinen Server, der ab und zu Files aus der RAM-Disk an remote-Clients (?ber $SOCKET) schicken soll. Die Files sind zT gezippt zum Teil nicht. Um jetzt einerseits das Perl-Prg kleinzuhalten, andererseits den Speicherverbrauch aus dem (24/7) Perl-Prg 'raus'-zuhalten (ich erinnere mich an einen Thread zu Speicherfressern hier) habe ich mir etwas s.u. ausgedacht. Ich bin aber ein bi?chen unsicher, das Ganze schaut schon so einfach aus, dass ich nicht ganz dran gkauben kann. Denn wenn es wirklich so simpel ist, sollte das ein Perl-Standardfeature sein und in den tutorials stehen - oder? foreach my $f ( liesFiles($FileDir) ) { open( SAVEOUT, "<&STDOUT" ) or warn "can't save stdout: $!\n"; open( STDOUT, "<&", $SOCKET ) or warn "can't dup to stdout:$!\n"; if ($f =~ /\.zip/) { system('unzip', '-p', $f ); } else { system('cat', $f); } open( STDOUT, "<&SAVEOUT" ) or warn "can't restore stdout: $!\n"; } Also das mit unzip klappt. Das mit cat hab ich noch nicht probiert. Frage dazu g?be es zu 'cat' einen bessere Alternative? Kann man so wirklich im aufrufenden Perl-Programm den Speicherverbrauch vermeiden, den zB ein my $str; open F, "<$file" or warn "$!\n"; read F, $str, (-s $file); close(F); ... von der Gr??e des Files verursachen w?rde? Sieht jemand Risiken oder Probleme? Wie gesagt das ist so einfach, dass ich noch irgendwo einen Haken vermute :) Ansonsten allen aber ein sch?ne Ping sten Calli From hjp-vienna-pm-list at hjp.at Fri May 25 10:59:05 2007 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Fri, 25 May 2007 19:59:05 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <200705251809.18277.gooly@gmx.at> References: <200705251809.18277.gooly@gmx.at> Message-ID: <20070525175905.GD1299@hjp.at> On 2007-05-25 18:09:18 +0200, gooly at gmx.at wrote: > kurze Frage nach Einsch?tzungen.. > Ich hab meinen kleinen Server, der ab und zu Files aus der RAM-Disk an > remote-Clients (?ber $SOCKET) schicken soll. > Die Files sind zT gezippt zum Teil nicht. > Um jetzt einerseits das Perl-Prg kleinzuhalten, andererseits den > Speicherverbrauch aus dem (24/7) Perl-Prg 'raus'-zuhalten (ich erinnere > mich an einen Thread zu Speicherfressern hier) habe ich mir etwas s.u. > ausgedacht. > > Ich bin aber ein bi?chen unsicher, das Ganze schaut schon so einfach > aus, dass ich nicht ganz dran gkauben kann. Doch, das ist so einfach. Duppen von Filedescriptoren auf STDOUT oder STDIN ist Standard-Unix-Technik. Wenn Du auf der Commandline unzip -p foo.zip > foo tippst, macht die Shell im Prinzip nichts anderes. > Denn wenn es wirklich so simpel ist, sollte das ein > Perl-Standardfeature sein und in den tutorials stehen - oder? Kommt in perlipc und perlopentut vor, allerdings nicht wirklich erkl?rt (zumindest schien es mir beim kurzen ?berfliegen eher zusammenhanglos in der Gegend herumzustehen). Vielleicht haben die Autoren angenommen, dass jeder Perl-Programmierer auch die Shell kennt und dass das Feature keine weiteren Erkl?rungen braucht. > foreach my $f ( liesFiles($FileDir) ) { > open( SAVEOUT, "<&STDOUT" ) or warn "can't save stdout: $!\n"; > open( STDOUT, "<&", $SOCKET ) or warn "can't dup to stdout:$!\n"; Das ist verwirrend. Du ?ffnest hier STDOUT zum Lesen. Funktioniert zwar trotzdem, aber IMHO nur deswegen, weil die Information das exec nicht ?bersteht (der darunter liegende Filedescriptor wird nur dupliziert und bleibt damit zum Lesen und Schreiben ge?ffnet). > if ($f =~ /\.zip/) { > system('unzip', '-p', $f ); > } else { > system('cat', $f); > } > open( STDOUT, "<&SAVEOUT" ) or warn "can't restore stdout: $!\n"; Und da auch. Kannst Du danach noch auf STDOUT schreiben? > Also das mit unzip klappt. > Das mit cat hab ich noch nicht probiert. Frage dazu g?be es zu 'cat' > einen bessere Alternative? > Kann man so wirklich im aufrufenden Perl-Programm den Speicherverbrauch > vermeiden, den zB ein > my $str; > open F, "<$file" or warn "$!\n"; > read F, $str, (-s $file); > close(F); > ... > von der Gr??e des Files verursachen w?rde? Ja. Die Daten gehen ja gar nie durch Dein Programm durch, zip bzw. cat gibt das direkt auf den Socket aus und terminiert dann. Selbst wenn zip bzw. cat das File als ganzes in den Speicher lesen w?rden, w?re der Speicher danach wieder frei, w?hrend das bei read F, $str, (-s $file); nicht notwendigerweise der Fall ist (Perl gibt Speicher ungern an das OS zur?ck - vielleicht braucht es ihn ja sp?ter wieder). Eine sinnvolle Perl-Variante w?re my $str; open F, "<", $file" or warn "$!\n"; while (read F, $str, 0x1_0000) { print $socket $str; } close(F); (auch "while () print }" w?rde funktionieren, braucht aber soviel Speicher wie die l?ngste Zeile lang ist, was bei bin?ren Files ziemlich unabsch?tzbar ist) Eine Methode, Memory-Leaks zu vermeiden, ist es zu forken und die eigentliche Arbeit im Kind-Prozess zu machen. Wenn der beendet wird, ist alles wieder beim alten. Das hat bei Servern auch den Vorteil, dass man mehrere Clients gleichzeitig bedienen kann (Ja, das geht auch anders, aber "forking server" ist eine der einfachsten Varianten). hp -- _ | Peter J. Holzer | I know I'd be respectful of a pirate |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20070525/d3b8385e/attachment.bin From gooly at gmx.at Sat May 26 03:09:00 2007 From: gooly at gmx.at (gooly at gmx.at) Date: Sat, 26 May 2007 12:09:00 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <20070525175905.GD1299@hjp.at> References: <200705251809.18277.gooly@gmx.at> <20070525175905.GD1299@hjp.at> Message-ID: <200705261209.00284.gooly@gmx.at> Am Freitag, 25. Mai 2007 schrieb Peter J. Holzer: > On 2007-05-25 18:09:18 +0200, gooly at gmx.at wrote: > > > foreach my $f ( liesFiles($FileDir) ) { > > open( SAVEOUT, "<&STDOUT" ) or warn "can't save stdout: $!\n"; > > open( STDOUT, "<&", $SOCKET ) or warn "can't dup to > > stdout:$!\n"; Ich hatte das aus dem Internet : copy + paste auf der Suche nach dubbing STDOUT auf einen Socket (fast alles betrifft immer nur Files). Hatte mich auch ?berrascht, aber dann dachte ich, was auf der einen Seite schreibt muss auf der anderen Seite lesen und hab's so ?bernommen. > > Das ist verwirrend. Du ?ffnest hier STDOUT zum Lesen. Funktioniert > zwar trotzdem, aber IMHO nur deswegen, weil die Information das exec > nicht ?bersteht (der darunter liegende Filedescriptor wird nur > dupliziert und bleibt damit zum Lesen und Schreiben ge?ffnet). > > > if ($f =~ /\.zip/) { > > system('unzip', '-p', $f ); > > } else { > > system('cat', $f); > > } > > open( STDOUT, "<&SAVEOUT" ) or warn "can't restore stdout: > > $!\n"; > > Und da auch. Kannst Du danach noch auf STDOUT schreiben? Ja, ich kriegte nur einen Warung. Aber zur Sicherheit alle drei open 'gehen mit' ">&"? > > Also das mit unzip klappt. > > Das mit cat hab ich noch nicht probiert. Frage dazu g?be es zu > > 'cat' einen bessere Alternative? > > Kann man so wirklich im aufrufenden Perl-Programm den > > Speicherverbrauch vermeiden, den zB ein > > my $str; > > open F, "<$file" or warn "$!\n"; > > read F, $str, (-s $file); > > close(F); > > ... > > von der Gr??e des Files verursachen w?rde? > > Ja. Die Daten gehen ja gar nie durch Dein Programm durch, zip bzw. > cat gibt das direkt auf den Socket aus und terminiert dann. Selbst > wenn zip bzw. cat das File als ganzes in den Speicher lesen w?rden, > w?re der Speicher danach wieder frei, w?hrend das bei read F, $str, > (-s $file); nicht notwendigerweise der Fall ist (Perl gibt Speicher > ungern an das OS zur?ck - vielleicht braucht es ihn ja sp?ter > wieder). > > Eine sinnvolle Perl-Variante w?re > > my $str; > open F, "<", $file" or warn "$!\n"; > while (read F, $str, 0x1_0000) { > print $socket $str; > } > close(F); > (auch "while () print }" w?rde funktionieren, braucht aber soviel > Speicher wie die l?ngste Zeile lang ist, was bei bin?ren Files > ziemlich unabsch?tzbar ist) > > Eine Methode, Memory-Leaks zu vermeiden, ist es zu forken und die > eigentliche Arbeit im Kind-Prozess zu machen. Ja, aber dann h?tt ich lauter forks in in forks in forks.. Das sind dannn ifs in ifs in ifs.. So bleibt das Programm klein und ?bersichtlich und ich hab das Gef?hl es ist auch ein bi?chen schneller? Aber Danke, Calli From alfredreibenschuh at gmx.net Sat May 26 07:06:52 2007 From: alfredreibenschuh at gmx.net (Alfred Reibenschuh) Date: Sat, 26 May 2007 16:06:52 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <200705261209.00284.gooly@gmx.at> References: <200705251809.18277.gooly@gmx.at> <20070525175905.GD1299@hjp.at> <200705261209.00284.gooly@gmx.at> Message-ID: <46583EFC.30705@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 gooly at gmx.at wrote: > Am Freitag, 25. Mai 2007 schrieb Peter J. Holzer: >> On 2007-05-25 18:09:18 +0200, gooly at gmx.at wrote: ... >> >> Eine Methode, Memory-Leaks zu vermeiden, ist es zu forken und die >> eigentliche Arbeit im Kind-Prozess zu machen. > Ja, aber dann h?tt ich lauter forks in in forks in forks.. > Das sind dannn ifs in ifs in ifs.. So bleibt das Programm klein und > ?bersichtlich und ich hab das Gef?hl es ist auch ein bi?chen schneller? also ich verwende da Net::Server mit der PreFork config, ist mit 5-8 zeilen zu configgen und am laufen. C fredo - -- Schonmal davon gehoert, dass nicht jeder linux user gleich ein programmierer ist, der alles, was er selber braucht, auch selber programmiert, installiert, patched, hacked oder portiert? Urks? Das ist doch nur eine Legende..... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGWD78jKJMaHhpyr4RCJhWAJ9dJ//wQiLwzjbxemDJvbM/oQV3WgCdHIf2 nl9DmY7TyrWnPID/lHeybdQ= =z63H -----END PGP SIGNATURE----- From hjp-vienna-pm-list at hjp.at Sat May 26 15:23:37 2007 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Sun, 27 May 2007 00:23:37 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <200705261209.00284.gooly@gmx.at> References: <200705251809.18277.gooly@gmx.at> <20070525175905.GD1299@hjp.at> <200705261209.00284.gooly@gmx.at> Message-ID: <20070526222337.GA1354@hjp.at> On 2007-05-26 12:09:00 +0200, gooly at gmx.at wrote: > Am Freitag, 25. Mai 2007 schrieb Peter J. Holzer: > > On 2007-05-25 18:09:18 +0200, gooly at gmx.at wrote: > > > > > foreach my $f ( liesFiles($FileDir) ) { > > > open( STDOUT, "<&", $SOCKET ) or warn "can't dup to > > > > Das ist verwirrend. Du ?ffnest hier STDOUT zum Lesen. [...] > > > open( STDOUT, "<&SAVEOUT" ) or warn "can't restore stdout: > > > $!\n"; > > > > Und da auch. Kannst Du danach noch auf STDOUT schreiben? > Ja, ich kriegte nur einen Warung. Bei mir (perl, v5.8.8 built for i486-linux-gnu-thread-multi) geht das n?mlich nicht: #!/usr/bin/perl open(SAVEOUT, "<&STDOUT") or warn "can't save stdout: $!\n"; open(STDOUT, ">foo1"); open( STDOUT, "<&SAVEOUT" ) or warn "can't restore stdout: $!\n"; print STDOUT "test\n" or warn "cannot write to stdout: $!\n"; ergibt: cannot write to stdout: Bad file descriptor > Aber zur Sicherheit alle drei > open 'gehen mit' ">&"? Ja, schlie?lich willst Du den Filedescriptor zum Schreiben ?ffnen. > > Eine Methode, Memory-Leaks zu vermeiden, ist es zu forken und die > > eigentliche Arbeit im Kind-Prozess zu machen. > Ja, aber dann h?tt ich lauter forks in in forks in forks.. Warum das? > Das sind dannn ifs in ifs in ifs.. So bleibt das Programm klein und > ?bersichtlich und ich hab das Gef?hl es ist auch ein bi?chen schneller? Ja, ein fork kostet Zeit. Aber sobald ein zweiter Client zu connecten versucht, wird zumindest die Latenz deutlich besser, wenn auch nicht notwendigerweise der Throughput. hp -- _ | Peter J. Holzer | I know I'd be respectful of a pirate |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20070527/fb1efbcb/attachment.bin From gooly at gmx.at Mon May 28 00:29:52 2007 From: gooly at gmx.at (gooly at gmx.at) Date: Mon, 28 May 2007 09:29:52 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <20070526222337.GA1354@hjp.at> References: <200705251809.18277.gooly@gmx.at> <200705261209.00284.gooly@gmx.at> <20070526222337.GA1354@hjp.at> Message-ID: <200705280929.52253.gooly@gmx.at> Am Sonntag, 27. Mai 2007 schrieb Peter J. Holzer: > On 2007-05-26 12:09:00 +0200, gooly at gmx.at wrote: > > Am Freitag, 25. Mai 2007 schrieb Peter J. Holzer: > > > On 2007-05-25 18:09:18 +0200, gooly at gmx.at wrote: > > > > foreach my $f ( liesFiles($FileDir) ) { > > > > open( STDOUT, "<&", $SOCKET ) or warn "can't dup to > > > > > > Das ist verwirrend. Du ?ffnest hier STDOUT zum Lesen. > > [...] > > > > > open( STDOUT, "<&SAVEOUT" ) or warn "can't restore stdout: > > > > $!\n"; > > > > > > Und da auch. Kannst Du danach noch auf STDOUT schreiben? > > > > Ja, ich kriegte nur einen Warung. > > Bei mir (perl, v5.8.8 built for i486-linux-gnu-thread-multi) geht das > n?mlich nicht: > > #!/usr/bin/perl > > open(SAVEOUT, "<&STDOUT") or warn "can't save stdout: $!\n"; > open(STDOUT, ">foo1"); > open( STDOUT, "<&SAVEOUT" ) or warn "can't restore stdout: $!\n"; > > print STDOUT "test\n" or warn "cannot write to stdout: $!\n"; > > ergibt: > > cannot write to stdout: Bad file descriptor > > > Aber zur Sicherheit alle drei > > open 'gehen mit' ">&"? > > Ja, schlie?lich willst Du den Filedescriptor zum Schreiben ?ffnen. > > > > Eine Methode, Memory-Leaks zu vermeiden, ist es zu forken und die > > > eigentliche Arbeit im Kind-Prozess zu machen. > > > > Ja, aber dann h?tt ich lauter forks in in forks in forks.. > > Warum das? Nun, ein Server wartet auf clients und 'forket' dann, wenn in dieser Anwendung nun weitere Prozesse starten m?ssen, die ihrerseits dann... Wenn Perl (so wie 'andere' auch) forket, wird das Programm ja geklont. Da habe ich dann die Situation, dass der Server f?r jede Client dessen eigenes Datenquellprogramm startet. Wenn das aber nicht so ideal ist, bei einer zeitkritischen Anwendungen zB, die bestimmten Dingen einen Zeitstempel verpassen und die von unterschiedlichen Dingen abh?ngen: der steht, bis er Daten kriegt, der zweite soll aber genau zur vollen Minute 'was machen', dann ist es dies Konzept nicht mehr so gut. Und das Prinzip Radio mit ein und derselben 'live'-Datenquelle f?r alle Clienten habe ich in der umfangreichen 'Literatur' nicht gefunden.. Daher funktioniert auch nicht das: >also ich verwende da Net::Server mit der PreFork config, >ist mit 5-8 zeilen zu configgen und am laufen. Dazu kommen dann noch die Programme, die zu bestimmten Abst?nden die Daten verwalten und aufr?umen.. Na, noch sch?ne Pfingsten.. Calli From hjp-vienna-pm-list at hjp.at Mon May 28 09:29:20 2007 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Mon, 28 May 2007 18:29:20 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <200705280929.52253.gooly@gmx.at> References: <200705251809.18277.gooly@gmx.at> <200705261209.00284.gooly@gmx.at> <20070526222337.GA1354@hjp.at> <200705280929.52253.gooly@gmx.at> Message-ID: <20070528162920.GB32410@hjp.at> On 2007-05-28 09:29:52 +0200, gooly at gmx.at wrote: > Am Sonntag, 27. Mai 2007 schrieb Peter J. Holzer: > > On 2007-05-26 12:09:00 +0200, gooly at gmx.at wrote: > > > Am Freitag, 25. Mai 2007 schrieb Peter J. Holzer: > > > > Eine Methode, Memory-Leaks zu vermeiden, ist es zu forken und die > > > > eigentliche Arbeit im Kind-Prozess zu machen. > > > > > > Ja, aber dann h?tt ich lauter forks in in forks in forks.. > > > > Warum das? > > Nun, ein Server wartet auf clients und 'forket' dann, wenn in dieser > Anwendung nun weitere Prozesse starten m?ssen, die ihrerseits dann... Ah, mir war nicht klar, dass Du ohnehin schon einen forking server hast. Da ist existiert das Problem, dass der Server nie mehr schrumpft ja meistens nicht: Der Parent-Prozess macht nichts au?er accept und fork, und bleibt damit sch?n klein, die Kindprozesse sterben sobald der Client disconnected und geben damit jeden Speicher, den sie hatten, wieder frei. Damit musst Du nat?rlich nicht innerhalb eines Kindprozesses nochmal forken, es sei denn, die Clientsessions k?nnen lange dauern und viel Speicher fressen. Mit der "externe-Programme mittels system starten, um die Arbeit zu machen"-Methode hast Du aber genau die verschachtelten forks: Zuerst forkt der Server, wenn er eine neue Connection erh?lt, dann forkt das Kind f?r jeden File-Request, und das Enkelkind exect dann cat bzw. zip (und wenn Du nicht aufpasst, hast Du eine Shell auch noch dazwischen). > Wenn Perl (so wie 'andere' auch) forket, wird das Programm ja geklont. > Da habe ich dann die Situation, dass der Server f?r jede Client dessen > eigenes Datenquellprogramm startet. Wenn das aber nicht so ideal ist, > bei einer zeitkritischen Anwendungen zB, die bestimmten Dingen einen > Zeitstempel verpassen und die von unterschiedlichen Dingen abh?ngen: > der steht, bis er Daten kriegt, der zweite soll aber genau zur vollen > Minute 'was machen', dann ist es dies Konzept nicht mehr so gut. Wenn Du ein hartes Echtzeitsystem brauchst, solltest Du wahrscheinlich sowohl um General-Purpose-Betriebssysteme (Linux, Windows, ...) als auch um Perl einen gro?en Bogen machen. Wenn es weniger hart ist, verstehe ich nicht, welches Szenario du da jetzt meinst, und welches Konzept jetzt besser oder schlechter sein soll als welches andere Konzept. Kannst Du da konkreter werden? > Und das Prinzip Radio mit ein und derselben 'live'-Datenquelle f?r > alle Clienten habe ich in der umfangreichen 'Literatur' nicht > gefunden.. Multicast. hp -- _ | Peter J. Holzer | I know I'd be respectful of a pirate |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20070528/8a6e71e2/attachment.bin From bernd at firmix.at Mon May 28 09:53:22 2007 From: bernd at firmix.at (Bernd Petrovitsch) Date: Mon, 28 May 2007 18:53:22 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <20070528162920.GB32410@hjp.at> References: <200705251809.18277.gooly@gmx.at> <200705261209.00284.gooly@gmx.at> <20070526222337.GA1354@hjp.at> <200705280929.52253.gooly@gmx.at> <20070528162920.GB32410@hjp.at> Message-ID: <1180371202.3640.64.camel@gimli.at.home> On Mon, 2007-05-28 at 18:29 +0200, Peter J. Holzer wrote: [...] > Da ist existiert das Problem, dass der Server nie mehr schrumpft ja > meistens nicht: Der Parent-Prozess macht nichts au?er accept und fork, > und bleibt damit sch?n klein, die Kindprozesse sterben sobald der Client > disconnected und geben damit jeden Speicher, den sie hatten, wieder > frei. Tats?chlich ist das die einzig mir bekannte Methode, tempor?ren gro?en Speicher wieder loszuwerden (z.B. macht der Daemon genau einmal t?glich irgendwas speicherfressendes): Vorher fork()en und den Worker-Proze? entsorgen, wenn man ihn nicht mehr braucht bzw. der Worker fertig ist. [...] > Speicher fressen. Mit der "externe-Programme mittels system starten, um > die Arbeit zu machen"-Methode hast Du aber genau die verschachtelten > forks: Zuerst forkt der Server, wenn er eine neue Connection erh?lt, > dann forkt das Kind f?r jeden File-Request, und das Enkelkind exect dann > cat bzw. zip (und wenn Du nicht aufpasst, hast Du eine Shell auch noch > dazwischen). Wenn das perl system() intern das libc system(3) aufruft, wird man das gar nicht verhindern k?nnen. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services From hjp-vienna-pm-list at hjp.at Mon May 28 10:16:19 2007 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Mon, 28 May 2007 19:16:19 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <1180371202.3640.64.camel@gimli.at.home> References: <200705251809.18277.gooly@gmx.at> <200705261209.00284.gooly@gmx.at> <20070526222337.GA1354@hjp.at> <200705280929.52253.gooly@gmx.at> <20070528162920.GB32410@hjp.at> <1180371202.3640.64.camel@gimli.at.home> Message-ID: <20070528171619.GF32410@hjp.at> On 2007-05-28 18:53:22 +0200, Bernd Petrovitsch wrote: > On Mon, 2007-05-28 at 18:29 +0200, Peter J. Holzer wrote: > > Da ist existiert das Problem, dass der Server nie mehr schrumpft ja > > meistens nicht: Der Parent-Prozess macht nichts au?er accept und fork, > > und bleibt damit sch?n klein, die Kindprozesse sterben sobald der Client > > disconnected und geben damit jeden Speicher, den sie hatten, wieder > > frei. > > Tats?chlich ist das die einzig mir bekannte Methode, tempor?ren gro?en > Speicher wieder loszuwerden (z.B. macht der Daemon genau einmal t?glich > irgendwas speicherfressendes): Vorher fork()en und den Worker-Proze? > entsorgen, wenn man ihn nicht mehr braucht bzw. der Worker fertig ist. Zumindest die einzige Methode, die auf verschiedenen Systemen zuverl?ssig funktioniert. Auf Systemen, die die glibc verwenden, werden gr??ere Speicherbereiche (default: ab 128 kB) mittels mmap statt sbrk alloziert und beim free auch wieder freigegeben. Die malloc-Implementatioen von BSD (und MacOS) scheinen das auch so halten, die von HP-UX gibt nie was frei, was sie einmal hat (klassische Unix malloc-Implementation halt). Und Perl verwendet ja nicht notwendigerweise malloc/free von der libc, sondern kann auch seine eigene Implementation verwenden (die meines Wissens auch nie mehr was hergibt), und wenn das nicht kompliziert genug ist, dann kommen noch die Geheimnisse des Perl-Memory-Managements dazu, bei dem auch nie so ganz klar ist, wann es free aufruft, und wann es der Meinung ist, dass es den Speicherbereich vielleicht sicherheitshalber behalten sollte. > > Speicher fressen. Mit der "externe-Programme mittels system starten, um > > die Arbeit zu machen"-Methode hast Du aber genau die verschachtelten > > forks: Zuerst forkt der Server, wenn er eine neue Connection erh?lt, > > dann forkt das Kind f?r jeden File-Request, und das Enkelkind exect dann > > cat bzw. zip (und wenn Du nicht aufpasst, hast Du eine Shell auch noch > > dazwischen). > > Wenn das perl system() intern das libc system(3) aufruft, wird man das > gar nicht verhindern k?nnen. Tut es nur dann, wenn 1) es mit nur einem Parameter aufgerufen wird und 2) dieser eine Parameter "Shell-Metacharacters" (wie auch immer die jetzt genau definiert sind) enth?lt. Normalerweise kann man das leicht vermeiden und Perl system macht dann nur ein fork und ein exec. (Darum habe ich "wenn Du nicht aufpasst" geschrieben) hp -- _ | Peter J. Holzer | I know I'd be respectful of a pirate |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20070528/810826c8/attachment.bin From gooly at gmx.at Mon May 28 10:56:01 2007 From: gooly at gmx.at (gooly at gmx.at) Date: Mon, 28 May 2007 19:56:01 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <20070528162920.GB32410@hjp.at> References: <200705251809.18277.gooly@gmx.at> <200705280929.52253.gooly@gmx.at> <20070528162920.GB32410@hjp.at> Message-ID: <200705281956.01858.gooly@gmx.at> Am Montag, 28. Mai 2007 schrieb Peter J. Holzer: > On 2007-05-28 09:29:52 +0200, gooly at gmx.at wrote: > > Am Sonntag, 27. Mai 2007 schrieb Peter J. Holzer: > > > On 2007-05-26 12:09:00 +0200, gooly at gmx.at wrote: > > > > Am Freitag, 25. Mai 2007 schrieb Peter J. Holzer: > > > > > Eine Methode, Memory-Leaks zu vermeiden, ist es zu forken und > > > > > die eigentliche Arbeit im Kind-Prozess zu machen. > > > > > > > > Ja, aber dann h?tt ich lauter forks in in forks in forks.. > > > > > > Warum das? > > > > Nun, ein Server wartet auf clients und 'forket' dann, wenn in > > dieser Anwendung nun weitere Prozesse starten m?ssen, die > > ihrerseits dann... > > Ah, mir war nicht klar, dass Du ohnehin schon einen forking server > hast. Da ist existiert das Problem, dass der Server nie mehr > schrumpft ja meistens nicht: Der Parent-Prozess macht nichts au?er > accept und fork, und bleibt damit sch?n klein, die Kindprozesse > sterben sobald der Client disconnected und geben damit jeden > Speicher, den sie hatten, wieder frei. > > Damit musst Du nat?rlich nicht innerhalb eines Kindprozesses nochmal > forken, es sei denn, die Clientsessions k?nnen lange dauern und viel > Speicher fressen. Mit der "externe-Programme mittels system starten, > um die Arbeit zu machen"-Methode hast Du aber genau die > verschachtelten forks: Zuerst forkt der Server, wenn er eine neue > Connection erh?lt, dann forkt das Kind f?r jeden File-Request, und > das Enkelkind exect dann cat bzw. zip (und wenn Du nicht aufpasst, > hast Du eine Shell auch noch dazwischen). Naja, forken wollte ich ja schon und damit spezielle Dinge aus dem Programm raushalten, aber mit dem dubbing von STDOUT auf den socket brauche ich dazu nur 4 zeilen statt einem fork oder open und die if-struktur.. > > Wenn Perl (so wie 'andere' auch) forket, wird das Programm ja > > geklont. Da habe ich dann die Situation, dass der Server f?r jede > > Client dessen eigenes Datenquellprogramm startet. Wenn das aber > > nicht so ideal ist, bei einer zeitkritischen Anwendungen zB, die > > bestimmten Dingen einen Zeitstempel verpassen und die von > > unterschiedlichen Dingen abh?ngen: der steht, bis er Daten kriegt, > > der zweite soll aber genau zur vollen Minute 'was machen', dann ist > > es dies Konzept nicht mehr so gut. > > Wenn Du ein hartes Echtzeitsystem brauchst, solltest Du > wahrscheinlich sowohl um General-Purpose-Betriebssysteme (Linux, > Windows, ...) als auch um Perl einen gro?en Bogen machen. Warum Linux nicht, warum Perl nicht? Laut einer Untersuchung (aus dem Netz) aus Deutschland ist Perl (auch Python und so) viel schneller programierbar als zB C oder C++ ist aber parktisch genauso schnell in der Ausf?hrung wie C (sp?ter kann man ja dann noch C erzeugen, wenn man m?chte). In C muss man aber jeden Kleinkram selber machen und C++ und Java sind etwas f?r Romaschreiber - nix f?r Faule ;) > Wenn es > weniger hart ist, verstehe ich nicht, welches Szenario du da jetzt > meinst, und welches Konzept jetzt besser oder schlechter sein soll > als welches andere Konzept. Kannst Du da konkreter werden? Nun es geht um Kursdaten, Aktien, W?hrungen, Futures. Da hast Du nur eine Quelle, oder Du hast mehrere Quellen, die Du dann untereinander vergleichen musst wegen der badTicks. Aus denen mach ich dann erstmal 1-Minuten-Bars. Und die m?chte ich dann nach versch Ans?tzen weiter bearbeiten und jeder Ansatz sollte selbst?ndig sein. Mir ist lieber mehrere kleine Programme die definierte kleine Aufgaben erledigen, als ein Riesending f?r alles. > > Und das Prinzip Radio mit ein und derselben 'live'-Datenquelle f?r > > alle Clienten habe ich in der umfangreichen 'Literatur' nicht > > gefunden.. > > Multicast. Hmmm. Ich hab mir deshalb threads::shared; mit IO::Socket::INET; genommen: 1. thread f?r die Kursallokation und dem Timestamp per shared vars diese 1) an den 2. thread und 2) an den die Clienten schickt. Der 2. thread macht daraus 1 Minuten-Bars zum sichern und f?r die Clients, die sind das jew. die n?chsten therads, mein radio.pl Aber jetzt noch eine andere Frage. Ich will mir http://search.cpan.org/~kwilliams/Algorithm-SVMLight/lib/Algorithm/SVMLight.pm installieren. Da cpan -i Algorithm::SVMLight.pm nicht klappt, muss ich es 'zu Fu?' machen, aber auch hier gibt es Probleme: Es braucht dazu ein lib von hier, die zu patche ist (gemacht) Jetzt findet aber die Perl-Installations-Kaskade perl Build.PL perl Build (bis hier klappts) perl Build test (da ist's dann aus) perl Build install (may need to be done as root) Das ist der Grund: /usr/bin/perl lib/Algorithm/Makefile.PL lib/Algorithm/Makefile Malformed argument 'lib/Algorithm/Makefile' at /usr/lib/perl5/site_perl/5.8.6/Module/Build/Compat.pm line 163, line 547. /usr/bin/perl lib/Algorithm/Build.PL lib/Algorithm/Build Checking whether your kit is complete... WARNING: the following files are missing in your kit: lib/Algorithm/param_set.c.PL lib/Algorithm/SVMLight.xs Please inform the author. .... Diese Dateien sind eh da, aber ich muss sie jetzt dorthinschieben, dass perl auch weiss, sie sind da. Da ich alles h?ndisch machen musste, habe ich mal einen Folder erzeugt: /usr/lib/perl5/5.8.6/Algorithm (wo die anderen sind) und alles hineingestopft, auch die 'externen' svm-Programme inkl der libsvmlight.a. Aber obige Fehlermeldung deutet darauf hin, dass ich in Algorithm/ noch einmal lib/Algorithm/ habe - w?r das so? Ich denke es g?be eine elegantere L?sung? Peter, wie soll denn so eine Modul-Folder in Perl aussehen und wo tue ich am besten die 'andere' lib hin? Gibt es da - hhm - Standards? Danke und noch einen sch?nen Abend, Calli From bernd at firmix.at Mon May 28 13:41:35 2007 From: bernd at firmix.at (Bernd Petrovitsch) Date: Mon, 28 May 2007 22:41:35 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <200705281956.01858.gooly@gmx.at> References: <200705251809.18277.gooly@gmx.at> <200705280929.52253.gooly@gmx.at> <20070528162920.GB32410@hjp.at> <200705281956.01858.gooly@gmx.at> Message-ID: <1180384895.3640.94.camel@gimli.at.home> On Mon, 2007-05-28 at 19:56 +0200, gooly at gmx.at wrote: > Am Montag, 28. Mai 2007 schrieb Peter J. Holzer: [...] > > Wenn Du ein hartes Echtzeitsystem brauchst, solltest Du > > wahrscheinlich sowohl um General-Purpose-Betriebssysteme (Linux, > > Windows, ...) als auch um Perl einen gro?en Bogen machen. > Warum Linux nicht, warum Perl nicht? Laut einer Untersuchung (aus dem Weil es keine Garantien ?ber Rechtzeitigkeit gibt, d.h. Garantien da? bestimmte Funktionen/Subsysteme/... maximale Ausf?hrungszeiten haben. > Netz) aus Deutschland ist Perl (auch Python und so) viel schneller > programierbar als zB C oder C++ ist aber parktisch genauso schnell in > der Ausf?hrung wie C (sp?ter kann man ja dann noch C erzeugen, wenn man > m?chte). In C muss man aber jeden Kleinkram selber machen und C++ und > Java sind etwas f?r Romaschreiber - nix f?r Faule ;) Das hat alles mit "Echtzeitf?higkeit" nach akademischer Definition (und damit der wahren) nichts zu tun. Das Problem, da? die Welt mit dem Begriff "Echtzeit" hat ist, da? er in den letzten Jahren von diversen Ahnungslosen und/oder Ignoranten als Marketing/Sales-Buzzword f?r "sofort", "m?glichst schnell", "unverz?glich", u.?. technisch wenig sinnvolle Adjektive vergewaltigt wurde. Tats?chlich bedeutet Echtzeitf?higkeit, da? eine gegebene Aufgabe/Algorithmus/Problem nicht nur Ergebnis-m??ig korrekt gel?st wird, sondern auch zus?tzlich noch Zeitvorgaben einh?lt. Und es ist v?llig irrelevant, welche Dimension die Zeitangabe hat. Z.B. k?nnte eine Bank definieren, da? sie am 4. J?nner 00:00 Uhr die Jahresabrechnung des letzten Jahres fertig haben will. Voila, wir haben einen festen Termin in der Spezifikation und damit ein Echtzeitsystem. Und dann unterscheidet man noch zwischen "soft realtime" und "hard realtime": soft: Wenn man die Zeitvorgaben nicht einh?lt, dann ist der Verlust im wesentlichen der entgangene Nutzen. Z.B. gibt es f?r den Verbindungsaufbau im ISDN eine maximale Dauer (20?s oder so). Wenn das bei einem normalen Telefonanruf mal l?nger dauert, wird nicht viel passieren .... hard: Der Schaden ist signifikant gr??er. Typische Bsp. sind Flugzeug- und/oder Eisenbahnsteuerungen, diverse Maschinensteuerungen. Wenn da was zu langsam geregelt/gesteuert wird, dann kracht es idR ordentlich. [...] > bearbeiten und jeder Ansatz sollte selbst?ndig sein. Mir ist lieber > mehrere kleine Programme die definierte kleine Aufgaben erledigen, als > ein Riesending f?r alles. Tja, der Hund bei Echtzeitsystemen als solchen ist, da? Du nur das gesamte System dann und nur dann echtzeitf?hig bekommst, wenn Du ganz unten damit anf?ngst. Wenn nicht, dann mu? du mit dem Restrisiko leben. Das mag gr??er oder kleiner sein und Du kannst es mit Hardware bewerfen, aber Du wirst es mit Hardware nicht erschlagen k?nnen. F?r mehr kann man z.B. http://ti.tuwien.ac.at/rts/teaching/courses/ezs besuchen ...... Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services From gooly at gmx.at Tue May 29 00:00:57 2007 From: gooly at gmx.at (gooly at gmx.at) Date: Tue, 29 May 2007 09:00:57 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <1180384895.3640.94.camel@gimli.at.home> References: <200705251809.18277.gooly@gmx.at> <200705281956.01858.gooly@gmx.at> <1180384895.3640.94.camel@gimli.at.home> Message-ID: <200705290900.57402.gooly@gmx.at> Am Montag, 28. Mai 2007 schrieb Bernd Petrovitsch: > On Mon, 2007-05-28 at 19:56 +0200, gooly at gmx.at wrote: > > Am Montag, 28. Mai 2007 schrieb Peter J. Holzer: > > [...] > > > > Wenn Du ein hartes Echtzeitsystem brauchst, solltest Du > > > wahrscheinlich sowohl um General-Purpose-Betriebssysteme (Linux, > > > Windows, ...) als auch um Perl einen gro?en Bogen machen. > > > > Warum Linux nicht, warum Perl nicht? Laut einer Untersuchung (aus > > dem > > Weil es keine Garantien ?ber Rechtzeitigkeit gibt, d.h. Garantien da? > bestimmte Funktionen/Subsysteme/... maximale Ausf?hrungszeiten haben. Aber das kann (muss) man dann doch so programmieren - egal in welcher Sprache, auch in Perl, oder? Gut, denkbar sind Systeme, die so schnell sein m?ssen, dass man zum Maschinencode greift, aber das ist eine andere Geschichte, und f?r mich nicht notewendig. Aber ich sehe keinen Nachteil Perls gegen?ber anderen Sprachen, im Gegenteil, es ist sogar schneller als mach andere moderne Hoichsprache, wie zB Java. > > > Netz) aus Deutschland ist Perl (auch Python und so) viel schneller > > programierbar als zB C oder C++ ist aber parktisch genauso schnell > > in der Ausf?hrung wie C (sp?ter kann man ja dann noch C erzeugen, > > wenn man m?chte). In C muss man aber jeden Kleinkram selber machen > > und C++ und Java sind etwas f?r Romaschreiber - nix f?r Faule ;) > > Das hat alles mit "Echtzeitf?higkeit" nach akademischer Definition > (und damit der wahren) nichts zu tun. > Das Problem, da? die Welt mit dem Begriff "Echtzeit" hat ist, da? er > in den letzten Jahren von diversen Ahnungslosen und/oder Ignoranten > als Marketing/Sales-Buzzword f?r "sofort", "m?glichst schnell", > "unverz?glich", u.?. technisch wenig sinnvolle Adjektive vergewaltigt > wurde. Das ist klar! Hat aber nicht mit der Programier-Sprachwahl zu tun? > > Tats?chlich bedeutet Echtzeitf?higkeit, da? eine gegebene > Aufgabe/Algorithmus/Problem nicht nur Ergebnis-m??ig korrekt gel?st > wird, sondern auch zus?tzlich noch Zeitvorgaben einh?lt. Und es ist > v?llig irrelevant, welche Dimension die Zeitangabe hat. Z.B. k?nnte > eine Bank definieren, da? sie am 4. J?nner 00:00 Uhr die > Jahresabrechnung des letzten Jahres fertig haben will. Voila, wir > haben einen festen Termin in der Spezifikation und damit ein > Echtzeitsystem. Deshalb kommen meine beiden zeitkritischen Teile in eigene Threads, auch deshalb notwendig, weil sie zeitlich ganz unterschiedlich (re-)agieren m?ssen und die Server-Cleint Struktur macht es leicht daraus ein 'distributet system' zu machen oder es so nach Belieben mit Hardware zu bewerfen ;) Und wie bei jeder technischen Spezifikation kann man nie einen genauen Zielwert angeben, sondern immer nur einen zusammen mit einer zu erreichenden Tolleranz! Auch das ist in Perl erreichbar: Je nach Schnelligkeitsanforderung muss man halt auf das Gesamsystem schauen, oder wie Du sagt Hardware bewerfen :). Und wenn Perl dann nicht schnell genug ist, ist wahrscheinlich auch C nicht schnell genug - auf diesem System. Und wie gesagt, Perl ist praktisch so schnell wir C. Das Problem w?re also so nicht Perl. > > Und dann unterscheidet man noch zwischen "soft realtime" und "hard > realtime": > soft: Wenn man die Zeitvorgaben nicht einh?lt, dann ist der Verlust > im wesentlichen der entgangene Nutzen. > Z.B. gibt es f?r den Verbindungsaufbau im ISDN eine maximale > Dauer (20?s oder so). Wenn das bei einem normalen Telefonanruf mal > l?nger dauert, wird nicht viel passieren .... > hard: Der Schaden ist signifikant gr??er. > Typische Bsp. sind Flugzeug- und/oder Eisenbahnsteuerungen, > diverse Maschinensteuerungen. Wenn da was zu langsam > geregelt/gesteuert wird, dann kracht es idR ordentlich. > > [...] > > > bearbeiten und jeder Ansatz sollte selbst?ndig sein. Mir ist lieber > > mehrere kleine Programme die definierte kleine Aufgaben erledigen, > > als ein Riesending f?r alles. > > Tja, der Hund bei Echtzeitsystemen als solchen ist, da? Du nur das > gesamte System dann und nur dann echtzeitf?hig bekommst, wenn Du ganz > unten damit anf?ngst. > Wenn nicht, dann mu? du mit dem Restrisiko leben. Das mag gr??er oder > kleiner sein und Du kannst es mit Hardware bewerfen, aber Du wirst es > mit Hardware nicht erschlagen k?nnen. Naja, es ist erschlagen, wenn Du Toleranzen definierts und innerhalb derer bleibst.. > F?r mehr kann man z.B. > http://ti.tuwien.ac.at/rts/teaching/courses/ezs besuchen ...... Interessante Slides, Danke. Calli From robe at amd.co.at Tue May 29 01:48:55 2007 From: robe at amd.co.at (Michael Renner) Date: Tue, 29 May 2007 10:48:55 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <200705290900.57402.gooly@gmx.at> References: <200705251809.18277.gooly@gmx.at> <200705281956.01858.gooly@gmx.at> <1180384895.3640.94.camel@gimli.at.home> <200705290900.57402.gooly@gmx.at> Message-ID: <465BE8F7.1080209@amd.co.at> gooly at gmx.at wrote: >> Das hat alles mit "Echtzeitf?higkeit" nach akademischer Definition >> (und damit der wahren) nichts zu tun. >> Das Problem, da? die Welt mit dem Begriff "Echtzeit" hat ist, da? er >> in den letzten Jahren von diversen Ahnungslosen und/oder Ignoranten >> als Marketing/Sales-Buzzword f?r "sofort", "m?glichst schnell", >> "unverz?glich", u.?. technisch wenig sinnvolle Adjektive vergewaltigt >> wurde. > Das ist klar! Hat aber nicht mit der Programier-Sprachwahl zu tun? Die jeweilige Sprache muss (vermutlicherweise, ich kenn mich da nur sehr marginal aus) API Hooks f?r das ausgesuchte RT OS haben. > Deshalb kommen meine beiden zeitkritischen Teile in eigene Threads, auch > deshalb notwendig, weil sie zeitlich ganz unterschiedlich (re-)agieren > m?ssen und die Server-Cleint Struktur macht es leicht daraus > ein 'distributet system' zu machen oder es so nach Belieben mit > Hardware zu bewerfen ;) Das klingt schwer nach einem "Here happens magic"-Ansatz. Eine Server-Client Architektur macht ein System bzw. die Tasks die es bearbeitet nicht automatisch verteilbar. > Und wie gesagt, Perl ist praktisch so schnell wir C. Nein. Lange Version: Das h?ngt sehr von den Tasks ab die du bearbeitest. Wenn du nur ein bisschen Kleister zwischen Datenbank und Internet brauchst, ja. Sobalds rechnerisch oder von der Datenmenge her gr??er wird, bist du mit Sprachen deren Datenstrukturen bzw. Interpreter nicht so overhead-behaftet sind wie bei Perl deutlich schneller. Synthetische Benchmarks zum untermauern: [1] >> Tja, der Hund bei Echtzeitsystemen als solchen ist, da? Du nur das >> gesamte System dann und nur dann echtzeitf?hig bekommst, wenn Du ganz >> unten damit anf?ngst. >> Wenn nicht, dann mu? du mit dem Restrisiko leben. Das mag gr??er oder >> kleiner sein und Du kannst es mit Hardware bewerfen, aber Du wirst es >> mit Hardware nicht erschlagen k?nnen. > Naja, es ist erschlagen, wenn Du Toleranzen definierts und innerhalb > derer bleibst.. Echtzeitsysteme definieren sich AFAIK durch sehr enge Toleranzen. Siehe das Beispiel mit dem ISDN Signalling. Und auf die Gefahr dass das hier schon mal breitgtreten wurde: Realnames f?rdern die Gespr?chskultur ;). Michael. [1] http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=perl&lang2=gcc From bernd at firmix.at Tue May 29 01:57:08 2007 From: bernd at firmix.at (Bernd Petrovitsch) Date: Tue, 29 May 2007 10:57:08 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <200705290900.57402.gooly@gmx.at> References: <200705251809.18277.gooly@gmx.at> <200705281956.01858.gooly@gmx.at> <1180384895.3640.94.camel@gimli.at.home> <200705290900.57402.gooly@gmx.at> Message-ID: <1180429028.9989.38.camel@tara.firmix.at> On Tue, 2007-05-29 at 09:00 +0200, gooly at gmx.at wrote: > Am Montag, 28. Mai 2007 schrieb Bernd Petrovitsch: > > On Mon, 2007-05-28 at 19:56 +0200, gooly at gmx.at wrote: > > > Am Montag, 28. Mai 2007 schrieb Peter J. Holzer: [...] > > > > Wenn Du ein hartes Echtzeitsystem brauchst, solltest Du > > > > wahrscheinlich sowohl um General-Purpose-Betriebssysteme (Linux, > > > > Windows, ...) als auch um Perl einen gro?en Bogen machen. > > > > > > Warum Linux nicht, warum Perl nicht? Laut einer Untersuchung (aus > > > dem > > > > Weil es keine Garantien ?ber Rechtzeitigkeit gibt, d.h. Garantien da? > > bestimmte Funktionen/Subsysteme/... maximale Ausf?hrungszeiten haben. > Aber das kann (muss) man dann doch so programmieren - egal in welcher Das ist eine notwendige, aber nicht hinreichende Bedingung. > Sprache, auch in Perl, oder? Perl hat - wie jede Interpretersprache - das zus?tzliche Handikap, da? Du einen echtzeitf?higen Interpreter drunter brauchst. Und wenn unter den Applikationen ein Kernel l?uft, dann m?ssen die Systemcalls auch zeitliche Vorgaben einhalten. Ja, es gibt POSIX RealTime Zeugs im Linux-Kernel. Nein, f?r harte Echtzeit ist das unbrauchbar, da mu?t Du schon z.B. RTAI verwenden (f?r die Echtzzeittasks). > Gut, denkbar sind Systeme, die so schnell sein m?ssen, dass man zum > Maschinencode greift, aber das ist eine andere Geschichte, und f?r mich Da gibt es aber nur wenige Spezialf?lle, wo Assembler wirklich nennenswert schneller ist wie irgendeine kompilierte Hochsprache. Bei Interpretersprachen (perl, JVM, ...) h?ngt es dann auch noch vom Interpreter drunter ab. > nicht notewendig. Aber ich sehe keinen Nachteil Perls gegen?ber anderen > Sprachen, im Gegenteil, es ist sogar schneller als mach andere moderne > Hoichsprache, wie zB Java. Es geht nicht um die Geschwindigkeit der Ausf?hrung (die ist im Prinzip irrelevant solange die maximale Dauer garantiert werden kann), sondern - bei harter Echtzeit - darum 100% zuverl?ssige Aussagen (im Idealfall beweisbar) ?ber das Verhalten in der Zeit zu machen (unter einer gegebenen Fehlerhypothese). Anderes Beispiel: Es gibt das RTnet Projekt. Da bauen Leute Echtzeit-Kommunikation ?ber handels?bliches Ethernet mit CotS Hardware. Auf Ethernet wird CSMA/CD CSMA/CA o.?. eingesetzt. Nur sind Kollisionen wenig deterministisch, ergo d?rfen die nicht passieren. Was macht man? Man legt statisch fest, wer wann sendet. Frage: Setzt man dann Hubs (Multi-Port-Repeater) oder Switches (Multi-Port-Bridges) ein und warum? Antwort: Man setzt *selbstverst?blich* nur Hubs ein, weil Switches store-and-forward machen und das in der Zeit nicht kontrollierbar ist. Und man setzt auch besser 10MBit-Hubs statt 10GBit-Switches ein - es interessiert niemanden, da? das vielleicht viel langsamer als ein Switch ist. > > > Netz) aus Deutschland ist Perl (auch Python und so) viel schneller > > > programierbar als zB C oder C++ ist aber parktisch genauso schnell > > > in der Ausf?hrung wie C (sp?ter kann man ja dann noch C erzeugen, > > > wenn man m?chte). In C muss man aber jeden Kleinkram selber machen > > > und C++ und Java sind etwas f?r Romaschreiber - nix f?r Faule ;) > > > > Das hat alles mit "Echtzeitf?higkeit" nach akademischer Definition > > (und damit der wahren) nichts zu tun. > > Das Problem, da? die Welt mit dem Begriff "Echtzeit" hat ist, da? er > > in den letzten Jahren von diversen Ahnungslosen und/oder Ignoranten > > als Marketing/Sales-Buzzword f?r "sofort", "m?glichst schnell", > > "unverz?glich", u.?. technisch wenig sinnvolle Adjektive vergewaltigt > > wurde. > Das ist klar! Hat aber nicht mit der Programier-Sprachwahl zu tun? Im engeren Sinn, nein. Ich wollte nur sichergehen, da? wir "Echtzeit" gleich definieren. Im weiteren Sinn: Nat?rlich. Schlie?lich mu? *jeder* Aspekt echtzeitf?hig sein. Wenn die ach-so-tolle-Programmiersprache transparent (und damit zwingend *unkontrollierbar*) z.B. Garbage Collection macht, dann ist sie daf?r unbrauchbar. > Und wie bei jeder technischen Spezifikation kann man nie einen genauen > Zielwert angeben, sondern immer nur einen zusammen mit einer zu > erreichenden Tolleranz! Auch das ist in Perl erreichbar: Je nach Tja, bei Echtzeitsystemen *sind* die genauen Zielwerte vorgegeben und die Toleranz ist - bei harter Echtzeit - idR 0 (andernfalls addiert man die Toleranz gleich zum Zielwert und ist bei Toleranz 0). Und dann mu? man das gesamte System so designen, da? die Zielwerte auch eingehalten werden. Deswegen l?st das Einf?hren eine Toleranz in der Zeit nicht das Problem sondern bestenfalls zum a posteriori Messen des "Restriskos" ben?tzt werden (wenn ?berhaupt). Und wenn das nicht geht, kann man das System eben nicht bauen. Entweder kann man mit anderen Zielwerten leben (die dann auch wieder als feste Vorgabe betrachtet werden) oder man l??t es (und das Projekt ist tot). Es gibt - akademisch betrachtet - keine andere L?sung. > Schnelligkeitsanforderung muss man halt auf das Gesamsystem schauen, > oder wie Du sagt Hardware bewerfen :). Pures Hardware draufwerfen bringt keine zeitlichen Garantien sondern reduziert nur das Restrisiko. > Und wenn Perl dann nicht schnell genug ist, ist wahrscheinlich auch C > nicht schnell genug - auf diesem System. > Und wie gesagt, Perl ist praktisch so schnell wir C. Das Problem w?re > also so nicht Perl. Ich glaube nicht, da? z.B. der Garbage-Collector in perl irgendwelche zeitlichen Garantien gibt (und die perl Gurus werden das korrigieren, wenn es nicht stimmt). Wie willst du da Aussagen ?ber das Verhalten in der Zeit treffen. Da helfen auch "Toleranzen" nichts, weil du die Einhaltung derselben auch nicht garantieren kannst. Es gibt nicht im Linux-Kernel, da? zeitliche Angaben ?ber die Dauer der Systemcalls macht. Wenn jemand z.B. per Floodping derma?en viele Hardware-Interrupts erzeugt, da? alles viel l?nger braucht, wie willst du das einkalkulieren. OK, man macht ein eigenes LAN, wo nur definierte Knoten mit definiertem Verhalten/Applikationen "mitspielen" d?rfen. Und alle hunderte andere M?glichkeiten, IRQ-Storms zu erzeugen, mu?t du jetzt auch noch l?sen. BTW ist das mit ein Grund, warum Interrupts bei Echtzeitsystmen normalerweise vermieden werden und Polling das Mittel der Wahl ist. [...] > > Tja, der Hund bei Echtzeitsystemen als solchen ist, da? Du nur das > > gesamte System dann und nur dann echtzeitf?hig bekommst, wenn Du ganz > > unten damit anf?ngst. > > Wenn nicht, dann mu? du mit dem Restrisiko leben. Das mag gr??er oder > > kleiner sein und Du kannst es mit Hardware bewerfen, aber Du wirst es > > mit Hardware nicht erschlagen k?nnen. > Naja, es ist erschlagen, wenn Du Toleranzen definierts und innerhalb > derer bleibst.. Ja, aber woher wei? ich *a priori* *verl??lich*, da? die Zeit eingehalten wird? Ein Lasttest ist jedenfalls viel zu wenig - auch wenn er (angeblich) die x-fache Last simuliert. Oder deine Toleranz ist halt: Ich lebe damit, da? das Ergebnis gelegentlich zu sp?t kommt. Und genau das ist das Restrisiko. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services From gooly at gmx.at Tue May 29 05:53:12 2007 From: gooly at gmx.at (gooly at gmx.at) Date: Tue, 29 May 2007 14:53:12 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <465BE8F7.1080209@amd.co.at> References: <200705251809.18277.gooly@gmx.at> <200705290900.57402.gooly@gmx.at> <465BE8F7.1080209@amd.co.at> Message-ID: <200705291453.12904.gooly@gmx.at> > > Nein. > > Lange Version: Das h?ngt sehr von den Tasks ab die du bearbeitest. > Wenn du nur ein bisschen Kleister zwischen Datenbank und Internet > brauchst, ja. Sobalds rechnerisch oder von der Datenmenge her gr??er > wird, bist du mit Sprachen deren Datenstrukturen bzw. Interpreter > nicht so overhead-behaftet sind wie bei Perl deutlich schneller. > Synthetische Benchmarks zum untermauern: [1] ... > [1] > http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=per Interessant, kannt ich nicht, ich hatte 'meine Meinung' aus einer Vergleichstudie aus dem Internet - ich habe aber keine Adresse mehr. > > >> Tja, der Hund bei Echtzeitsystemen als solchen ist, da? Du nur das > >> gesamte System dann und nur dann echtzeitf?hig bekommst, wenn Du > >> ganz unten damit anf?ngst. > >> Wenn nicht, dann mu? du mit dem Restrisiko leben. Das mag gr??er > >> oder kleiner sein und Du kannst es mit Hardware bewerfen, aber Du > >> wirst es mit Hardware nicht erschlagen k?nnen. > > > > Naja, es ist erschlagen, wenn Du Toleranzen definierts und > > innerhalb derer bleibst.. > > Echtzeitsysteme definieren sich AFAIK durch sehr enge Toleranzen. > Siehe das Beispiel mit dem ISDN Signalling. > > > Und auf die Gefahr dass das hier schon mal breitgtreten wurde: > Realnames f?rdern die Gespr?chskultur ;). > Ja! Aber nachdem das Verhalten immer dreister wird, auf jedwede Art an Informationen zu kommen, um sie in durchaus krimineller Weis zu missbrauchen, werde ich immer vorsichtiger. Daher hier zB eine Adresse f?r Listen, die ich irgendwann mal wechseln werde. Adressen, Namen, Wohnanschriften werden bezahlt, am teuersten sind zB die von ?lteren Damen mit deren vollst. Adresse inkl. ihrer Bankverbindung, so etwas ist einfach erschreckend. Ich denke, dass daher leider auch die Listen-Gespr?chskultur sich anpassen wird, denn es ist ja jetzt nicht mehr nur noch ein Penisverg??erungsangebot oder noch ein 0,01 USD-Aktie, die morgen 100 $ kosten wird. Mit online-Telefonb?chern ist es einfach, aus vollst?ndigen Namen komplette Adressen zu machen, verbunden mit einem Interessenschwerpunkt n?mlich diese Liste und das zu verkaufen. Ich verstehe mich nicht als paraniod diesbez?glich, ich sehe nur, es ist m?glich, es bringt Geld, einer wird's schon machen. Calli ( das ist doch schon fast ein Realname ;) From robe at amd.co.at Tue May 29 07:06:32 2007 From: robe at amd.co.at (Michael Renner) Date: Tue, 29 May 2007 16:06:32 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <200705291453.12904.gooly@gmx.at> References: <200705251809.18277.gooly@gmx.at> <200705290900.57402.gooly@gmx.at> <465BE8F7.1080209@amd.co.at> <200705291453.12904.gooly@gmx.at> Message-ID: <465C3368.5070305@amd.co.at> gooly at gmx.at wrote: >> Und auf die Gefahr dass das hier schon mal breitgtreten wurde: >> Realnames f?rdern die Gespr?chskultur ;). >> > Ja! > > Aber nachdem das Verhalten immer dreister wird, auf jedwede Art an > Informationen zu kommen, um sie in durchaus krimineller Weis zu > missbrauchen, werde ich immer vorsichtiger. Daher hier zB eine Adresse > f?r Listen, die ich irgendwann mal wechseln werde. Adressen, Namen, > Wohnanschriften werden bezahlt, am teuersten sind zB die von ?lteren > Damen mit deren vollst. Adresse inkl. ihrer Bankverbindung, so etwas > ist einfach erschreckend. > > Ich denke, dass daher leider auch die Listen-Gespr?chskultur sich > anpassen wird, denn es ist ja jetzt nicht mehr nur noch ein > Penisverg??erungsangebot oder noch ein 0,01 USD-Aktie, die morgen 100 $ > kosten wird. Mit online-Telefonb?chern ist es einfach, aus > vollst?ndigen Namen komplette Adressen zu machen, verbunden mit einem > Interessenschwerpunkt n?mlich diese Liste und das zu verkaufen. > > Ich verstehe mich nicht als paraniod diesbez?glich, ich sehe nur, > es ist m?glich, es bringt Geld, einer wird's schon machen. Mit Spamassassin, einer monatlichen Kontrolle der Konto- und Kreditkartenausz?ge und nach Notwendigkeit einer Faustfeuerwaffe, Kampfmesser und/oder Nahkampfausbildung sollte man auf alle Eventualit?ten des Lebens und Gefahren des Internets ausreichend vorbereitet sein ;). Michael, der seit mehr als einer Dekade sicher und ungest?rt im Netz unterwegs ist. From gooly at gmx.at Tue May 29 07:32:23 2007 From: gooly at gmx.at (gooly at gmx.at) Date: Tue, 29 May 2007 16:32:23 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <1180429028.9989.38.camel@tara.firmix.at> References: <200705251809.18277.gooly@gmx.at> <200705290900.57402.gooly@gmx.at> <1180429028.9989.38.camel@tara.firmix.at> Message-ID: <200705291632.23631.gooly@gmx.at> Am Dienstag, 29. Mai 2007 schrieb Bernd Petrovitsch: > On Tue, 2007-05-29 at 09:00 +0200, gooly at gmx.at wrote: > > Am Montag, 28. Mai 2007 schrieb Bernd Petrovitsch: > > > On Mon, 2007-05-28 at 19:56 +0200, gooly at gmx.at wrote: > > > > Am Montag, 28. Mai 2007 schrieb Peter J. Holzer: > > [...] > > > Perl hat - wie jede Interpretersprache - das zus?tzliche Handikap, > da? Du einen echtzeitf?higen Interpreter drunter brauchst. > Und wenn unter den Applikationen ein Kernel l?uft, dann m?ssen die > Systemcalls auch zeitliche Vorgaben einhalten. > Ja, es gibt POSIX RealTime Zeugs im Linux-Kernel. Nein, f?r harte > Echtzeit ist das unbrauchbar, da mu?t Du schon z.B. RTAI verwenden > (f?r die Echtzzeittasks). Ok, aber meine Notwendigkeit ist 'so hart' nun nicht, die Anwendungsbeispiele sind Laserschneidemaschienen, da kann ich es gem?tlicher angehen.. > > Gut, denkbar sind Systeme, die so schnell sein m?ssen, dass man zum > > Maschinencode greift, aber das ist eine andere Geschichte, und f?r > > mich > > Da gibt es aber nur wenige Spezialf?lle, wo Assembler wirklich > nennenswert schneller ist wie irgendeine kompilierte Hochsprache. Bei > Interpretersprachen (perl, JVM, ...) h?ngt es dann auch noch vom > Interpreter drunter ab. > > > nicht notewendig. Aber ich sehe keinen Nachteil Perls gegen?ber > > anderen Sprachen, im Gegenteil, es ist sogar schneller als mach > > andere moderne Hoichsprache, wie zB Java. > > Es geht nicht um die Geschwindigkeit der Ausf?hrung (die ist im > Prinzip irrelevant solange die maximale Dauer garantiert werden > kann), sondern - bei harter Echtzeit - darum 100% zuverl?ssige > Aussagen (im Idealfall beweisbar) ?ber das Verhalten in der Zeit zu > machen (unter einer gegebenen Fehlerhypothese). > > Anderes Beispiel: Es gibt das RTnet Projekt. Da bauen Leute > Echtzeit-Kommunikation ?ber handels?bliches Ethernet mit CotS > Hardware. Auf Ethernet wird CSMA/CD CSMA/CA o.?. eingesetzt. Nur sind > Kollisionen wenig deterministisch, ergo d?rfen die nicht passieren. > Was macht man? Man legt statisch fest, wer wann sendet. Das sind dann wohl Dinge, die gemeinsam synchron arbeiten m?ssen, ich habe bei mir bewusst alles so angelegt, dass ich Kette habe, immer eines nach dem anderen. Nach jedem Kettenglied kann ich verzweigen, zB zu dem n?chsten und dessen 'shadow'. > > Frage: Setzt man dann Hubs (Multi-Port-Repeater) oder Switches > (Multi-Port-Bridges) ein und warum? > > Antwort: Man setzt *selbstverst?blich* nur Hubs ein, weil Switches > store-and-forward machen und das in der Zeit nicht kontrollierbar > ist. interessant, das wusste ich so im Detail nicht. > Und man setzt auch besser 10MBit-Hubs statt 10GBit-Switches ein > - es interessiert niemanden, da? das vielleicht viel langsamer als > ein Switch ist. ok, aber wenn man diese Beweisnotwendigkeit nicht hat. > > Im engeren Sinn, nein. Ich wollte nur sichergehen, da? wir "Echtzeit" > gleich definieren. Naja, was Echtzeit ist, h?ngt doch von den Erfordernissen des Projektes ab. Du selbst unterscheidest ja in 'harte' und 'soft'. Versteh mich nicht falsch, ich widerspreche nicht so sehr dem Inhalt, als vielmehr Deiner 'strictness'. Die Unterscheidung zwischen hart und soft ist nicht immer eindeutig! > Im weiteren Sinn: Nat?rlich. Schlie?lich mu? *jeder* Aspekt > echtzeitf?hig sein. Wenn die ach-so-tolle-Programmiersprache > transparent (und damit zwingend *unkontrollierbar*) z.B. Garbage > Collection macht, dann ist sie daf?r unbrauchbar. ok! Aber Perl hatt ja dann noch den Vorteil, man kann es in C wandeln :) > > Und wie bei jeder technischen Spezifikation kann man nie einen > > genauen Zielwert angeben, sondern immer nur einen zusammen mit > > einer zu erreichenden Tolleranz! Auch das ist in Perl erreichbar: > > Je nach > > Tja, bei Echtzeitsystemen *sind* die genauen Zielwerte vorgegeben und > die Toleranz ist - bei harter Echtzeit - idR 0 (andernfalls addiert > man die Toleranz gleich zum Zielwert und ist bei Toleranz 0). Auch wenn das ein Streit um des Kaisersbart sein k?nnte, Zielwerte mit definierten Toleranzen halte ich f?r die sinnvollere Ausdrucksweise. Sie trennt deutlich das erwartete, zeitliche (Normal-) Verhalten eines Systems von den unerwarteten aber akzeptierten oder erwarteten Schwankungen oder Verz?gerungen. > Und dann mu? man das gesamte System so designen, da? die Zielwerte > auch eingehalten werden. > Deswegen l?st das Einf?hren eine Toleranz in der Zeit nicht das > Problem sondern bestenfalls zum a posteriori Messen des "Restriskos" > ben?tzt werden (wenn ?berhaupt). > > Und wenn das nicht geht, kann man das System eben nicht bauen. > Entweder kann man mit anderen Zielwerten leben (die dann auch wieder > als feste Vorgabe betrachtet werden) oder man l??t es (und das > Projekt ist tot). Es gibt - akademisch betrachtet - keine andere > L?sung. > > > Schnelligkeitsanforderung muss man halt auf das Gesamsystem > > schauen, oder wie Du sagt Hardware bewerfen :). > > Pures Hardware draufwerfen bringt keine zeitlichen Garantien sondern > reduziert nur das Restrisiko. > > > Und wenn Perl dann nicht schnell genug ist, ist wahrscheinlich auch > > C nicht schnell genug - auf diesem System. > > Und wie gesagt, Perl ist praktisch so schnell wir C. Das Problem > > w?re also so nicht Perl. > > Ich glaube nicht, da? z.B. der Garbage-Collector in perl irgendwelche > zeitlichen Garantien gibt (und die perl Gurus werden das korrigieren, > wenn es nicht stimmt). > Wie willst du da Aussagen ?ber das Verhalten in der Zeit treffen. Da > helfen auch "Toleranzen" nichts, weil du die Einhaltung derselben > auch nicht garantieren kannst. Du hast Recht, aber auch hier ist es eine Frage des Projektes, ob es akzeptabel ist - auch der l?uft ja nicht Minuten lang, denke ich mal - oder nicht. > Es gibt nicht im Linux-Kernel, da? zeitliche Angaben ?ber die Dauer > der Systemcalls macht. Wenn jemand z.B. per Floodping derma?en viele > Hardware-Interrupts erzeugt, da? alles viel l?nger braucht, wie > willst du das einkalkulieren. In dem das niemand machen kann oder wird, weil ich mich zB im Netz verstecke. > OK, man macht ein eigenes LAN, wo nur definierte Knoten mit > definiertem Verhalten/Applikationen "mitspielen" d?rfen. Genau. > Und alle hunderte andere M?glichkeiten, IRQ-Storms zu erzeugen, mu?t > du jetzt auch noch l?sen. > BTW ist das mit ein Grund, warum Interrupts bei Echtzeitsystmen > normalerweise vermieden werden und Polling das Mittel der Wahl ist. Eigentlich mach ich ja genau das mit meiner Kette. Nur am Anfang dieser Kette wartet 'der Erste' auf die Daten, um ihnen den Zeitstempel zu verpassen und dann werden im 'Zweiten' daraus 1-Min-Bars, der wartet auf die 'Zeit' + Toleranz von 1,2 Sek um die Daten mit dem Zeitstempel :00 noch mitzunehmen. :) Zielwert ist die genaue Minute :00, das ist aber unrealstisch und ich brauch eine Toleranz von 0.5 Sek, die durchaus akzeptabel sind. Ist auch leichter und verst?ndlicher zu Programmieren. > [...] > > > > Tja, der Hund bei Echtzeitsystemen als solchen ist, da? Du nur > > > das gesamte System dann und nur dann echtzeitf?hig bekommst, wenn > > > Du ganz unten damit anf?ngst. > > > Wenn nicht, dann mu? du mit dem Restrisiko leben. Das mag gr??er > > > oder kleiner sein und Du kannst es mit Hardware bewerfen, aber Du > > > wirst es mit Hardware nicht erschlagen k?nnen. > > > > Naja, es ist erschlagen, wenn Du Toleranzen definierts und > > innerhalb derer bleibst.. > > Ja, aber woher wei? ich *a priori* *verl??lich*, da? die Zeit > eingehalten wird? Verzeih, das ist ein bi?chen so ein typische Totschalargument, 100% sicher ist nix! > Ein Lasttest ist jedenfalls viel zu wenig - auch wenn er (angeblich) > die x-fache Last simuliert. Man kann sich nur auf 'wissbares' vorbereiten und auch hier wird man ganz bewu? gewisse Risiken akzetieren: Was ist wenn jemand einbricht und den pc klaut? Auf einmal ein ganz schlechtes Echtzeitverhalten ;) > > Oder deine Toleranz ist halt: Ich lebe damit, da? das Ergebnis > gelegentlich zu sp?t kommt. Neee, es kommt sp?ter, aber es schadet nicht, es ist ja einkalkuliert! > Und genau das ist das Restrisiko. Das Restrisko bezeichnet doch eher (Wahrscheinlichkeiten von) Ereignissen, die das Ergebniss des Gesamtsystem verschlechtert. Calli From bernd at firmix.at Tue May 29 09:03:45 2007 From: bernd at firmix.at (Bernd Petrovitsch) Date: Tue, 29 May 2007 18:03:45 +0200 Subject: [Vienna-pm] anmerkungen .. In-Reply-To: <200705291632.23631.gooly@gmx.at> References: <200705251809.18277.gooly@gmx.at> <200705290900.57402.gooly@gmx.at> <1180429028.9989.38.camel@tara.firmix.at> <200705291632.23631.gooly@gmx.at> Message-ID: <1180454625.29349.38.camel@tara.firmix.at> On Tue, 2007-05-29 at 16:32 +0200, gooly at gmx.at wrote: > Am Dienstag, 29. Mai 2007 schrieb Bernd Petrovitsch: [...] > > Perl hat - wie jede Interpretersprache - das zus?tzliche Handikap, > > da? Du einen echtzeitf?higen Interpreter drunter brauchst. > > Und wenn unter den Applikationen ein Kernel l?uft, dann m?ssen die > > Systemcalls auch zeitliche Vorgaben einhalten. > > Ja, es gibt POSIX RealTime Zeugs im Linux-Kernel. Nein, f?r harte > > Echtzeit ist das unbrauchbar, da mu?t Du schon z.B. RTAI verwenden > > (f?r die Echtzzeittasks). > Ok, aber meine Notwendigkeit ist 'so hart' nun nicht, die > Anwendungsbeispiele sind Laserschneidemaschienen, da kann ich es > gem?tlicher angehen.. Gut, dann hast im Prinzip ein Soft-Realtime-System. [...] > > Und man setzt auch besser 10MBit-Hubs statt 10GBit-Switches ein > > - es interessiert niemanden, da? das vielleicht viel langsamer als > > ein Switch ist. > ok, aber wenn man diese Beweisnotwendigkeit nicht hat. Soft-Realtime. > > Im engeren Sinn, nein. Ich wollte nur sichergehen, da? wir "Echtzeit" > > gleich definieren. > Naja, was Echtzeit ist, h?ngt doch von den Erfordernissen des Projektes Der Begriff "Echtzeit" ist fest definiert - unabh?ngig vom Projekt. *Ob* Dein Projekt das Wort "Echtzeit" verwenden sollte, ist die Frage. > ab. Du selbst unterscheidest ja in 'harte' und 'soft'. Ja, beides sind echte Untermengen von "Echtzeit", um da nochmal eine sinnvolle Unterteilung zu haben. IIRC gab/gibt es auch eine dritte, aber die hab ich verdr?ngt. > Versteh mich nicht falsch, ich widerspreche nicht so sehr dem Inhalt, > als vielmehr Deiner 'strictness'. Die Unterscheidung zwischen hart und > soft ist nicht immer eindeutig! Wie bei vielen "Prosa-definierten" Konzepten. Aber ich seh' bei der von mir gebrachten Unterscheidung wenig Mi?verst?ndlichkeit bzw. Unklarheit, d.h. ich hab noch nichts erlebt, wo es nicht relativ klar ist. Aber ich lerne gerne dazu. > > Im weiteren Sinn: Nat?rlich. Schlie?lich mu? *jeder* Aspekt > > echtzeitf?hig sein. Wenn die ach-so-tolle-Programmiersprache > > transparent (und damit zwingend *unkontrollierbar*) z.B. Garbage > > Collection macht, dann ist sie daf?r unbrauchbar. > ok! Aber Perl hatt ja dann noch den Vorteil, man kann es in C wandeln :) Ja, und dann gehen wir alle aufgerufenen Libraryfunktionen kontrollieren. > > > Und wie bei jeder technischen Spezifikation kann man nie einen > > > genauen Zielwert angeben, sondern immer nur einen zusammen mit > > > einer zu erreichenden Tolleranz! Auch das ist in Perl erreichbar: > > > Je nach > > > > Tja, bei Echtzeitsystemen *sind* die genauen Zielwerte vorgegeben und > > die Toleranz ist - bei harter Echtzeit - idR 0 (andernfalls addiert > > man die Toleranz gleich zum Zielwert und ist bei Toleranz 0). > Auch wenn das ein Streit um des Kaisersbart sein k?nnte, Zielwerte mit > definierten Toleranzen halte ich f?r die sinnvollere Ausdrucksweise. > Sie trennt deutlich das erwartete, zeitliche (Normal-) Verhalten eines > Systems von den unerwarteten aber akzeptierten oder erwarteten > Schwankungen oder Verz?gerungen. Ja, das mag bei Best-Effort-Systemen (das sind alle, die nicht "Echtzeit sind) praktischer und sinnvoll sein. Bei Echtzeitsystemen interessiert der "erwartete Normalfall" nicht wirklich, weil man so ein System auf den Worst-Case dimensioniert (und wenn im Normalbetrieb 90% der Kapazit?t nicht ausgen?tzt werden, weil man sie nur f?r Extremsituationen braucht, dann ist es halt so. Immer besser als mehr Flugzeuge, die wenig kontrolliert herunterkommen). > > Ich glaube nicht, da? z.B. der Garbage-Collector in perl irgendwelche > > zeitlichen Garantien gibt (und die perl Gurus werden das korrigieren, > > wenn es nicht stimmt). > > Wie willst du da Aussagen ?ber das Verhalten in der Zeit treffen. Da > > helfen auch "Toleranzen" nichts, weil du die Einhaltung derselben > > auch nicht garantieren kannst. > Du hast Recht, aber auch hier ist es eine Frage des Projektes, ob es Es ist immer eine Frage des Projektes, *ob* es eine Echtzeit-System (und wenn ja, ob "hart2 oder "weich") ist oder nicht und wieviel "Fehler" toleriert werden k?nnen (sowohl Fehler im Zeit- wie im Wertebereich). Wir k?nnen auch dr?ber streiten, ob es noch ein "Fehler" ist, wenn die Ungenauigkeit eh einkalkuliert ist. Nur wenn jemand kommt und sagt, "wir haben da ein Echtzeitprojekt und programmieren es in perl" dann sagt mir meine Erfahrung, das >90% der Leute nicht wissen, was sie da sagen (Anwesende nat?rlich ausgenommen) und da das Buzzword ben?tzen, weil es cool klingt und $KUNDE (oder sonstwen) beeindruckt. > akzeptabel ist - auch der l?uft ja nicht Minuten lang, denke ich mal - > oder nicht. Ich wei? nicht, was der Worst Case ist. Ich wei? nicht mal, ob es jemand wei?. [...] > > Und alle hunderte andere M?glichkeiten, IRQ-Storms zu erzeugen, mu?t > > du jetzt auch noch l?sen. > > BTW ist das mit ein Grund, warum Interrupts bei Echtzeitsystmen > > normalerweise vermieden werden und Polling das Mittel der Wahl ist. > Eigentlich mach ich ja genau das mit meiner Kette. Nur am Anfang dieser > Kette wartet 'der Erste' auf die Daten, um ihnen den Zeitstempel zu > verpassen und dann werden im 'Zweiten' daraus 1-Min-Bars, der wartet > auf die 'Zeit' + Toleranz von 1,2 Sek um die Daten mit dem > Zeitstempel :00 noch mitzunehmen. > :) Zielwert ist die genaue Minute :00, das ist aber unrealstisch und ich > brauch eine Toleranz von 0.5 Sek, die durchaus akzeptabel sind. > Ist auch leichter und verst?ndlicher zu Programmieren. Gut so, wenn es bei Dir eine so "einfache" L?sung gibt. [...] > > Ja, aber woher wei? ich *a priori* *verl??lich*, da? die Zeit > > eingehalten wird? > Verzeih, das ist ein bi?chen so ein typische Totschalargument, 100% > sicher ist nix! Aber es definiert das Ziel sehr klar (und um der Erkenntnis Willen bringe ich einfache und klare Aussagen wohl wissen, da? es nicht die ganze Wahrheit bis ins letzte ist). Und es gibt Situationen, da will man keine Kompromi? eingehen: W?rdest Du in einen Airbus (oder Boeing oder ...) steigen, wo schon in der *Spezifikation* das Wort "Restrisiko" oder "in 99,9% aller F?lle" vorkommt? > > Ein Lasttest ist jedenfalls viel zu wenig - auch wenn er (angeblich) > > die x-fache Last simuliert. > Man kann sich nur auf 'wissbares' vorbereiten und auch hier wird man > ganz bewu? gewisse Risiken akzetieren: Was ist wenn jemand einbricht > und den pc klaut? Auf einmal ein ganz schlechtes Echtzeitverhalten ;) Ja, das war mit der definierten Fehlerhypothese gemeint. Niemand kann (im Moment) ein System bauen, da? alle Fehler handlen kann (und wenn, ist vermutlich das System zu nix wirklich brauchbar;-). D.h. man mu? sich die Fehler definieren, die man ?berleben will. Wenn die Fehlerhypothese der Realit?t widerspricht, dann hat man ein seri?ses Problem. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services From domm at cpan.org Tue May 29 12:48:34 2007 From: domm at cpan.org (Thomas Klausner) Date: Tue, 29 May 2007 21:48:34 +0200 Subject: [Vienna-pm] Linuxwochen Message-ID: <20070529194834.GA28794@i85.chello.at> Hi! Donnerstag 31. Mai 10:00 bis Samstag 2. Juni 2007 22:00 Urania A-1010, Uraniastra??e 1 ** Freier Eintritt ** http://linuxwochen.at/2007/Wien Wir machen einen Perl-Tisch! Dazu waere es super, wenn noch jemand Zeit haette (es gibt Strom und Netz, d.h. man kann auch nebenbei "arbeiten") Ich kann naemlich am DO kaum (hab eine Besprechung im Buero), am FR muss ich um ca 13:00 weg (Kinder (und die Freundin hat natuerlich ein Dissertationsseminar..)), aber am SA bin ich den ganzen Tag dort (ausser von 12:00-13:00, wo ich 2 vortraege ueber Testing mache (in Konkurrenz zur 100$-Laptop-praesentation, mal schaun ob ich Publikum haben werde...) Neben allgemeiner Perl-Propagande moechte ich auch die YAPC stark bewerben - und wir haben einige $foo-Magazine zum "verkaufen" (gegen Spende, fuer Vienna.pm Mitglieder gratis!) Bitte ein kurzes Mail an mich, wer wann noch zum Perl-Tisch kommen mag (vor allem FR nachmittag waere wichtig!) bis dann! -- #!/usr/bin/perl http://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From domm at cpan.org Tue May 29 13:29:22 2007 From: domm at cpan.org (Thomas Klausner) Date: Tue, 29 May 2007 22:29:22 +0200 Subject: [Vienna-pm] Einladung zur ordentlichen Generalversammlung 2007 der Vienna Perl Mongers Message-ID: <20070529202921.GC28794@i85.chello.at> Einladung zur ordentlichen Generalversammlung der Vienna Perl Mongers Verein zur Foerderung der Programmiersprache Perl am 13. Juni 2007, 19:00 im "Mocca Club", Linke Wienzeile 4, 1060 Wien Tagesordnung: 1. Begruessung 2. Genehmigung der Tagesordnung 3. Bestaetigung der Rechnungspruefer fuer das abgelaufene Jahr 4. Bericht des Obmannes 5. Bericht des Kassiers 6. Bericht der Rechnungspruefer 7. Entlastung des Vorstandes 8. Neuwahl des Vorstandes Wahlvorschlag: Obmann Thomas Klausner Schriftfuehrer Peter J. Holzer Kassier Roland Lammel 9. Bestellung der Rechnungspruefer fuer das kommende Jahr 10. Eingelangte Antraege Antraege koennen bis spaetestens 10. Juni bei einem der Vorstandsmitglieder (bevorzugt beim Schriftfuehrer) per E-Mail eingereicht werden. Auf ein zahlreiches Erscheinen freut sich der Vorstand der Vienna Perl Mongers -- #!/usr/bin/perl http://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}