A Microsoft megnyitotta a Windows Calculator kódját

Open Source

A Microsoft bejelentette, hogy MIT licenc alatt megnyitotta a Windows Calculator kódját, ami elérhető a GitHub-on.

( xc0m v | 2019. 03. 07., cs – 08:27 )

Hátha le lehetne forkolni UWP helyett, mondjuk QT-val.
Vicces lenne látni Ubuntun.

Még jobb lenne ha a Microsoft megoldaná az UWP cross-platformos működését .NET Core-on.
Mert most itt van ez a Core ami már állítólag cross-platform. Azon UWP lenne a fő GUI irány de az mégiscsak Windows-hoz kötődik.
Így nem kell azon csodálkozni, hogy a Java királysága megingathatatlan továbbra is.

( whitehawk v | 2019. 03. 07., cs – 08:31 )

A programozói nézetbe úgyis kéne előjel nélküli számolási lehetőség..

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

( elod v | 2019. 03. 07., cs – 08:43 )

Fantasztikus. Most már azon kéne dolgozni hogy induljon is. A sok fejlesztéssel valahogy oda jutottunk hogy egy ilyen egyszerű dolog nem indul első kulcsra az esetek 100%-ában (mert Store App lett).

Ez nekem is megvolt, de egyszer csak azt vettem észre, hogy 2 calculator ikonom van. A snap csomagot ismét eltávolítottam és azóta nem jött vissza. Hogy mikor tette fől és mi azt nem nyomoztam, de rohadtul idegesítenek ezek a snap csomagok.
Azt nem értem miért kellett ebbe energiát ölni, vagy ha már elhatározták hogy kell nekik egy ilyen akkor szokásukhoz híven 10 év kínlódás után feltehették volna a polcra a MIR és az Unity-next(unity8) mellé, mert odavaló. Viszont az Unity-next -et azt sajnálom.

Ne csináld, csak speciális esetben távolítsd el a BOM-ot, akkor, amikor expliciten nincs engedélyezve a használata, a Unicode standard ezt le is írja.

"The Unicode Standard permits the BOM in UTF-8, but does not require or recommend its use....The standard also does not recommend removing a BOM when it is there, so that round-tripping between encodings does not lose information, and so that code that relies on it continues to work."
Pontosan ez van a szabványban:

"In UTF-8, the BOM corresponds to the byte sequence . Although there are never any questions of byte order with UTF-8 text, this sequence can serve as signature for UTF-8 encoded text where the character set is unmarked. "
Szóval van értelme a BOM-nak, mert szöveges tartalomnál jelezheti, hogy az azt követő bytesorozat UTF-8-ként kódolt Unicode karaktereket ír le.

Illetve ott a BOM FAQ:
http://unicode.org/faq/utf_bom.html#bom5

( YleGreg | 2019. 03. 07., cs – 09:33 )

Azon kívül, hogy aki programozósuliba jár, az tud belőle copy-pa... akarom mondani inspirációt meríteni, van bármilyen haszna pont egy ilyen 12 egy tucat programot megnyitni?

Azért kérdezem, mert ez az "excited to announce", nekem fura.
Most tényleg van itt valami izgalom, vagy csak simán belehazudnak a képembe már a bejelentés első sorával?

Szerintem az amerikai kultúra sokkal képmutatóbb: kérdezgeti how are you doing, érdeklődést tettet feléd, közben a választ le se szarja. Csak azért kezdeményezett beszélgetést, h. azt mutassa ő milyen szociálisan érzékeny az irányodba. Ha engem valaki nem érdekel, szimplán elkerülöm vagy nem szólok hozzá. Nem tettetem a jópofizást. Sokkal őszintébb.
--

"Ha engem valaki nem érdekel, szimplán elkerülöm vagy nem szólok hozzá. Nem tettetem a jópofizást. Sokkal őszintébb."

+1

Ezek a small talk-os emberek igazi energiavámpírok. Sajnos nem érzik. Ha szólsz nekik, akkor meg megsértődnek. De inkább sértődjenek, mint az időmet és az energiámat lopják.

--
trey @ gépház

"Azért kérdezem, mert ez az "excited to announce", nekem fura."

Marketing bullshit, mit foglalkozol vele?

"van bármilyen haszna pont egy ilyen 12 egy tucat programot megnyitni?"

Igen, az, hogy látod, hogy az MS hogy képzeli el házon belül egy ilyen alkalmazást. Illetve abból a szempontból is érdekes még, hogy managed C++, nem pedig C# (ez egy picit meglepett), ami AFAIK egy jóval ritkábban használt programnyelv. (Igazából csak ott láttam, ahol natív meg managelt kódot kellett összeragasztani, vagy CLR-hez csináltak valami wrappert egy natív kód köré.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( b | 2019. 03. 07., cs – 09:37 )

ezért vették meg a githubot?
gyenge...

--
GPLv3-as hozzászólás.

( pehsa | 2019. 03. 07., cs – 10:12 )

Örülök annak, hogy a Microsoft egyre több dolgot nyit Open Source irányba, viszont egy kicsit olyan érzés, hogy próbálja csökkenteni a kis "modulok" házon belüli fejlesztését ezért inkább megnyitja, hogy mások ingyen fejlesszék neki.

---
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

AZ ilyen kis alkalmazások (Notepad, Calculator, Paint stb.) tökéletesek a MS-nek arra, hogy a belépő új fejlesztők feladatokat kapjanak, amiben megismerik az MS-nél azt, hogy miként dolgoznak, mi az infrastruktúra, hogyan megy az issue management, mi a code style stb.
Emiatt van az, hogy apránként fejlesztgetik ezeket az alkalmazásokat, a Notepad is kap néha új feature-t.

Notepad mikor kapott utoljára új feature-t? Nem kötekedés, lehet átsiklottam felette, meg alapból NP++ ha ilyesmiről van szó.
Amúgy MS féle szoftver design inkább káosz kategória. UWP-s appokból ahány annyi féle menü, hamburger menü, egyiknél a gomb jobb oldalon, másik programnál teljesen máshol ha van egyáltalán.

Plusz ezen felül engem baromira zavar az UWP-s calculator indulási lagja, anno már w95-nél meg tudták oldani hogy elindítom és azonnal ütöm be a számokat és már veszi is, UWP-s cuccnál meg splash screen miatt akármilyen bika alatta a vas, az első 2-3 számjegy általában lemarad. Persze, lehet várni de azért jó pár éves beidegződést nem egyszerű elfelejteni, arról nem is beszélve hogy ezt semmiképpen sem tudnám pozitív változásnak tekinteni.

"Notepad mikor kapott utoljára új feature-t? Nem kötekedés, lehet átsiklottam felette, meg alapból NP++ ha ilyesmiről van szó."
Az előző Windows kiadásban.
UNIX sorvégek támogatása, wrap around find/replace, text zooming stb.
https://www.howtogeek.com/359042/everything-new-in-notepad-in-windows-1…

Ha ez bug, akkor az összes lebegőpontos számítás kerekítési hibái is bugosak, amióta lebegőpontos számítás létezik.
A cikk alatti kommentből: A hibás eredmény -8.164846955514.....e-39 lenne, ami _gyakorlatilag_ nulla. Ahol pedig !negyven! tizedesjegyig fontos a pontosság, ott meg olyan ember van, aki éri is hogy mit csinál, mivel csinálja és annak a módszernek mik a határai.

Az sqrt(4) az pontosan kettő. Egész számokon lehetőleg ne csináljon kerekítési hibát. Van egész gyökvonásos algoritmus is, amennyiben egész a végeredmény, egészet adjon vissza.
Kb. akkora hiba, mintha a 9/3 az 2.9999999999999999 lenne, szerintem súlyos. Nem hagytuk el a gyökvonással az egész számok körét, ha kivonunk belőle 2-t, negatív tartományba pláne nem megyünk át.

sqrt(sqrt(4)-2)

mennyit ad vissza? Rögtön komplex számok jönnek?

Nem keverjük, egy számológépnek tudnia kell kerekíteni, pláne ilyen triviális esetben.

Ez bug, amit javítani kellett. A sin(k*pi) sem egyszerűbb történet, de jobb programok lökni szokták rá a 0-t.
Pedig itt irracionális számról van szó, ami valóságban sem nulla, mert a pi-t csak adott pontosságig használjuk.

Felvennéd akkor inkább listaszerűen az összes edge-case-t, vagy lebegőpontos számítás helyett fixpontosat alkalmaznál? (ami lassabb, de lássuk be modern hardware-n már igazán nem számít) és akkor néznéd nagy kerek buci szemekkel, hogy a másik program miért ad kicsit más eredményt?

Vagy lehessen konfigurálni hogy éppen melyik módban hogyan számol, és elmagyarázod a felhasználóidnak hogy mi a különbség a lebegő és a fixpontos eredmény között?

A Commodore 64 úgy számolta a sin-t, hogy a bemenő értéket elosztotta 2*pi-vel és vette a tört részét a számnak. A kapott számot ezután visszaszorozta újra 2*pi-vel a Taylor interpoláció előtt. Milyen frappáns, nem? 1982-ből!

Vannak értelmes programozók is, nem csak a Nobel-díjasok. Tudom, parasztos dolog a sin(12343.2424) bemenetét 2pi-vel osztani, amikor a Taylor interpoláció 10000 tag esetén már jó eredményt adna, de érdemes lenne a "másként gondolkodókat" is elfogadni. Van, akit már 1982-ben is zavart, hogy a sin(10*pi) az nem nulla.

Nem ma találták fel a kerekítési algoritmusokat.

A 2*pi-vel való osztás és a 2*pi-vel való szorzás egymás után nem lesz igazán pontos (eleve a Pi értéke gépen csak közelítés), a relatív hibák összegződnek ilyenkor, és nem egyenlítődnek ki a műveletek során.
Nem frappáns, csak éppen nem tudtak jobbat csinálni.
A lebegőpontos számítás nem játék. A műveletek nem kommutatívak, nem asszociatívak, nem lehet csak úgy műveleteket végezni, anélkül, hogy tudnád igazából, hogy mit csinálsz.

Pontosan.

Ezért vannak a matematikusok, akik 40 évvel ezelőtt kitalálták, hogy hogyan lehet lebegőpontos műveletekkel pontosan számolni.

A log függvény esete sem egyszerűbb, mert rohadt lassan konvergál.

1000 oldalas könyveket lehet kapni arról, hogy az adott lebegőpontos műveletet miként kell elvégezni, hogy tényleg pontos legyen!

Mindezt matematikai számításokkal, maximális pontatlanság számszerűsítésével alátámasztva. Nem újkeletű problémáról beszélünk, ha pedig sqrt(4) esetén félreszámol, a többi helyen mit csinálhat?

( gee v | 2019. 03. 07., cs – 12:37 )

Hátha valaki kijavítja, hogy a műveleti sorrendre odafigyeljen, és akkor a nagy facebookos vitákban nem lesznek tömegével, akik azzal érvelnek, hogy hiszen a Windows calculatorba beírta, hogy 2+3*4, és bizony 20 az eredmény, nem 14

Le is zárták igen gyorsan:

I am going to close this bug as by design for now, but we welcome suggestions on how to improve this experience.

https://github.com/Microsoft/calculator/issues/138

Tehát implementáltak egy hibát, amit a régi 1000 éves vackokban is várhatóan csak technikai limitáció volt. :)

no comment.

--
zrubi.hu

Ezzel csak az a baj, hogy aki anno rendesen megtanulta matematikából a műveleti sorrendet, az a régi számológépek technikai limitációján túllépve megfelelő sorrendben adta meg a számolni kívánt dolgokat. Aki meg nem tanulta meg, az biztos, hogy nem matematikus lett. :D

Viszont ha a régi számológépes beidegződést hagyjuk meg Standard módban, akkor a sok szellemileg alulmaradt felhasználó továbbra is a hibás értékeket fogja kapni egy-egy számításnál és még neki áll feljebb amikor számon kérik tőle. Lásd a fentebbi FaceBook-os példa, ahol mindenki okosnak hiszi magát és mindenkit leszólnak, aki szerint nem az ő hibás eredményük a jó, mert még arra is képtelenek, hogy a Windows számológépet átállítsák Tudományosra.

---
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Az a különbség, hogy az MS kalkulátor nem hajtja azonnal vissza. Beírod, és amikor =-t ütsz, akkor hajtja végre.

Ha átkapcsolod tudományos módba, akkor ugyanazokat a billentyűket leütve jó eredményt ad.

Ebből látszik, hogy valóban, ez egy döntés volt.

Én azért írtam, mert szerintem rossz döntés. Remélem, hogy most, hogy nyílt forrású lett, valaki kijavítja.

( xc0m v | 2019. 03. 07., cs – 13:34 )

Valaki nem akar egy Issue-t nyitni, hogy mikor lesz belőle Linux-os build?

Nem feltétlen a Linux-os build miatt, de már többekben felmerült, hogy a régi verziós calc.exe kódját is adják ki:

https://github.com/Microsoft/calculator/issues/105
https://github.com/Microsoft/calculator/issues/161
https://github.com/Microsoft/calculator/issues/164

