Google zveřejnil seznam 1 141 projektů (vývojářů) od 184 organizací přijatých do letošního, již dvaadvacátého, Google Summer of Code. Přihlášeno bylo celkově 23 371 projektů od 15 245 vývojářů ze 131 zemí.
Na čem pracovali vývojáři GNOME a KDE Plasma minulý týden? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Open source počítačová hra na hrdiny NetHack (Wikipedie, GitHub) byla vydána v nové verzi 5.0.0. První verze této hry byla vydána v roce 1987.
Evropská komise naléhavě vyzvala členské státy EU, aby kvůli ochraně nezletilých na internetu urychlily zavádění unijní aplikace pro ověřování věku a zajistily její dostupnost do konce roku. Členské státy mohou zavést aplikaci EU pro ověřování věku jako samostatnou aplikaci nebo ji integrovat do takzvané evropské peněženky digitální identity.
Richard Biener oznámil vydání verze 16.1 (16.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 16. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Zulip Server z open source komunikační platformy Zulip (Wikipedie, GitHub) byl vydán ve verzi 12.0. Přehled novinek v příspěvku na blogu.
Před 30 lety, tj. v úterý 30. dubna 1996, byl spuštěn Seznam.cz.
Byly zpracovány a zveřejněny všechny videozáznamy, které stojí za zveřejnění, z konference FOSDEM 2026.
Od úterý 28. dubna musí nově uváděné notebooky v Evropské unii podporovat nabíjení přes USB-C. Jednotná nabíječka byla schválena Evropským parlamentem v říjnu 2022.
Byly publikovány informace o kritické zranitelnosti CVE-2026-31431 pojmenované Copy Fail v Linuxu, konkrétně v kryptografii (AF_ALG). Běžný uživatel může získat práva roota (lokální eskalaci práv). Na všech distribucích Linuxu vydaných od roku 2017. Pomocí 732bajtového skriptu. V upstreamu je již opraveno. Zranitelnost byla nalezena pomocí AI Xint Code.
Zdravim vsechny,
Vstup
Ma nekdo nejaky napad na chytry algoritmus?
#!/usr/bin/perl
use 5.010;
use warnings;
use strict;
use List::Util qw{first};
use Benchmark;
our $VERSION = 0.001;
my $string =
'234781802319q8019810328103982104398021483049823094830498023982094823028340932840923830483201223';
my @multiregexp = ( qr{ \A \d+ . \z }msx, qr{ \$ }msx, );
timethese(
1000000,
{
more => sub {
my $trueregexp = first { $string ~~ $_ } @multiregexp;
},
one => sub { my $tt = $string ~~ m{\A \d+ . \z|\$}msx ? 1 : 0; },
one_better =>
sub { my $tt = $string ~~ m{\A \d+ . \z|\A .* \$ .* \z}msx ? 1 : 0; },
}
);
mi vypíše
Benchmark: timing 1000000 iterations of more, one, one_better...
more: 3 wallclock secs ( 2.72 usr + 0.00 sys = 2.72 CPU) @ 367647.06/s (n=1000000)
one: 14 wallclock secs (13.69 usr + 0.01 sys = 13.70 CPU) @ 72992.70/s (n=1000000)
one_better: 12 wallclock secs (12.06 usr + 0.00 sys = 12.06 CPU) @ 82918.74/s (n=1000000)
když $string upravím a přidám na konec $, tak
more: 3 wallclock secs ( 3.21 usr + 0.00 sys = 3.21 CPU) @ 311526.48/s (n=1000000)
one: 12 wallclock secs (13.74 usr + 0.00 sys = 13.74 CPU) @ 72780.20/s (n=1000000)
one_better: 1 wallclock secs ( 2.04 usr + 0.00 sys = 2.04 CPU) @ 490196.08/s (n=1000000)
a když smažu q z takto upraveného $string
more: 3 wallclock secs ( 2.18 usr + 0.00 sys = 2.18 CPU) @ 458715.60/s (n=1000000)
one: 1 wallclock secs ( 1.39 usr + 0.00 sys = 1.39 CPU) @ 719424.46/s (n=1000000)
one_better: 0 wallclock secs ( 1.36 usr + 0.00 sys = 1.36 CPU) @ 735294.12/s (n=1000000)
atp.
first ještě dá na výstup, který ten regexp bude true
ještě se to dá otestovat jako
more_better => sub {
my $tt = $string ~~ @multiregexp ? 1 : 0;
}
které je nejrychlejší ve všech předešlých případech
use 5.010;
use warnings;
use strict;
use List::Util qw{first};
our $VERSION = 0.001;
my $string =
'23478180231x98019810328103982104398021483049823094830498023982094823028340932840923830483201223$';
my @multiregexp = ( qr{ \A \d+ . \z }msx, qr{ \$ }msx, );
my $trueregexp = first { $string ~~ $_ } @multiregexp;
say 'tento regexp vyhovuje ', $trueregexp;
a když to nebude dostatečně rychlé, tak to chce vědět více o těch regexp-ech popř. o tom řetězci, aby se dalo navrhnout něco efektivnějšího
Takze dekuji vsem za kometare.
Spojeni do jednoho velkeho regexpu jak je navrzeno vyse by snad splnilo podminku na rychle vyhledavani, nicmene jsem skoncil na tom ze je potreba i pomerne rychla reakce na to kdyz uzivatel nejaky regulani vyraz prida/ubere/zmeni a konstrukce toho dloooouheho regularniho vyrazu a jeho kompilace je prilis pomala.
Vysledne reseni je nakonec zalozene na tom, ze ty regularni vyrazy - tedy alespon vetsinaz nich ma v sobe nejaky pevny retezec, napriklad "[0-9]ABC[0-9]" a pomoci techto retezcu lze udelat index a v tom indexu najit podmnozinu regexu ktere se pak matchuji sekvencne. Vetsinou jsou to regexy slozitejsi nez v tom prikladu, ale obvykle to jde a tech par stovek regexu, ze kterych se neda nejaky rozumny retezec vyextraovat se bude prochazet sekvencne az kdyz se nenajde jinde.
Tiskni
Sdílej: