Vývojáři mobilní Datovky prosí o pomoc s testováním beta verze mobilní Datovky s novým grafickým rozhraním, podporou pro tmavý režim a podporou pro VoDZ. Aplikace je zatím dostupná pouze pro zařízení Android a je umístěna v samostatném instalačním kanále Datovka Beta. Tento kanál slouží pro testovaní nové funkcionality a grafického uživatelského rozhraní. Datovka Beta se instaluje jako samostatná aplikace s vlastními daty, která
… více »Harlequin byl vydán ve verzi 1.0.0. Jedná se o TUI (Text User Interface) IDE (Integrated Development Environment) k systému pro správu SQL OLAP databází DuckDB.
Po roce a půl od představení DALL·E 2 představila společnost OpenAI novou verzi DALL·E 3 svého AI systému pro generování "realisticky vypadajících obrázků nebo uměleckých děl" na základě popisu v přirozeném jazyce, viz příklad "kosmonaut na koni fotorealisticky". Jednou z novinek je integrace s ChatGPT.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 133 (pdf) a HackSpace 70 (pdf).
Po půl roce vývoje od vydání verze 44 bylo vydáno GNOME 45 s kódovým názvem Rīga. Přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře. Krátké představení na YouTube. Jednou z nejviditelnějších změn je odstranění tlačítka Činnosti (Activities) v levém horním rohu. Nově je tam indikátor ploch. Výchozím prohlížečem obrázků je nově Loupe, nahradil Eye of GNOME (eog). Novou aplikací pro práci s webovou kamerou je Snapshot, nahradil Cheese. Rozšíření GNOME Shellu fungující v předchozích verzích nejsou s verzí 45 kompatibilní.
Linux Foundation představila a zaštítila svobodný a otevřený fork Terraformu s názvem OpenTofu. Ten vznikl pod původním názvem OpenTF jako reakce na přelicencování Terraformu na BSL (Business Source License) společností HashiCorp.
Google oznámil (en), že konverzační AI Bard (Wikipedie) může nyní komunikovat s aplikacemi a službami Google: "Díky nejnovějšímu rozšíření služby může Bard najít a zobrazit relevantní informace z nástrojů společnosti Google, které používáte každý den, jako je například Gmail, Dokumenty, Disk, Mapy, YouTube a Letenky Google, a to i když jsou potřebné informace v různých aplikacích a službách."
Apache Pinot (GitHub, Wikipedie) dospěl do verze 1.0. Jedná se o realtimeový distribuovaný OLAP datastore navržený tak, aby na OLAP dotazy odpovídal s nízkou latencí.
Byla vydána Java 21 / JDK 21. Nových vlastností (JEP - JDK Enhancement Proposal) je 15. Jedná se o LTS verzi. Nová Java / JDK vychází každých 6 měsíců.
Byla vydána betaverze Fedora Linuxu 39, tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 17. října. Nový Fedora Linux přinese GNOME 45, LibreOffice 7.6, GCC 13.2, …
Dobrý den, v mém projektu mě trápí dost protivný memory leak, při jehož hledání jsem došel zhruba k následující konstrukci, která jej způsobuje:
#include <map>
#include <string>
#include <iostream>
#include <stdio.h>
#include <sstream>
using namespace std;
multimap<int,string> mapa;
int main() {
for(int i=0;i<20000;i++) {
stringstream s;
mapa.insert(make_pair(i%234,string("fdsfdsfdsfdsfdsfds")+s.str()));
};
cout<<"Mapa vytvorena"<<endl;
getc(stdin); //Zde celý program zabírá 2292 KB
cout<<"Jdu mazat"<<endl;
for(int i=0;i<234;++i) {
mapa.erase(i);
};
cout<<"smazano"<<mapa.size()<<endl;
getc(stdin); //Zde program zabírá 2312KB
};
Zajímalo by mě, proč na konci programu je stále naalokováno tolik paměti, i když mapa neobsahuje žádné záznamy. Zabranou pamět zjišťuji příkazem ps s parametrem RSS. Valgrind žádný leak neukazuje.
Stejný problém jsem narazil i u vectoru, a asi bude i u dalších kontejnerů.
Máte pro to nějaké vysvětlení? Lze nějak přikázat kontejneru/překladači, aby paměť skutečně delalokoval?
Tak nevím. ale přijde mi, že alokujete 20000
členů a pak uvolníte jenom 234
, nemůže být problém tam?
std::vector<T>::capacity()
- tam se to asi bude skrývat. Napadá mě leda zkusit clear()
, ale nevím nevím.
Je mozny vyhradit urcitou kapacitu: std::vector(int) vec, vec.reseve(10); aby nedochazelo k realokaci behem plneni. Pokud uz mame plnej vektor a chceme jej zmensit na pocet (size()), pak zavolame std::vector<int>(vec).swap(vec);
To není memory leak, STL je prostě žrout paměti. Co kontejner schvátí, jen tak nevrátí
Děkuji všem za odpověďi To %234, tam je pouze, abych měl v kontejneru různé prvky, z nichž některé se budou opakovat. Nechtěl jsem tím mást:) Opravdu je to tak, že STL si naalokuje paměť a tu potom používá, takže v pokud pole znovu naplním, nová paměť už se nebere...ale pouze na tomhle testovacím prográmku, v mém projektu ne :'(. Zajímalo by mě, zda existuje možnost, jak přinutit SDL aby tu paměť dealokoval (clear() nepomáhá). Zkoušel jsem to exportnutí GLIBCXX_FORCE_NEW, ale nepomáhá to. Nějaká cesta, jak přinutit SDL dealokovat paměť přece musí existovat, protože jinak by jakýkoli program - deamon, co třeba při spuštění potřebuje 100MB RAM a pak už jen 2MB žral celou dobu 100 paměti...to by přece nikdo nemohl přehlédnout:)
GLIBCXX_FORCE_NEW je určitě těžce nepřenositelné. Řešení ti popsal "puk" o pár příspěvků výše (aneb např. string(s).swap(s), obdobně pro vector apod.)
vim ~/.emacs
Tiskni
Sdílej: