Google Blog ČR informuje, že mobilní aplikaci Gemini a NotebookLM lze používat už také v Česku.
Byla vydána nová major verze 8 duálně licencovaného open source frameworku JUCE (Wikipedie, GitHub) pro vývoj multiplatformních audio aplikací.
Od 18. června bude možné předobjednat notebook DC-ROMA RISC-V LAPTOP II od společnosti DeepComputing s osmijádrovým 64-bit RISC-V AI CPU a s předinstalovaným Ubuntu.
Byla vydána verze 1.79.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Byly zveřejněny výsledky průzkumu (infografika) mezi uživateli FreeBSD.
Na konferenci DevConf.CZ 2024 je na stánku Furi Labs prezentován linuxový telefon FuriPhone FLX1. Jeho cena 499 dolarů.
Bylo vydáno Eclipse IDE 2024-06 aneb Eclipse 4.32. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-2 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Po roce od vydání verze 15.5 bylo vydáno openSUSE Leap 15.6. Přehled novinek v nejnovější verzi této linuxové distribuce v oznámení o vydání a v poznámkách k vydání.
Byla vydána nová verze 256 správce systému a služeb systemd (GitHub). Nově mimo jiné s run0 jako alternativou k sudo.
Vyšla nová verze debuggeru GDB, 6.8. Lze jej zkompilovat (do jedné binárky) tak, aby podporoval několik architektur (vzdálené cíle). Přidává podporu pro NetBSD/hppa a Xtensa GNU/Linux. Byla vylepšena podpora programovacího jazyka Ada a debugování optimalizovaného kódu. Připojování k programu pomocí přepínače '-c' již není podporováno, používá se '-p' (--pid).
Tiskni
Sdílej:
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
void* print_pokus(void *unused)
{
while(1)
{
printf(" %s\n", (char *)unused);
}
return(NULL);
}
int main()
{
pthread_t thread_id1;
pthread_t thread_id2;
pthread_t thread_id3;
pthread_create(&thread_id1, NULL, &print_pokus, "1");
pthread_create(&thread_id2, NULL, &print_pokus, "2");
pthread_create(&thread_id3, NULL, &print_pokus, "3");
while(1)
{
sleep(1);
}
return(0);
}
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
static pthread_mutex_t mutex;
void* print_pokus(void *unused)
{
while(1)
{
pthread_mutex_lock(&mutex);
printf(" %s\n", (char *)unused);
pthread_mutex_unlock(&mutex);
}
return(NULL);
}
int main()
{
pthread_t thread_id1;
pthread_t thread_id2;
pthread_t thread_id3;
pthread_mutex_init(&mutex, NULL);
pthread_create(&thread_id1, NULL, print_pokus, "1");
pthread_create(&thread_id2, NULL, print_pokus, "2");
pthread_create(&thread_id3, NULL, print_pokus, "3");
while(1)
{
sleep(1);
}
return(0);
}
char* string; ziskej_mutex() string = malloc(100); if (string != NULL) memcpy(string,zdroj,100); vrat_mutex(); ... ziskej_mutex(); free(string); vrat_mutex();Céčko by bylo zhola nepoužitelné, pokud by C knihovna nebyla vnitřně multithreadová.
pokud se zhroutí debugger u _jakéhokoli_ zdrojáku, pak je to špatný debuggerNebo je v něm prostě chyba, že?
A zde se rozmáhá nešvar na abclinuxu jásat nedávno nad linkerem, který linkuje několikrát rychleji - co na tom, že neumí spolehlivě linkovat - kdo by se zdržoval takovou maličkostí, že?Jásalo se nad tím, že se novej a rychlej linker vyvíjí, nevím co je na tom za nešvar. Třeba já z něj mám radost, ale nepoběžím si ho hned nainstalovat.
Přemýšlím, jestli lze udělat debugger pro nativní kód, který přežije libovolně ošklivé chování laděného programu...pokud se zhroutí debugger u _jakéhokoli_ zdrojáku, pak je to špatný debuggerNebo je v něm prostě chyba, že?
0x080484f4 <print_pokus+0>: push %ebp
0x080484f5 <print_pokus+1>: mov %esp,%ebp
0x080484f7 <print_pokus+3>: sub $0x8,%esp
0x080484fa <print_pokus+6>: int3
0x080484fb <print_pokus+7>: add $0x24,%al
0x080484fd <print_pokus+9>: int3
0x080484fe <print_pokus+10>: xchg %eax,%edi
0x080484ff <print_pokus+11>: add $0x8,%al
0x08048501 <print_pokus+13>: call 0x8048440 <pthread_mutex_lock@plt>
0x08048506 <print_pokus+18>: int3
0x08048507 <print_pokus+19>: inc %ebp
0x08048508 <print_pokus+20>: or %cl,0xc7042444(%ecx)
0x0804850e <print_pokus+26>: add $0x24,%al
0x08048510 <print_pokus+28>: cwtl
0x08048511 <print_pokus+29>: xchg %al,(%eax,%ecx,1)
0x08048514 <print_pokus+32>: call 0x8048420 <printf@plt>
0x08048519 <print_pokus+37>: movl $0x80497cc,(%esp)
Pri debugovani debuger dava do strojoveho kodu int3, ked vsak prepne na nejake ine vlakno, zabude tuto intrukciu inemu vlaknu zobrat, cim sa poskodi kod. Ked kazde vlakno poziva svoju vlastnu funkciu, nie su v tej funkcii int3 z debugovani inych vlakien. Samozrejme debuger by mal podporovat debugovat funkcie, ktore su pozivane sucastne viac vlaknami
gdb --help|grep bugs Report bugs to "bug-gdb@gnu.org".