Azt egyszerűbb lenne portolni, mint ezt az UWP-s változatot

---
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

A probléma, hogy nem.

A Dot Net Core meg lett nyitva és tökéletesen működik Linux-on/Unix-on. A Dot Net Core támogatja a WPF-et, viszont CSAK Windows-on, ugyanis a WPF lehet nyílt forrású lett, de nagyon rendszer specifikus dolgokkal operál, amit portolás során valamilyen úton-módon le kellene emulálni egyéb rendszereken.

Az UWP meg csak egy API lényegében, ami össze akarja fogni a grafikai fejlesztést Windows 10 és Xbox One között, hogy kb ugyanúgy nézzen ki egy alkalmazás itt és ott is.

A probléma, hogy át kellene nézni a teljes kódot, kukázni az UWP-s részeket és azokat újra kellene implementálni egy könnyebben portolható grafikus kódbázisra, ami akár lehetne Windows Forms is.

---
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

"amit portolás során valamilyen úton-módon le kellene emulálni egyéb rendszereken."

Helló, ezt hívják portolásnak.

"Az UWP meg csak egy API lényegében, ami össze akarja fogni a grafikai fejlesztést Windows 10 és Xbox One között, hogy kb ugyanúgy nézzen ki egy alkalmazás itt és ott is."

Igen, és? Ezt hívják portolásnak.

"A probléma, hogy át kellene nézni a teljes kódot, kukázni az UWP-s részeket és azokat újra kellene implementálni egy könnyebben portolható grafikus kódbázisra"

Igen és? Interface adott, implementációt meg meg kell csinálni. Még mindig könnyebb, mintha kód sem lenne.

"ami akár lehetne Windows Forms is."

WinForms implementáció most is van, ellenben AFAIK nem része a netcorenak. (Meg igazából felejtsük már el. 95-ben a Delphi 1 idejében nagyon előremutató volt ez a koncepció, azóta viszont eltelt majdnem 25 év.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( Raynes | 2019. 03. 07., cs – 18:00 )

Szép gesztus, de baromi felesleges. Nagyon alap progik az MS Számológépek, ilyeneket kezdő programozók is simán újraimplementálnak akármelyik platformon programozási gyakorlat képpen.

Régen én is nyomkodtam ilyen GUI-s számológépeket (Linux alatt KCalc, Galculator és egyebek), aztán áttértem terminálos programokra. Jelenleg calc-ot használok, de van fent octave is. Már eleve a calc is overkill, nem csak hogy rendesen kezeli a műveletek precedenciáját, de sok millió számjegyig simán számolja az orbitális faktoriálisokat, és gigantikus hatványokat (és nem butítja normál alakra és pár tizedesjegyre az eredményt), csomó függvényt tud, ami tovább bővíthető, tud komplex számokkal és mátrixokkal számolni, stb.. Billentyűzetről sokkal gyorsabb a műveletsort beírni, meg látom mit vittem be, észreveszem, ha elgépeltem valamit, vissza lehet pörgetni a számolási history-t, ezzel újrahasznosítva a számítási sorokat, ez a GUI-s progiknál nehézkes.

Ahol fontosak ezek a GUI-s számológépek, azok a mobil, táblagép kategóriája, ott az érintőképernyőn tapicskolás miatt fontos, a karakteres mód kényelmetlen lenne. Androidon a RealCalcot használom, még megjelenésében is a klasszikus tudományos számológépeket imitálja. Nem is értem, hogy ki vesz ma már számológépet. Max. csak elkurvult helyeken tudom elképzelni, ahová nem lehet telefont, PC-t bevinni.
No keyboard detected... Press F1 to run the SETUP

( kovi | 2019. 03. 08., p – 17:28 )

Még mindig jobb, mintha a calc nyitotta volna meg a Windows kódját muhawhaha

--
Vortex Rikers NC114-85EKLS

( the_manni | 2019. 03. 11., h – 19:10 )

Szerintem azért, hogy biztonsági javításokat tudjanak hozzá kapni. De mindegy is, mert ha újraforgatod (módosítások nélkül), akkor is letiltja windows defender.

Mondjuk annak, akinek magyarázni kell, hogy egy invalid input naplózása és elemzése vajon miért hasznos és, hogy az user szokásokhoz lehet igazítani egy szoftvert, az is megér egy rly? kérdést.

Mert egyébként meg nyilván az a tipikus use-case, hogy jelszavakat másolunk szándékosan egy számológépbe.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™