Americký výrobce čipů Nvidia získal od vlády prezidenta Donalda Trumpa souhlas s prodejem svých pokročilých počítačových čipů používaných k vývoji umělé inteligence (AI) H20 do Číny. Prodej těchto čipů speciálně upravených pro čínský trh by tak mohl být brzy obnoven, uvedla firma na svém blogu. Americká vláda zakázala prodej v dubnu, v době eskalace obchodního sporu mezi oběma zeměmi. Tehdy to zdůvodnila obavami, že by čipy mohla využívat čínská armáda.
3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.
Open source webový aplikační framework Django slaví 20. narozeniny.
V Brestu dnes začala konference vývojářů a uživatelů linuxové distribuce Debian DebConf25. Na programu je řada zajímavých přednášek. Sledovat je lze online.
Před 30 lety, tj. 14. července 1995, se začala používat přípona .mp3 pro soubory s hudbou komprimovanou pomocí MPEG-2 Audio Layer 3.
Výroba 8bitových domácích počítačů Commodore 64 byla ukončena v dubnu 1994. Po více než 30 letech byl představen nový oficiální Commodore 64 Ultimate (YouTube). S deskou postavenou na FPGA. Ve 3 edicích v ceně od 299 dolarů a plánovaným dodáním v říjnu a listopadu letošního roku.
Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila open source robota Reachy Mini (YouTube). Předobjednat lze lite verzi za 299 dolarů a wireless verzi s Raspberry Pi 5 za 449 dolarů.
Dnes v 17:30 bude oficiálně vydána open source počítačová hra DOGWALK vytvořena v 3D softwaru Blender a herním enginu Godot. Release party proběhne na YouTube od 17:00.
McDonald's se spojil se společností Paradox a pracovníky nabírá také pomocí AI řešení s virtuální asistentkou Olivii běžící na webu McHire. Ian Carroll a Sam Curry se na toto AI řešení blíže podívali a opravdu je překvapilo, že se mohli přihlásit pomocí jména 123456 a hesla 123456 a získat přístup k údajům o 64 milionech uchazečů o práci.
Byla vydána (𝕏) červnová aktualizace aneb nová verze 1.102 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.102 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Nechtěl jsem to navrhnout jako zprávičku, jelikož se to podle mě nedotkne Linuxu až tak brzy (2011 / 2012).
Jenže má tohle vůbec v dnešní době smysl? V Delphi jsem kdysi pár věcí dělal a byl jsem nadšený. Borland / Inprise ale zaspal dobu, dost opožděná verze pro Linux byla nejen komerční, ale i dost okousaná a mezitím se objevil a vypracoval relativně dobrý projekt Lazarus, který je navíc celý open source (jeho aktuální stav ale neznám, v Pascalu už jsem delší dobu nic nedělal, přešel jsem na Python, což mi na to moje občasné skriptování vyhovuje daleko víc).
Originální zpráva tady.
Tiskni
Sdílej:
Myslím, že existuje i JVM napsaná v Javě (každopádně je to proveditelné).No to nejde. Leda by se to z Javy přeložilo přímo do strojáku, což je samozřejmě možné, ale už je to jiná situace, než běžné psaní programů v Javě, ačkoli jazyk je stejný...
1. Load joeq into a 'host' Java virtual machine. joeq is completely written in Java, which means a Java virtual machine can load and execute the code.
No veď tie staticky typované jazyky sú naozaj plnohodnotné jazyky lebo v nich môžeš naprogramovať akýkoľvek druh aplikácieA v těch ostatních nemůžu naprogramovat jakýkoli druh aplikace?
Python sa prekladá do bytecode a ten sa priamo interpretujeEhm…
nie.Například? Jinak s tím Pythonem - kdo říká, že se ten bytecode musí hned vykonávat a nemůže se uložit napotom jako u Javy?
no skús v pythone naprogramovať napr. rýchly 3D grafický engine, bez použitia knižníc napísaných v iných programovacích jazykoch. ... v jave áno v pythone v žiadnom prípade.
Teda ja uz jsem z toho jelen. Prece je nesmysl, ze by se v Jave dal napsat 3D engine (slovo "rychly" vynechejme, ted nejde o rychlost), aniz by byl pouzit jiny nez Java kod. Ty Java knihovny, ktere se tam pouziji, jsou treba napsane samy o sobe v Jave, ale samy pouzivaji opet dalsi knihovny, ktere uz v Jave nejsou, az se postupne takto dostaneme treba az k Assembleru. Vidim tam dost podobnosti s Pythonem.
(Jinak pojem skript vs. program je vec pohledu, ja to tak dramaticky nerozlisuju. Skript muzu taky zkompilovat a mam z toho program. Je to jen slovni hricka.)
programovať graficvký engine v pythone je odtrhnuté od reality, nikto to nerobí prečo asi?To už jsem říkal. Je to nepraktické.
Java nemusí být vždycky kompilovaná do bytecode, jsou i projekty pro překlad javy do nativního kódu, jaký je to pak jazyk podle tvoji definice?Navíc u mnoha mobilů nebo smart karet by se podle mě klidně dalo říct, že Java (ME) je jejich nativní kód. Protože J2ME JRE je tam v podstatě natvrdo vysmažené v hardware.
x = 'y = 1 + 1' exec(x) print yvidno že si nikdy nevytvoril vlastný interpreter programovacieho jazyka :D
ako chceš skompilovať napr. totoKompilátor může být součástí zkompilovaného programu.
plus: mov ry,1 add ry,1 ret main: mov rx,&plus call rx mov rp,ry call print_val ;number in rp call exitJo to kdybys chtěl print x, tak by to bylo horší
a = raw_input("zadaj hocijaký python kód na vykonanie") exec(a)
python sa ale používa len ako doplnkový jazyk na tvorbu pluginov a rozširovanie aplikácie alebo ako prostriedok na tvorbu menších web aplikácií.Před pár hodinama to byl skriptovací jazyk na pár řádků
žiadna, veď práve preto nemá používanie dynamických jazykov žiadny podstatný prínos.Tak co ti brání, abys Python používal jako statický?
žiadna, veď práve preto nemá používanie dynamických jazykov žiadny podstatný prínos.LOL. Osobně mám taky radši staticky typované jazyky, ale tato hláška je perla! Kdo nikdy nevytvořil kód v dynamicky typovaném jazyce, asi nikdy nepřijde na to, že ta dynamická povaha jazyka je strašně flexibilní, a někdy může práci naopak ušetřit. Dynamické typování se často pomocí pomocných tříd používá i ve staticky typovaných jazycích, je to všude - Qt, Glib, .NET, atd... A naopak někdy se zase zavádí statická kontrola do dynamicky typovaných jazyků. Meze se posunujou. Před 10 lety by mi nikdo nevěřil, že v tom pomalém javascriptu někdo napíše použitelný emulátor 8bitu nebo klon boulder dash. Nebo že někteří blázni začnou v tekovém jazyce psát UI pro mobilní zařízení.
Meze se posunujou. Před 10 lety by mi nikdo nevěřil, že v tom pomalém javascriptu někdo napíše použitelný emulátor 8bitu nebo klon boulder dash. Nebo že někteří blázni začnou v tekovém jazyce psát UI pro mobilní zařízení.Jj nebo třeba tuhle google a pacman
jedine tak a niektoré časti sa budú kompilovať počas behu programu, čo samozrejme bude bude mať nemalú réžiu a spomalovať vykonávanie programu a vpodstate sa tým stratí výhoda kompilovaného jazyka.Kompilaci až za běhu používají třeba některé multimediální přehrávače – ne kvůli tomu, aby byly pomalejší, ale právě naopak. vaše úvahy o tom, co je rychlé a co pomalé svědčí akorát o tom, že toho o tom, jak fungují programy a procesory mnoho nevíte.
a okrem toho toto všetko sú len nezmyselné teoretické úvahy python je interpretovaný jazykTo nevadí, že vám to tady několik lidí vyvrátilo, stejně budete trvat na svém.
keby sa python dal skompilovaťOn se dá zkompilovat. Víte třeba o existenci Jythonu?
pravdepodobne by sa používal aj tam kde sa dnes používajú plnohodnotné jazyky, python sa ale používa len ako doplnkový jazyk na tvorbu pluginov a rozširovanie aplikácie alebo ako prostriedok na tvorbu menších web aplikácií.To, že vy nevíte o existenci velkých aplikací napsaných v Pythonu, ještě neznamená, že neexistují.
gcc
nebo ld
jsou napsané v C? Oba pracují tak, že načtou nějaký soubor na vstupu, zpracují jej a zapíší něco na výstup. Nebyl by problém z nich udělat knihovní funkce, které předáte pole bajtů a na výstupu dostanete jiné pole bajtů – dost možná, že takové knihovní funkce už někde existují – já si je pojmenuju gcc()
a ld()
.
#include <stdio.h> int main(void) { char x[] = "int y = 1 + 1"; void *o = gcc(x); void *out = ld(o); (*out)(); return 0; }V čem se liší tenhle program v C od toho vašeho v Pythonu (až na ty memoryleaky)?
ktorý sa kompiloval do strojového kódu procesora.Podporuje i LISPový stroj? Klidně snížím požadavky na ARM, ale i na ten by bylo potřeba něco jako QEMU, což je "interpreter".
Python je len primitívny skriptovací jazyk na pár riadkové skripty.Tohle nestačí? P.S. Heh asi bych neměl zmiňovat, že bych rád dodělal emulátor 486 procesoru v perlu a nabootoval na něm
#include <stdio.h> int main() { printf ("%s \n", "A string"); return 0; }Je v tom nějaký principiální rozdíl oproti vašemu kódu?
A co takhle zkusit Phyton v Delphi http://www.atug.com/andypatterns/pythonDelphiTalk.htm
Existuje i komponenta interpretru (Object)Pascalu a možná i nějakých dalších jazyků.
Python je len primitívny skriptovací jazyk na pár riadkové skripty.Slunce se toci taky kolem Zeme, ze jo. Vyznas se v Delphi, tak pis komentare o Delphi a ne o necem, s cim jsi se delsi dobu nezabyval.
a různými Pascaly určenými pro normální programování, je dost velký rozdíl.jo, to vetsina lidi nechape. navic si neuvedomuji, ze v pascalech ala delphi se programuje uuuuuuplne, ale uplne jinak. typicky se pascalu vycita priserna prace s ukazately... v delphi jsou takove veci spis pro zpetnou kompatibilitu a diky pouzitemu objektovemu modelu nejsou potreba (stejne jako v jave). proti moznostem toho jazyka bych mel vyhrady... neni tak expresivni jako ostatni. ale u javy se to povazuje za killer feature. co se mi na delphi libilo, kdyz jsem v nem nekdy na prelomu tisicileti delal, byla standardni knihovna. bylo u ni videt, ze se nad ni premyslelo a ktera mela koncepci. a nebyl to zmet napadu slepena dohromady.
co se mi na delphi libilo, kdyz jsem v nem nekdy na prelomu tisicileti delal, byla standardni knihovna. bylo u ni videt, ze se nad ni premyslelo a ktera mela koncepci. a nebyl to zmet napadu slepena dohromady.K tomu dávám +1, to je pravda.
K tomu dávám +1, to je pravda. Na druhou stranu, ona ta standardní knihovna byla dost pověšená na win32 API. Vím, byly tam cross-platform-ready části, nicméně zdaleka ne všechno.Těžko zrovna toto vyčítat. Kód mezi Delphi a C++Builderem byl sdílený, a když jsem opravdu hodně dávno nainstaloval C++Builder 1.0 na Win95 desktop, byl jsem z toho nadšený. Form designer byl na tu dobu vymakaný, velice jednoduché bylo vytvořit si DIBSection a renderovat si vlastní widgety, prostě paráda;) Hodně aplikací, co vzniklo v té době používalo právě C++Builder.
co se mi na delphi libilo, kdyz jsem v nem nekdy na prelomu tisicileti delal, byla standardni knihovna. bylo u ni videt, ze se nad ni premyslelo a ktera mela koncepci. a nebyl to zmet napadu slepena dohromady.No, ona slavná knihovna byla možná dobrá, ale v rámci Delphi. Jakmile člověk chtěl trošku hlouběj (použít něco z Win32 API - psali jsme kdysi aplikaci, která používala sériové porty) tak to zase taková výhra nebyla. V principu to byla zplácanina mezi borlandím runtimem <-> MFC <-> Win32 API. A tuto zplácaninu rovněž používal Borland C++ Builder 5 a vyšší. Ale jinak v celku proti Delphi nic nemám, bylo v tom napsáno mnoho všelijakých aplikací a svého času bylo na výsluní a používalo se hodně.
Moderní Pascal je naprosto celý Wirthův Pascal (snad až na pár detailů) + něco navíc.
Jde o to, jestli se bavime o teorii Wirthova Pascalu nebo o hotovem kompilatoru.
Tvrdit, ze koncepce a vlastnosti Pascalu ze 70.let jsou stejne jako z 90. let a z tohoto tisicileti je silenost. To "+ neco navic" dokazuje jen to, ze jste se tim dostatecne nezabyval, ja delal v TurboPascalu 6, 7 a pak v nekolika verzich Delphi od 1 az asi po 4 a rozdily byly obrovske, ze se skoro nedalo mluvit o stejnem jazyku a vyvoj jazyka sel s kazdou verzi o kousek dal (samozrejme i zasluhou knihoven, ne jen koncepce jazyka). A to porovnavam jenom TurboPascal a ObjectPascal. Podobnost syntaxe nic nerika, Modula taky neni Pascal.
with
beru, člověku to kolikrát ušetřilo zuřivé cvakání na klávesnici.'a'+'b'
je opravdu drobnost...pote, co jsem nastudoval strukturu PE souboru me to nejak prestalo bavit.
V tom jsem taky kdysi neco kutil, ale nikdy jsem nic nedokutil. Ted zkousim v lazarusu zbastlit kopii PE Exploreru (ten je tusim napsan v delphi) + podporu ELFu, ale jsem naprosto neschopny a pote, co jsem nastudoval strukturu PE souboru me to nejak prestalo bavit.To je tak složitý rozparsovat /etc/file/magic ?
Samozřejmě trochu chyběly makra a šablony a z moderních jazyků pokročilejší datové struktury jako seznamy, slovníky a operace nad nimi, ale dalo se to řešit a nikoli na úkor pracnosti, horší udržovatelnosti nebo znovupoužitelnosti kódu.
Co vim tak funkce v Pascalu nemohla mít jako návratový typ třeba soubor nebo datovou strukturu - ty se musely vracet přes výstupní parameterydobra otazka. co vim, tak v delphi toto by nemel byt problem. navic pri spravnem navrhu, nebudes vracet z funkce soubor, ale hodnotu typu myslim TFile (coz je vlastne ukazatel na instanci objektu). i.e., hezka ukazka, ze davat rovnost mezi pascal 70-let a delphi je blbost.
Root.Items.Add('item1').Items.Add('Item2').Items.Add('Item3');
ale hodnotu typu myslim TFileSpíš TFileStream
Jaký je rozdíl mezi komponentou a knihovnou nebo třídou?Knihovna - knihovna kompomenent a tříd? Dynamická knihovna? Musíš se lépe vyjádřit.
file of blabla
či textfile
jsem nikdy nepoužil, jsou špatně použitelné, a tedy netuším, jestli to jde vrátit z funkce, spíš ne.
int f,u=32,n[1024];s(v){if(u/=2)s(v),s(v|u),s (v|u<<5);n[v]=u=u?u+u:1;};main(){for(f=~1,s(0 );f<1024;printf(n[++f]?f&31?"#":"\n#":" "));}je krasa :) Ne,ale ted vazne...programoval jsem v Pascalu(i Delphi) i v C a nazor mam uplne opacny. C syntaxe je jednoducha, elegantni kratka a prehledna...pokud clovek nepise jako prase. Ja teda kdyz vidim Pascal tak je mi spatne...mozna proto ze nam i na VS tlacili do hlavy "Kdo programuje v Pascalu tak mu patri obe ruce urezat... :)" Btw, zkuste si ten kod prepsat do Pascalu...
begin/end
a ceckovych {}
, a to teprve pote, co jsem si to na par prikladech vyzkousel. Do te doby jsem preferoval begin/end
(protoze se {}
snadno da prehlednout) a na Python jsem se dival trochu skepticky. Clovek by mel vse zkusit a predem nic nezavrhovat.
for i := 0 to max do for j := i to max-1 do if pole[j]>pole[j+1] then prehod;
a jeden účastník vyrobil něco ve stylu:
for (i=0;i<max;i++) if (pole[i]>pole[i+1]) {prehod; i=-2; }
možná to není úplně přešné, ale to není podstatné. Oboje to funguje, ale na první, když se člověk podívá, tak vcelku rychle pochopí, co to dělá. U toho druhého, to už tak jednoduché není a rozhodně není ani jednoduché dokázat, že složitost je stejně n^2 jako v prvním případě. A dokonce i fakt, že se to vůbec zastaví není triviální... Na té soutěži jsme mu za originální řešení dali bod navíc, ale přiznejme si, v pracovním procesu bych radši viděl řešení prvním způsobem...
i -= 2
, předpokládám... (Nerejpu, jen poznámka A práveže není jedno, jestli Pascal nebo C. For x := 1 to 20 v Pascalu znamená projeď proměnou x od 1 do 20. To je naprsoto přehledné a jasné. Delphi vás už nenechají měnit řídící proměnou cyklu v cyklu, takže v Delphi už toto pomocí for nenapíšete. A to je právě ta pointa.To právě není ta pointa, protože v tom příkladě jsou v Pascalu dva for cykly vnořené do sebe. A na tom na první pohled není vidět o nic víc, než v tom Céčkovém zápisu.
for
má v Pascalu trochu jinou definici, v céčku to je v podsatě stejné jako while. Nadruhou stranu, zkus si v Pascalu (v Delphi) napsat ekvivalentanebofor (int i = 0; i < 20; i+=2) {}
V obou případech budeš muset použít dost nepřehlednou konstrukci použitímint i = 0, j = 20; for (;(i<20) && (j>0); i++,j--) {}
while
.