Nedávno se povedlo do pdf souborů vložit Tetris a DOOM a po otevření příslušného pdf souboru v na Chromiu založeném webovém prohlížeči vybranou hru přímo v pdf spustit. LinuxPDF ukazuje, že do pdf lze vložit také RISC-V emulátor a rozběhnout Linux.
Kancelářský balík LibreOffice byl vydán ve verzi 25.2. Podrobnosti v poznámkách k vydání.
Byla vydána nová stabilní major verze 24.10 linuxové distribuce primárně určené pro routery a vestavěné systémy OpenWrt (Wikipedie). Jedná se o nástupce předchozí major verze 23.05. Přehled novinek v poznámkách k vydání. Podporováno je více než 1970 zařízení. Samozřejmě včetně OpenWrt One. Linux byl povýšen z verze 5.15 na verzi 6.6.
Byla vydána nová verze 6.12 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přináší důležité bezpečnostní opravy díky bezpečnostnímu auditu od společností Radically Open Security. Tor Browser byl povýšen na verzi 14.0.5. Thunderbird na verzi 128.6.0. Další změny v příslušném seznamu.
Databáze DuckDB (Wikipedie) byla vydána ve verzi 1.2.0. S kódovým názvem Histrionicus (kačka strakatá). Z novinek lze vypíchnout, že například 🦆 může být nově použita jako vícebajtový oddělovač sloupců. 😂
Google Chrome 133 byl prohlášen za stabilní. Nejnovější stabilní verze 133.0.6943.53 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 12 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Novinky v Knot Resolver 6: ochrana před DoS útoky – technické řešení, aktuální příspěvek na blogu zaměstnanců CZ.NIC.
Smb4K, tj. pokročilý prohlížeč síťového okolí a nástroj na připojování úložišť Samba, byl vydán v nové major verzi 4.0.0. Proběhla portace na Qt 6 a KF 6.
Tiskni
Sdílej:
Ale po pravde, jelikoz tu je uz asi deset blogu ale ani radka kodu, tak vam teda moc neverim :-/.
Huh...? Já se na začátku bál spíš opačného přístupu. Šílené kódování od začátku a bez rozmyslu. Pokud se těm 10 blogům dá říkat analýza, tak je to jedině dobře.
konstruktér/návrhářJa si myslim, ze ten SpaceClaim je tak vhodny pro toho navrhare. Pro to, aby konstrukter protahl nejakou soucastku musi byt nejaky duvod. Ten duvod se musi prozkoumat, zvazit, to jsou mnohdy hodiny a dny. Uspora v celkovem procesu zanedbatelna. Ale vypada to hezky a moderne.
je vidět, že významu slova CAD vůbec nerozumíteArgumentujeme ad rem, nikoliv ad personam, je to základ slušné a konstruktivní diskuse už dob starořeckých polis.
Sám bych i přispěl troškou do mlýna, ale jsem teď dost vytíženej. Až to bude už v nějaké fázi zkompilovatelnej základ + zdrojáky přístupný např. přes Git, tak pokud budu mít čas a bude zájem, rád pomůžu.
Argumentujeme ad rem, nikoliv ad personam, je to základ slušné a konstruktivní diskuse už dob starořeckých polis.To byla argumentace k věci Vás (Vašeho přehledu) v souvislosti s tvorbou ideového modelu. Vypadá to, že si s aktuálními problémy poradíte, tudiž Vám velmi rád pomohu s doplněním požadavků z komerčních CADů, popř. s testováním. Ještě mě napadá, jaké důvody Vás vedou k použití QtScript pro objekty (Zde chybí přehled mě). Osobně se mi líbí vestavěný interpret pythonu tak, jak ho používá ABAQUS. Modelování je pohodlné jak pomocí GUI, tak skriptu.
Ještě uvažuju o zavedení nějaké centrální message bus, ale nejsem si jist, jak moc veliký přínos oproti samotným signálům a slotům by to znamenalo.Urcite by to prinos melo. Zalezi ovsem ciste na jednoduchosti navrhu a kvalite implementace. Bavime se nyni prilis nekonkretne, abychom mohli napevno prohlasit "nyni muzeme zahodit velkou cast Qt signalu-slotu a pouzit nase reseni". Nemohu vsak neupozornit prave na reseni vyuzivajici CSP. Myslim vsak, ze pokud se v samotnem CSG stromu signalum-slotum uplne vyhnete, tak jednoduse hierarchicky implementovane gui si s Qt signaly-sloty vystaci (videl jsem totiz odstrasujici priklad pouziti signalu-slotu v Qt, kdy se za jejich pomoci kreslilo jenom 40 polopruhlednych trojuhelniku ve 2D, ktere si mezi sebou takto vymenovali informaci o poloze a podle ni menili vlastni souradnice, velikost a natoceni; v tomto pripade clovek pohnul mysi jednim trojuhelnikem a pul vteriny cekal, nez se pohnuly i ostatni
mged> in kvadr.s rpp 0 30 0 10 0 10
Zjistíme o něm, co se dá:
mged> l kvadr.s
kvadr.s: ARB8
1 (30, 0, 0)
2 (30, 10, 0)
3 (30, 10, 10)
4 (30, 0, 10)
5 (0, 0, 0)
6 (0, 10, 0)
7 (0, 10, 10)
8 (0, 0, 10)
Všimněte si, že rpp je vlastně arb8, rpp je (nenapadá mě lepší termín) metatyp, který jen usnadňuje zadání.
U válce postupujeme podobně:
Výroba:
mged> in valec.s rcc 5 0 5
Enter X, Y, Z of height (H) vector: 0 10 0
Enter radius: 3
Info:
mged> l valec.s
valec.s: truncated general cone (TGC)
V (5, 0, 5)
Top (5, 10, 5)
H (0, 10, 0) mag=10
H direction cosines=(90, 0, 90)
H rotation angle=90, fallback angle=0
A (0, 0, 3) mag=3
B (3, 0, 0) mag=3
C (0, 0, 3) mag=3
D (3, 0, 0) mag=3
AxB direction cosines=(90, 0, 90)
AxB rotation angle=90, fallback angle=0
Všimněte si, že pravoúhlý kruhový válec je datově vzato zvláštní případ komolého kužele.
Teď je zkombinujeme:
mged> c -r kvadr_s_dirou kvadr.s - valec.s
Creating region id=1000, air=0, los=100, GIFTmaterial=1
Info o jejich kombinaci vypíšeme stejně, ale už dostaneme jen info, o tělesech a vztazích mezi nimi:
mged> l kvadr_s_dirou
kvadr_s_dirou: REGION id=1000 (air=0, los=100, GIFTmater=1) --
u kvadr.s
- valec.s
Více zjistíme pomocí nástroje gqa
, nebudu sem už dávat výpisy, ale jen povím, co je nač:
gqa -Ao kvadr_s_dirou - zjistíme překryv kombinace s jiným tělesem
gqa -Av kvadr_s_dirou - vypočte objem kombinace
gqa -Ag kvadr_s_dirou - zjistí díry v kombinaci
gqa -Ab kvadr_s_dirou - vypíše bounding box
Bylo by fajn mít ten výpis proklikávací na úroveň těles a pokud změním hodnotu ve výpisu tělesa (třeba souřadnici jednoho rohu kvádru), tak aby se to promítlo do tělesa.
Otázky stran kódu, resp. začlenění do architektury programu bohužel nedovedu zodpovědět.
in jméno_tělesa typ_tělesa
a pak už se bude MGED vyptávat dokaď nebude vědět, co potřebuje.
Ještě pro doplnění a upřesnění předchozího:
gqa -Aop kombinace1.r kombinace2.r
vypíše a v grafickém okně vyznačí překryv dvou kombinací. Textově můžeme překryv zjistit ještě pomocí rtcheck
.
S překladem na Windows držím palce.
#vložíme válec, již má definované rozměry 10,2
>>> App.ActiveDocument.addObject("Part::Cylinder","Cylinder")
>>> App.ActiveDocument.recompute()
>>> Gui.SendMsgToActiveView("ViewFit")
>>> App.ActiveDocument.ActiveObject.Height
10.0
>>> App.ActiveDocument.ActiveObject.Radius
2.0
>>> App.ActiveDocument.ActiveObject.Radius = 5
>>> App.ActiveDocument.ActiveObject.Radius
5.0
#přidáme na hrany zaoblení 3
>>> App.activeDocument().addObject("PartDesign::Fillet","Fillet")
>>> App.activeDocument().Fillet.Base =(App.ActiveDocument.Cylinder,["Edge1","Edge3"])
>>> Gui.activeDocument().setEdit('Fillet')
>>> App.ActiveDocument.Fillet.Radius = 3.000000
>>> App.ActiveDocument.recompute()
>>> Gui.activeDocument().resetEdit()
Jak to tady všechny ty diskuse kolem CADu a cadusu čtu, měl bych jedno doporučení:
Sjednejte si co nejvíc exkurzí do konstrukčních, vývojových a projekčních kanceláří od modelářů a malých živnostníků až po nadnárodní firmy, třeba na jeden den, a pozorujte konstruktéry při jejich skutečné práci a vyptávejte se. Zjistěte, jak postupují. jak tvoří díly (obráběné, odlévané, lisované, plechové, potrubí atd.) a sestavy, jak celou konstrukci ladí a upravují, jaké používají externí knihovny a moduly a proč, co potřebují, co se jim na jejich softwaru líbí a nelíbí, co by chtěli. Vyptejte se správců CAD systému na propojení CADu se zbytkem firmy a s okolím - s nákupem, skladem, se subdodavateli. Vyptejte se manažerů na spolupráci s konstrukcí - na rychlost práce, na prezentační výstupy, na výstupy pro NC stroje. Výstupem z těchto exkurzí by měl být podrobná analýza a seznam toho, co CAD umět musí a jak, co umět může a nemusí, a co konstruktéra nezajímá, i když programátorovi se to strašně líbí.
Vaše cílová skupina by měla být konstruktéři, projektanti, návrháři. Zatím to vypadá, že to jsou programátoři; řeší se jejich představy o knihovnách, komunikaci, modulech, o jazycích; ale to by mělo vyplynout až z analýzy potřeb cílové skupiny. Jinak se může stát, že cadus bude z programátorského hlediska skvělá věc, ale skutečný konstruktér s tím nebude chtít dělat (a to je podle mě důvod, proč tolik CAD programů vyhořelo - pro jejich totální nepoužitelnost. Docela by mě mrzelo, kdyby Cadus dopadl stejně).
Těch exkurzí by mělo být co nejvíc a měly by rovnoměrně pokrýt všechny dnes používané CAD programy; ve strojírenství ProE, Catia, SolidEdge, Autodesk Inventor, I-Deas a další. pro stavebnictví a elektro to samé (ale tam to neznám). Mám pocit, že jediný z komunity abclinuxu, který CAD reálně používá, je pan Zima (a myslím ještě někdo s Autocadem), který ProE používá v rozsahu, který potřebuje, ale zase omezeném; protože nikdo na světě žádný CAD nevyužívá naplno se vším všudy.
V podstatě CLI modelováním nepočítáme. To prostě necháme na BRL-CADuTo by byla dost velká chyba. CLI modelování pomocí vysokoúrovňového skriptovacího jazyka je dnes běžné a v některých případech je to nutnost. Představte si, že např. kreslíte listy vrtule větrné elektrárny. Máte na listu 40 řezů, ve kterých musíte dodržet daný profil listu, který je pokaždé jiný, dále jeho natočení vůči prvnímu profilu atd. Kreslit toto ručně je práce na dva dny. Až to nakreslíte, předáte model dále, aby jste se další den dozvěděli, že je potřeba změnit profily ve všech řezech. Tohle je běžná vývojová iterační smyčka. Pokud mám dobrý CAD, napíšu si za dvě hodiny jednoduchý skript, který modeluje za mě a bez chyb. Viz jednoduchá ukázka v přiloze.
výsledek = Továrna.metoda(vstup)
NaroCAD (Novinka, nechme stranou výběr jazyka a GUI. Zatím nefunguje na Linuxu, mluví se o portu do Mona)
Zaměřit se funkce, které jsou slabá místa komerčních 3D CADů (obvykle z marketingových důvodů) - zpětná kompatibilita, výměna dat, napojení na externí databáze a jazyky, vysokoúrovňový jazyk popisu modelu s případnou možností jeho implementace do komerčních CADů.Tohel co pisete je jiz samostatny projekt. Ja delal 1986-1991 ve firme, ktera pomahala zavadet tenkrat ve strednich a vetsich firmach CAD. Uz jenom ten vyber, vyhodnocovani pozadavku, srovnavani tech systemu, analyza konstrukcnich zvyklosti konkretni firmy a rada dalsich aktivit byly projekty v hodnote tenkrat tak 200 tisic DM. Ja si myslim, ze tohle je nerealizovatelne.
Podpora vyššího skriptovacího a "add-on" jazyka s plným přístupem ke GUI. Ideální se jeví PythonTo s tim Pythonem se tu jiz objevilo nekolikrat. Rad bych skutecne vedel, proc je to idealni. Je to ted nejake moda? Uci se to na skolach jako kdysi Pascal? Se scriptovacim jazykem souhlasim, ale proc se omezovat na jeden jediny?
OpenCascade většinu z tohoto nějakým způsobem umí.problematiku vidim v tom nějakým způsobem
Jak se dělá průmět modelu pro výkres,Tohle bych rekl ze je zasadni problem a je to jako prvni treba objasnit. Ale to se nepodari v diskuzi, to se proste musi zkusit. Idealni by bylo, kdyby nekdo analyzoval jak to vypada u toho OpenCascade a jak to je s tim BRL-CAD. Ja za sebe se snazim proniknout do toho BRL-CADu a jeste soucasne kontroluju, jak by to bylo v gcad3d. I kdyz to ted v projektu rozhodli, ze to bude BRL-CAD, tak ja to tak lozene nevidim.
To s tim Pythonem se tu jiz objevilo nekolikrat. Rad bych skutecne vedel, proc je to idealni. Je to ted nejake moda? Uci se to na skolach jako kdysi Pascal? Se scriptovacim jazykem souhlasim, ale proc se omezovat na jeden jediny?Viz vys. To s temi vicero jazyky je takova teoreticka moznost, ale prijde mi, ze v praxi stejne vyhraje to, co budou pouzivat puvodni autori. Aspon tak bych to odhadoval na zaklade toho, co se deje v OSS projektech. Vetsina lidi, co k tomu prijde pozdeji, proste skriptuje v tom co je, a na vytvareni API pro vlastni jazyk vetsinou neni moc sila.
To s temi vicero jazyky je takova teoreticka moznost,my u nas ve firme pouzivame uz 15 let swig a kdyz uz chceme zcela specialni predavani parametru, tak se musi napsat zvlastni typemap, jinak bezne se da pouzit to, co ma swig uz v sobe. Takze pro kazdy scriptovaci jazyk je potreba jen: - makefile - typemap-file (kdyz uz) - remaping file To se udela jednou a je to. Samozrejme, ze je 'vhodne', aby zaklad byla C, pak je to easy, s C++ je to bohuzel i se swigem opruz. A pak taky chapu, ze se autori rozhodnou pro jeden skriptovaci jazyk. Problem je v tom, ze moznost pouzit jen jeden scriptovaci jazyk predstavuje znacne omezeni. U kazdeho uzivatele je uz nejake infrastruktura, u nas treba perl. V tom se vyzname, vime jake knihovny, spousta hotoveho kodu. A pak prijde nekdo s CAD s pythonen. To vede automaticky k odmitave reakci. Jako uzivatel byvh mel mit moznost se rozhodnoutz pro ten scriptovaci jazyk, pro ktery jsme vytvoril vlastni infrastrukturu. Jako vyrobce nejakeho toolu bych se mel snazit toto uzivateli umoznit. Jestlize je to alespon nejak rozumne realizovatelne.
Tohel co pisete je jiz samostatny projekt. Ja delal 1986-1991 ve firme, ktera pomahala zavadet tenkrat ve strednich a vetsich firmach CAD. Uz jenom ten vyber, vyhodnocovani pozadavku, srovnavani tech systemu, analyza konstrukcnich zvyklosti konkretni firmy a rada dalsich aktivit byly projekty v hodnote tenkrat tak 200 tisic DM. Ja si myslim, ze tohle je nerealizovatelne.Když se vezmete skupinu současně používaných parametrických CADů se stromově uspořádanými prvky, tak úplně základní funkce modelování jsou téměř stejné - roviny, souřadné systémy, skicy (základní entity), základní vazby, prvky vysunutí, rotace profilu, zaoblení a sražení. Když se definuje jazyk, který model popíše na této úrovni (v podstatě postup operací uživatele), tak jde ve většině CADů tohle interpretovat pomocí API daného CADu. Komplexní modely vzhledem k rozdílnosti CADů by byly problém, ale pro často používané malé jednoduché součásti (např. normalizované) to je dostatečné. Implementace do jiných CADů by nemuselo být v rámci vývoje OSS CADu, ale kdyby se podařilo vytvořit dobrý standard, třeba by se začal používat, a OSS CAD by měl výhodu v integraci.
To s tim Pythonem se tu jiz objevilo nekolikrat. Rad bych skutecne vedel, proc je to idealni. Je to ted nejake moda? Uci se to na skolach jako kdysi Pascal? Se scriptovacim jazykem souhlasim, ale proc se omezovat na jeden jediny?Netvrdil jsem, že by musel být podporován pouze Python. Ale myslím, že je lepší vytvořit dobrou podporu pro jeden jazyk s jeho datovými typy, než univerzální API. A jak jsem už psal, Python je přehledný, má dobré knihovny jak v základu, tak velké množství externích pro numerické a technické výpočty, grafy, simulace, symbolickou matematiku, zpracování dat, apod. Dále má dobré vlastnosti pro integraci konzole do aplikace, dobré OOP, které ale není nuceno, a jako integrovaný skriptovací jazyk je ověřený. Doporučuji se podívat na integraci Pythonu v Blenderu (mimochodem API je generované z datových struktur) a jeho interaktivní konzoli.
problematiku vidim v tom nějakým způsobemAno, ale pokud vím, nic lepšího k dispozici není, a na základ to snad stačí. Jádro se také stále vyvíjí.
Idealni by bylo, kdyby nekdo analyzoval jak to vypada u toho OpenCascadeTak vzhledem k tomu, že většina aplikací využívající OpenCascade zobrazuje hranice tělesa a hrany jako křivky v 3d náhledu, tak snad nebude problém s průmětem. Základ tvorby pohledu a export do svg tam už také je.
Pokud bude OSS CAD použitelný pro konvertování modelů, přiláká spoustu uživatelů, i když bude mít slabší funkce.Tohle me zaujalo z jednoho prosteho duvodu - prevody mezi formaty jsou temer vyhradne one-man show, coz mnohym vyvojarum vyhovuje a je to docela challenge (tipovani co v danem binarnim formatu bez dokumentace asi je