Desktopové prostředí Budgie bylo vydáno ve verzi 10.10. Dokončena byla migrace z X11 na Wayland. Budgie 10 vstupuje do režimu údržby. Vývoj se přesouvá k Budgie 11. Dlouho se řešilo, v čem bude nové Budgie napsáno. Budgie 10 je postaveno nad GTK 3. Přemýšlelo se také nad přepsáním z GTK do EFL. Budgie 11 bude nakonec postaveno nad Qt 6.
OpenChaos.dev je 'samovolně se vyvíjející open source projekt' s nedefinovaným cílem. Každý týden mohou lidé hlasovat o návrzích (pull requestech), přičemž vítězný návrh se integruje do kódu projektu (repozitář na GitHubu). Hlasováním je možné změnit téměř vše, včetně tohoto pravidla. Hlasování končí vždy v neděli v 9:00 UTC.
Byl vydán Debian 13.3, tj. třetí opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.13, tj. třináctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Na stránkách Evropské komise, na portálu Podělte se o svůj názor, se lze do 3. února podělit o názor k iniciativě Evropské otevřené digitální ekosystémy řešící přístup EU k otevřenému softwaru.
Společnost Kagi stojící za stejnojmenným placeným vyhledávačem vydala (𝕏) alfa verzi linuxové verze (flatpak) svého proprietárního webového prohlížeče Orion.
Firma Bose se po tlaku uživatelů rozhodla, že otevře API svých chytrých reproduktorů SoundTouch, což umožní pokračovat v jejich používání i po plánovaném ukončení podpory v letošním roce. Pro ovládání také bude stále možné využívat oficiální aplikaci, ale už pouze lokálně bez cloudových služeb. Dokumentace API dostupná zde (soubor PDF).
Jiří Eischmann se v příspěvku na svém blogu rozepsal o open source AdGuard Home jako domácí ochraně nejen před reklamou. Adguard Home není plnohodnotným DNS resolverem, funguje jako DNS forwarder s možností filtrování. To znamená, že když přijme DNS dotaz, sám na něj neodpoví, ale přepošle ho na vybraný DNS server a odpovědi zpracovává a filtruje dle nastavených pravidel a následně posílá zpět klientům. Dá se tedy používat k blokování reklamy a škodlivých stránek a k rodičovské kontrole na úrovni DNS.
AI Claude Code od Anthropicu lépe rozumí frameworku Nette, tj. open source frameworku pro tvorbu webových aplikací v PHP. David Grudl napsal plugin Nette pro Claude Code.
Byla vydána prosincová aktualizace aneb nová verze 1.108 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.108 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Na lasvegaském veletrhu elektroniky CES byl předveden prototyp notebooku chlazeného pomocí plazmových aktuátorů (DBD). Ačkoliv se nejedná o první nápad svého druhu, nepochybně to je první ukázka praktického použití tohoto způsobu chlazení v běžné elektronice. Co činí plazmové chladící akční členy technologickou výzvou je především vysoká produkce jedovatého ozonu, tu se prý podařilo firmě YPlasma zredukovat dielektrickou
… více »
14.7.2006 16:29
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
1. Klasický zásobník je samozřejmě rychlý, ale rekurzivní implementace na něj ukládá mnohonásobně víc dat, než je potřeba. Jeho velikost je navíc omezena a na některých platformách je to omezení dost výrazné. Navíc je to omezení, se kterým prostě nehnete.
2. Realokovat není (obecně) potřeba a není ani nutné alokovat obrovské pole předem. Zásobník totiž vůbec nemusí být realizován jako lineární pole.
3. Snadno nahlédneme, že paměťové nároky řešení s vlastním zásobníkem jsou už z principu nižší než paměťové nároky řešení pomocí rekurze. Navíc s tím rozdílem, že pokud dojde místo na systémovém zásobníku, máme smůlu; dojde-li místo v našem zásobníku, dá se s tím něco dělat.
Sečteno a podtrženo: než někoho nařknete, že o problematice nic neví, nebývá od věci ověřit, zda toho sám víte aspoň tolik co on. Vyhnete se tak zbytečné blamáži…
15.7.2006 00:37
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Zásobník totiž vůbec nemusí být realizován jako lineární pole.A třeba takový
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czstd::stack ani není. Protože bývá typicky implementován pomocí std::deque, nepotřebuje souvislý úsek paměti.
#include <stdio.h>
int q(int i) {
printf("%d\n", i);
q(i+1);
}
int main(int argc, char** argv) {
q(0);
}
a nez to spadlo, tak napocital do 523 722. A dost pochybuju, ze by se algoritmus pri razeni nekolika souboru v adresari nekdy dostal do srovnatelny hloubky
A dost pochybuju, ze by se algoritmus pri razeni nekolika souboru v adresari nekdy dostal do srovnatelny hloubkyHehe. Takto by programátor uvažovat neměl.
, ale pokud provedu jenom hrubej vypocet, tak v idealnim pripade (pokud by se mu podarilo pole rozdelit vzdy presne na pul) by se do tyto hloubky dostal az pri poli velkym 2**523722 = 10e19 polozek. ono se mu to sice pravdepodobne vetsinou nepodari rozdelit presne na pul, ale stejne by to melo stacit na hodne hodne hodne velky pole...
2. A co takhle spojový seznam z jednotlivých polí vhodně zvolené velikosti? Realokovat není potřeba nic, alokovat nemusím tak často, overhead na spojovací pointer je zanedbatelný. Jinak ani kdyby to byl opravdu čistý spojový seznam, nemáte pravdu, protože ten pointer má z podstaty věci přesně stejnou velikost jako návratová adresa (kterou tam pro změnu nutně potřebujete vy) - a pořád ušetřím nějaké ty lokální proměnné.
3. Ne. Opakuji, že při rozumné implementaci zásobníku není potřeba nic realokovat.
Ad P.S.: porovnejte si celkovou velikost lokálních proměnných a argumentů u vašeho testovacího prográmku a u implementace, o níž tu byla řeč. Pořád sice zbyde relativně velké číslo, ale jak už jsem řekl, existují i jiné platformy.
Mimochodem, netvrdím, že rekurze je vždy špatná. Jen zásadně nesouhladím s důvody, které pro její upřednostnění uvádíte.
počet prvků = počet tříděných prvků / 2, tedy např. pro třídění pole int indexované int bude mít stejnou velikost, jako tříděné pole, pro třídění řetězců bude zabírat zlomek paměti zabrané tříděným seznamem. Opravdu monstrózní paměťové nároky…
Gcc umí aspoň tail recursion, aspoň občas, když už ne obecně.) Hromada rekurzivních volání jsou jen skoky s přejmenováním parametrů. Jak je to u quicksortu, to se budu muset podívat – docela mě to zajímá a už byh si ho měl konečně taky jednou naimplementovat. Ale přesto mi přijde, že hromada lidí šmahem odsuzuje rekurzi proto, že nikdy neviděli kompilátor, který ji dokáže vyeliminovat. A přitom to může být tak pěkné (a bezpečné) goto s parametry...
btw, ked uz vykon (a pamat), radsej by som pouzil radix sort
14.7.2006 16:29
int (*compare)(FileInfo *, FileInfo *, bool);
switch( column )
{
case 0:
compare = &FileInfoList::compare_name;
break;
case 1:
compare = &FileInfoList::compare_ext;
break;
case 2:
compare = &FileInfoList::compare_size;
break;
case 3:
compare = &FileInfoList::compare_date;
break;
case 4:
compare = &FileInfoList::compare_attrs;
break;
case 5:
compare = &FileInfoList::compare_owner;
break;
default:
compare = &FileInfoList::compare_group;
break;
}
for( FileInfoList::size_type i = 0; i < list->count(); ++i )
{
if( i == nCentral ){
same.push_back( list->at(nCentral) );
continue;
}
compareRes = (*compare)( list->at(nCentral), list->at(i), ascending );
/* ... */
a taky porovnavani ascending bych nepsal do kazdy compare fci zvlast ale primo do sort, je to min prace. ale to uz byl jenom takovej kosmetickej detail ;)
14.7.2006 17:22
Jardík | skóre: 40
| blog: jarda_bloguje
14.7.2006 20:31
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Co mne nejak nenapada, ale neni switch jenom if () { } else if () { } else { } ?Obecně být nemusí. Pokud bude kompilátor dostatečné chytrý, může to v řadě případů optimalizovat. Bohužel nevím, jestli to GCC dělá (případně které verze).
Je pravda, že virtual call něco stojí, ale v případě poměrně primitivních mechanismů C++ a relativně složitých porovnávacích funkcí, která vidím v kódu, mi to přijde docela levné. A líp by se to četlo.
) problému, ale právě jsem se vrátil z...společenské události... ...a vůbec, budu se potřebovat pořádně vyspat.
Ovšem po čtení knihy Thinking Forth (ve které každá třetí věta obsahuje sloveso „factor out“ ) cestou domů ovšem působí takovýhle kód prostě jako rána palici do hlavy.
Nemluvě o tom, že už jsem asi hodně odvykl používání Windows, takže samotná myšlenka dělení jména souboru na jméno a příponu mi připadá poněkud nepatřičná…
2. Jeslti dobře vidím, porovnáváte timestampy tak, že je převedete struct time a ty pak složitě porovnáváte po složkách. Nebylo by praktičtější porovnat je rovnou nebo, bojíte-li se tolik o přenositelnost na obskurní platformy, použít difftime()?
14.7.2006 17:22
Jardík | skóre: 40
| blog: jarda_bloguje
isDots(), dostanete vždy -1.
class Comparator;
class CompareFileSize : Comparator; // atd
class FileListInfo {
public static COMPARE_BY_FILE_SIZE;
}
FileInfoList::sort (const Comparator &);
...
file_list->sort (FileListInfo->COMPARE_BY_FILE_SIZE);
file_list->sort (new MyCrazyComparator);
file_list->reverse;
public static COMPARE_BY_FILE_SIZE;asi něco chybí.
14.7.2006 17:57
Jardík | skóre: 40
| blog: jarda_bloguje
file_list->sort(new MyCrazyComparator);Typická ukázka ztracení pointeru (leda, že by pak ta fce na konci volala delete).
14.7.2006 17:59
Jardík | skóre: 40
| blog: jarda_bloguje
14.7.2006 18:32
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
14.7.2006 19:33
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
15.7.2006 08:54
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
14.7.2006 19:40
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
) ved ich nechajme, nech sa hraju )
FileInfoList má členskou funkci, která umí setřídit jinou instanci FileInfoList a pak další členskou funkci, která té první předá svou instanci. To je poněkud avantgardní řešení, ne?
void FileInfoList::sort( FileInfoList* list, int column, bool ascending )
{
…
}
void FileInfoList::sort( int column, bool ascending )
{
sort( this, column, ascending );
}
Zajímavé.
sort(), ale řekl bych, že to je ve srovnání s paměťovou náročností spíše vedlejší problém.
14.7.2006 22:23
Jardík | skóre: 40
| blog: jarda_bloguje
14.7.2006 22:24
Jardík | skóre: 40
| blog: jarda_bloguje
14.7.2006 23:23
Jardík | skóre: 40
| blog: jarda_bloguje
if( list->count() <= 1 ) return;
int (*compare)(FileInfo *, FileInfo *, bool);
switch( column )
{
case 0:
compare = FileInfoList::compare_name;
break;
case 1:
compare = FileInfoList::compare_ext;
break;
case 2:
compare = FileInfoList::compare_size;
break;
case 3:
compare = FileInfoList::compare_date;
break;
case 4:
compare = FileInfoList::compare_attrs;
break;
case 5:
compare = FileInfoList::compare_owner;
break;
default:
compare = FileInfoList::compare_group;
break;
}
#define MAX_LEVELS 1000
FileInfo *piv;
int beg[MAX_LEVELS], end[MAX_LEVELS];
int i=0, L, R, elements = (int)list->count();
beg[0] = 0;
end[0] = elements;
while(i>=0)
{
L = beg[i];
R = end[i] - 1;
if( L < R )
{
if( i == MAX_LEVELS - 1 ) return;
piv = list->at(L);
while( L < R )
{
while(compare(list->at(R),piv,ascending) >= 0 && L<R ) R--;
if(L<R) list->at(L++) = list->at(R);
while(compare(list->at(L),piv,ascending) <= 0 && L<R ) L++;
if(L<R) list->at(R--) = list->at(L);
}
list->at(L) = piv;
beg[i+1] = L+1;
end[i+1] = end[i];
end[i++] = L;
} else {
i--;
}
}
template<typename Item>
void qsort(Item* a, int left, int right, int (*less)(Item a, Item b)) {
int i = left;
int j = right;
Item pivot = a[(i+j)/2];
while(i <= j) {
while(less(a[i], pivot)) i++;
while(less(pivot, a[j])) j--;
if(i < j) {
Item temp = a[i];
a[i] = a[j];
a[j] = temp;
i++; j--;
} else
if(i == j) {
i++; j--;
}
}
if(left < j) qsort(a, left, j, less);
if(i < right) qsort(a, i, right, less);
}
less je funkce, ktera prima dva prvky pole a vraci nenulovou hodnotu, pokud je prvni mensi nez druhy (ma byt v poli pred druhym)
podle me ta posloupnost neni naprosto nahodna, ale je pravdepodobny, ze bude uz castecne serazena
Navíc nevím nic o tom, jak jsou data udržována a obnovována, takže jsem raději vynechal naprosto běžné situace typu přidání nebo přejmenování jednoho souboru.
Další (menší) zdroj neefektivity je i v tom, že se používá at() místo operátoru [], čímž se zbytečně pokaždé testují meze.
15.7.2006 01:07
bool compare_abc(const FileInfo* a, const FileInfo* b)
{
...
}
static bool (*compare_functions[]) = {
compare_abc,
compare_def,
...
}
inline void FileInfoList::sort() {
sort(begin(), end(), compare_functions[column]);
}
15.7.2006 00:24
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
static bool (*compare_functions[])(const FileInfo* a, const FileInfo* b) = {
static bool (*compare_functions[])(const FileInfo*, const FileInfo*) = {
15.7.2006 13:43
Jardík | skóre: 40
| blog: jarda_bloguje
class file_comparator {
protected:
bool ascending;
virtual bool less(const FileInfo* a, const FileInfo* b) = 0;
public:
file_comparator(bool asc) : ascending(asc) {}
virtual ~file_comparator() {}
bool operator () (const FileInfo* a, const FileInfo* b);
};
bool file_comparator::operator () (const FileInfo* a, const FileInfo* b)
{
if (b->isDots()) return false;
if (a->isDots()) return true;
if (a->isDir() && !b->isDir()) return true;
if (b->isDir() && !a->isDir()) return false;
return (ascending ? less(a,b) : less(b,a));
}
class file_comparator_name : public file_comparator {
protected:
virtual bool less(const FileInfo* a, const FileInfo* b);
public:
file_comparator_name(bool asc) : file_compararator(asc) {}
virtual ~file_comparator_name() {}
};
bool file_comparator_name::less(const FileInfo* a, const FileInfo* b)
{
// tady porovnáme jména
}
// a podobně pro další kritéria
void FileInfoList::sort(FileInfoList::column_t column, bool asc)
{
file_comparator* cmp;
switch(column) {
case col_name:
cmp = new file_comparator_name(asc); break;
// ...
default:
// cannot happen
// throw ...;
}
std::sort(begin(), end(), cmp);
delete cmp;
}
(určitě jsou tam chyby, psal jsem to z hlavy a nezkoušel přeložit)
nevraviac o tom, ze v pripade vektora ci double-linked-list je to operacia urcite menej narocna.
. a .. vypisovaly vždy na začátku, pak ostatní adresáře a pak teprve ostatní typy souborů. Tím by se i obracení seznamu trochu zkomplikovalo. Kdyby šlo o prosté otočení pořadí, vůbec nejjednodušší by bylo nepřerovnávat nic a pouze ten seznam v opačném pořadí vypisovat…
to by som radsej pouzil nejake filtre (v design pattern terminologii by to boli pravdepodobne dekoratory nad zoznamom), a/alebo miesto komparatora pouzit key-generator (hmm, asi tiez dekoratory, ale nad prvkami zoznami)
priklady key-generatory:
- pre kazdy sortovatelny prvok
- case sensitivity/insensitivity
- ignorovat/neignorovat non-word character na zaciatku retazca
- file extension
FileList head = FileList->search ('.', '..');
FileList tail = FileList->search (mask)->filter (head);
tail->filter (new OwnerOnlyFilter)->sort (new FileListNameKey);
....
Panel.show (head + tail);
teraz ma tak napadlo, ze vlastne chyba definicia chovania v pripade rovnosti kriteria (typu primarne podla mtime, potom size, potom reverzne name)
17.7.2006 10:27
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
typedef shared_ptr< FileInfo > FileInforPtr;
class RuntimeFileCmp {
public:
enum cmp_mode {default_mode, size_mode, name_mode, ext_mode, attrs_mode, owner_mode, group_mode, date_mode};
private:
cmp_mode mode_; //column
bool ascending_;
int FileInfoList::compare_size(const FileInforPtr &fi1, const FileInforPtr &fi2) const;
int FileInfoList::compare_name( const FileInforPtr &fi1, const FileInforPtr &fi2) const;
int FileInfoList::compare_ext( const FileInforPtr &fi1, const FileInforPtr &fi2) const ;
int FileInfoList::compare_attrs( const FileInforPtr &fi1, const FileInforPtr &fi2) const;
int FileInfoList::compare_owner( const FileInforPtr &fi1, const FileInforPtr &fi2) const;
int FileInfoList::compare_group( const FileInforPtr &fi1, const FileInforPtr &fi2) const;
int FileInfoList::compare_date( const FileInforPtr &fi1, const FileInforPtr &fi2)const;
public:
RuntimeFileCmp( cmp_mode m = default_mode, bool ascending = true ) : mode_( m ), ascending_( a )
{
}
void setComparisonMode( cmp_mode m = default_mode ){
mode_ = m;
}
cmp_mode getComparisonMode() const {
return mode_;
}
void setOrderingMode( bool a = true ){
ascending_ = a;
}
bool getOrderingMode() const {
return ascending_;
}
bool operator()( const FileInforPtr fi1, const FileInforPtr fi2 ) const
{
switch( mode_ )
{
case 0:
compareRes = compare_name( fi1, fi2 );
break;
case 1:
compareRes = compare_ext( fi1, fi2);
break;
case 2:
compareRes = compare_size( fi1, fi2 );
break;
case 3:
compareRes = compare_date( fi1, fi2 );
break;
case 4:
compareRes = compare_attrs( fi1, fi2 );
break;
case 5:
compareRes = compare_owner( fi1, fi2);
break;
default:
compareRes = compare_group( fi1, fi2);
break;
}
return compareRes > 0;
}
};
typedef std::set< FileInforPtr, RuntimeFileCmp > file_set_t; //kontejner XY
/////////////////////////////////////////////////////////////
//v kodu
RuntimeFileCmp<slo by to udelat i obecne> compareDate(RuntimeFileCmp::date_mode, false);
RuntimeFileCmp compareName(RuntimeFileCmp::name_mode, true);
file_set_t fileSetCompName( comapreName );
file_set_t fileSetCompDate( compareDate );
fileSetCompName a fileSetCompDate se sami seradi, kdyz budu chtit jiny zpusob, tak set priradim jinymu;
nebo pouzit komparator RuntimeFileCmp pro funkci std::sort, tj. data budou ve vektoru a ty vzdy seradim podle
toho jak vytvorim objekt k razeni, tj. RuntimeFileCmp.
Vse by se navic dalo parametrizovat. Je tu vyhoda oddelenych dat a algoritmu, navic, kdyz uz jsou napsany...
switch. Spíš bych volil řešení využívající polymorfismu, tj. něco podobného jako jsem navrhoval zde.
17.7.2006 19:36
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
17.7.2006 19:44
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
Tiskni
Sdílej:
