Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #28849 > unrolled thread
| Started by | slawek <fake@fakeemail.com> |
|---|---|
| First post | 2016-09-26 15:57 +0200 |
| Last post | 2016-12-26 23:00 +0100 |
| Articles | 20 on this page of 278 — 19 participants |
Back to article view | Back to pl.comp.programming
Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-26 15:57 +0200
Re: Pascal - ankieta bartekltg <bartekltg@gmail.com> - 2016-09-26 08:39 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-26 18:02 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-09-26 19:55 +0200
Re: Pascal - ankieta joahim <w.birula@gmail.com> - 2016-10-01 09:18 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 18:59 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-01 19:42 +0200
Re: Pascal - ankieta joahim <w.birula@gmail.com> - 2016-10-01 11:04 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-01 20:21 +0200
Re: Pascal - ankieta darekm <darekm@emadar.com> - 2016-10-04 16:34 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-04 18:40 +0200
Re: Pascal - ankieta Mateusz Bogusz <mabakay@o2.pl> - 2016-10-04 19:18 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-04 20:15 +0200
Re: Pascal - ankieta darekm <darekm@emadar.com> - 2016-10-05 17:35 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-05 18:22 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-05 22:23 +0200
Re: Pascal - ankieta Adam M <amorawski@magna-power.com> - 2016-10-05 14:26 -0700
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-13 19:19 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-13 19:36 +0200
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-13 20:33 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-13 20:42 +0200
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-13 21:52 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-13 22:13 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-05 22:18 +0200
Re: Pascal - ankieta joahim <w.birula@gmail.com> - 2016-10-07 09:53 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 20:46 +0200
Re: Pascal - ankieta joahim <w.birula@gmail.com> - 2016-10-01 12:46 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 22:35 +0200
Re: Pascal - ankieta joahim <w.birula@gmail.com> - 2016-10-01 10:52 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 20:48 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 21:03 +0200
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-13 19:15 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-14 06:51 +0200
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-16 15:22 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-01 14:14 -0700
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-27 03:03 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-27 17:03 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-27 10:52 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 07:34 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 07:51 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-28 00:58 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 11:27 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-28 12:12 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 12:27 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-28 13:37 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 12:36 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-28 13:43 +0200
Re: Pascal - ankieta "M.M." <mmarszik@gmail.com> - 2016-09-27 11:28 -0700
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-28 12:03 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 12:26 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-28 13:02 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 13:19 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-28 00:08 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 08:29 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-28 11:00 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 11:46 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-28 12:09 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 12:23 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 12:24 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-28 11:32 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 12:15 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-28 03:26 -0700
Re: Pascal - ankieta Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2016-09-28 13:00 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 13:13 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-28 13:20 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 13:27 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-28 15:07 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 15:22 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-28 15:33 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 15:47 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-28 06:47 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 15:50 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-28 07:05 -0700
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-28 20:23 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 23:09 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-28 21:42 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 23:21 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-29 11:47 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-29 15:51 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-29 07:17 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-29 17:25 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-29 09:19 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-29 19:02 +0200
Re: Pascal - ankieta Adam M <amorawski@magna-power.com> - 2016-09-29 10:29 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-29 19:45 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-30 11:55 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 19:50 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-30 22:34 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 20:15 +0200
Re: Pascal - ankieta Kviat <null> - 2016-09-30 20:47 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 21:15 +0200
Re: Pascal - ankieta Kviat <null> - 2016-09-30 21:44 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 22:21 +0200
Re: Pascal - ankieta Kviat <null> - 2016-09-30 22:53 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-30 22:34 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 23:50 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-30 14:58 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 08:17 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-01 01:39 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 12:21 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-10-01 18:10 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 18:45 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-10-01 19:15 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 20:16 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-10-01 20:25 +0200
Re: Pascal - ankieta darekm <darekm@emadar.com> - 2016-10-03 19:02 +0200
Re: Pascal - ankieta Adam M <amorawski@magna-power.com> - 2016-10-03 12:02 -0700
Re: Pascal - ankieta Kviat <null> - 2016-09-30 23:59 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 08:33 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-10-01 08:54 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 09:17 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-10-01 10:07 +0200
Re: Pascal - ankieta Mateusz Bogusz <mabakay@o2.pl> - 2016-10-04 19:22 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-10-04 20:28 +0200
Re: Pascal - ankieta Adam M <amorawski@magna-power.com> - 2016-09-29 10:22 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-29 19:47 +0200
Re: Pascal - ankieta Adam M <amorawski@magna-power.com> - 2016-09-29 10:52 -0700
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-30 12:48 +0200
Re: Pascal - ankieta Adam M <amorawski@magna-power.com> - 2016-09-30 07:56 -0700
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-30 08:35 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 20:26 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-30 11:31 +0200
Re: Pascal - ankieta Kviat <null> - 2016-09-29 23:53 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 07:22 +0200
Re: Pascal - ankieta Kviat <null> - 2016-09-30 07:37 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 09:20 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-30 11:33 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 19:43 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-30 00:51 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 10:56 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-30 02:12 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 19:33 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-09-30 22:14 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 22:43 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-30 13:52 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 23:57 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-30 15:10 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 07:18 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 19:36 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-30 13:12 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 22:37 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-30 13:50 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 23:04 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-09-30 14:11 -0700
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-10-01 09:16 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-01 01:54 -0700
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-10-01 11:32 +0200
Re: Pascal - ankieta "slawek" <slawek@host.pl> - 2016-10-01 11:53 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-01 03:41 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-01 13:21 +0200
Re: Pascal - ankieta Kviat <null> - 2016-10-01 13:33 +0200
Re: Pascal - ankieta Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2016-10-03 10:40 +0200
Re: Pascal - ankieta wloochacz <wloochacz@no.spam.gmail.com> - 2016-10-03 15:12 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-03 17:16 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-03 08:40 -0700
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-13 19:09 +0200
Re: Pascal - ankieta Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2016-10-04 07:54 +0200
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-13 19:07 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-03 17:52 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-10-03 20:04 +0200
Re: Pascal - ankieta Kviat <null> - 2016-10-01 13:27 +0200
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-13 18:55 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-13 10:15 -0700
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-13 20:25 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-13 11:42 -0700
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-13 18:54 +0200
Re: Pascal - ankieta Mateusz Bogusz <mabakay@o2.pl> - 2016-10-04 19:53 +0200
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-13 18:51 +0200
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-13 18:45 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-30 12:11 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 20:29 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 20:32 +0200
Re: Pascal - ankieta Kviat <null> - 2016-09-30 20:57 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 21:51 +0200
Re: Pascal - ankieta Kviat <null> - 2016-09-30 22:01 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-30 22:26 +0200
Re: Pascal - ankieta Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2016-09-28 14:01 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-28 15:17 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 15:26 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-09-28 15:34 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-09-28 15:48 +0200
Re: Pascal - ankieta Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2016-09-28 15:59 +0200
Re: Pascal - ankieta Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2016-09-27 12:46 +0200
Re: Pascal - ankieta Mateusz Bogusz <mabakay@o2.pl> - 2016-10-02 17:54 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-10-19 21:05 +0200
Re: Pascal - ankieta krolikbest <krolikbest@wp.pl> - 2016-10-21 16:17 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-22 08:04 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-22 01:05 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-22 13:55 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-22 08:39 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-22 18:57 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-22 10:39 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-22 20:27 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-22 12:13 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-22 22:07 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-22 16:43 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 09:40 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-23 10:14 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-23 02:07 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-23 11:21 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-23 03:41 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 13:02 +0200
Re: Pascal - ankieta Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2016-10-24 08:15 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-24 09:03 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-23 13:09 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-23 04:38 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-23 13:52 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-24 09:00 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-24 16:21 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 13:12 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 13:13 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 12:06 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 12:15 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 12:17 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 12:20 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 09:29 +0200
Re: Pascal - ankieta Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2016-10-24 08:06 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-24 09:08 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-24 16:02 +0200
Re: Pascal - ankieta Maciej Sobczak <see.my.homepage@gmail.com> - 2016-10-24 06:21 -0700
Re: Pascal - ankieta Adam M <amorawski@magna-power.com> - 2016-10-24 06:37 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-24 16:04 +0200
Re: Pascal - ankieta Adam M <amorawski@magna-power.com> - 2016-10-24 07:28 -0700
Re: Pascal - ankieta Maciej Sobczak <see.my.homepage@gmail.com> - 2016-10-24 14:33 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-24 16:17 +0200
Re: Pascal - ankieta Maciej Sobczak <see.my.homepage@gmail.com> - 2016-10-24 15:01 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-25 07:59 +0200
Re: Pascal - ankieta Maciej Sobczak <see.my.homepage@gmail.com> - 2016-10-25 02:32 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-25 12:27 +0200
Re: Pascal - ankieta Maciej Sobczak <see.my.homepage@gmail.com> - 2016-10-25 07:10 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-25 17:30 +0200
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-25 18:12 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-25 18:18 +0200
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-25 17:39 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-25 18:21 +0200
Re: Pascal - ankieta Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2016-10-26 07:59 +0200
Re: Pascal - ankieta Maciej Sobczak <see.my.homepage@gmail.com> - 2016-10-26 00:07 -0700
Re: Pascal - ankieta Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2016-10-26 09:53 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-26 09:57 +0200
Re: Pascal - ankieta Maciej Sobczak <see.my.homepage@gmail.com> - 2016-10-26 06:26 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-26 15:46 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-26 16:15 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-26 16:10 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-26 16:14 +0200
Re: Pascal - ankieta Maciej Sobczak <see.my.homepage@gmail.com> - 2016-10-26 13:59 -0700
Re: Pascal - ankieta Adam M <amorawski@magna-power.com> - 2016-10-27 06:33 -0700
Re: Pascal - ankieta Maciej Sobczak <see.my.homepage@gmail.com> - 2016-10-27 15:21 -0700
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-25 17:28 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-25 17:39 +0200
Re: Pascal - ankieta "re" <re@re.invalid> - 2016-10-25 18:11 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-26 07:19 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 09:23 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-23 00:32 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 09:51 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 09:27 +0200
Re: Pascal - ankieta godek.maciek@gmail.com - 2016-10-23 00:43 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 09:53 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 10:00 +0200
Re: Pascal - ankieta Adam M <amorawski@magna-power.com> - 2016-10-24 06:29 -0700
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-24 15:58 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 08:42 +0200
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-10-23 10:19 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 12:31 +0200
Re: Pascal - ankieta Wojciech Muła <wojtek.mula@gmail.com> - 2016-10-23 08:08 -0700
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 08:33 +0200
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-10-23 08:23 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-10-22 10:14 +0200
Re: Pascal - ankieta Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2016-10-24 07:45 +0200
Re: Pascal - ankieta Roman Tyczka <noemail@because.no> - 2016-12-02 17:28 +0100
Re: Pascal - ankieta Robert Largon <slawek4009@gmail.com> - 2016-12-21 01:05 -0800
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-12-21 21:37 +0100
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-12-23 08:58 +0100
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-12-23 08:38 +0100
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-12-23 18:15 +0100
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-12-23 20:52 +0100
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-12-24 10:50 +0100
Re: Pascal - ankieta slawek <fake@fakeemail.com> - 2016-12-26 22:46 +0100
Re: Pascal - ankieta Sebastian Biały <heby@poczta.onet.pl> - 2016-12-26 23:00 +0100
Page 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
| From | Adam M <amorawski@magna-power.com> |
|---|---|
| Date | 2016-10-24 06:37 -0700 |
| Message-ID | <242202b1-dfb4-4286-bd62-2aef819028d5@googlegroups.com> |
| In reply to | #29176 |
On Monday, October 24, 2016 at 9:21:30 AM UTC-4, Maciej Sobczak wrote: > > > Nie spotkałem się z jego szerszym zastosowaniem w embedded > > > > Nie szukaj daleko: Arduino. Że amatorskie? Za chwile Ci amatorzy będa > > pracować dla firm robiących embedded. > > Co nie znaczy, że dalej będą pisać w C++. > To "C++" w Arduino równie dobrze mogłoby być Javą, nawet bez wielkiej zmiany w składni. I tym ludziom od Arduino nie zrobiłoby to żadnej różnicy. > > To wcale nie jest takie oczywiste, że C++ będzie poważniej używane w embedzie. Ogólnie i z obraźliwym zaokrągleniem, embedy można podzielić na: > > - krytyczne > - rozrywkowe > > W części "krytycznej" C++ nie wnosi niczego istotnego, bo to, co jest jego obiektywną wartością dodaną i tak nie obniża wymaganego wysiłku weryfikacyjnego a tego jest większość w całym cyklu życia projektu. To oznacza, że o ile w "normalnym" programie takie rzeczy jak RAII czy nawet sama kontrola widoczności są cenne, to w systemie krytycznym ich zbawczy wpływ w kontekście całego projektu jest znacznie mniejszy. Stąd też znacznie mniejsza motywacja, żeby po C++ sięgnąć. Tak, jest MISRA-C++, ale chyba wszyscy to olali. > W częście "krytycznej" konkurentem dla C nie jest C++, tylko Ada/SPARK, ale branża nie zdąży tego konkursu rozstrzygnąć, bo prędzej przestawi się na kompletną generację kodu a wtedy nie będzie znaczenia, w czym. > > Natomiast w części "rozrywkowej" C++ nie zdąży wyprzeć obowiązującego obecnie C, bo zanim się zorientujemy, to hardware będzie wspierał Javę albo coś z tej ligi. I cała ta brać makersów z plecakami pełnymi prototypów na Arduino bez mrugnięcia okiem się na to coś przestawi, bo z ich punktu widzenia język nie ma znaczenia, znaczenie mają natomiast IDE oraz bogactwo frameworków do IoT. > > > Ale biologia działa i > > wystarczy poczekać. > > Sęk w tym, że hardware rozwija się szybciej, niż programiści C wymierają. To może spowodować, że okno czasowe, w którym C++ miałby szansę na zdobycie istotnej części rynku, może nie wystąpić. Czyli po C nastąpi od razu porzucenie kodu jako istotnego artefaktu projektowego (w częśći "krytycznej") albo Java/łotewer (w części "rozrywkowej"). > > Oczywiście nie twierdzę, że C++ nie będzie używany. Będzie. Prawdopodobnie branża motoryzacyjna będzie jego głównym użytkownikiem, bo tam będzie presja na wykorzystanie istniejącego kodu w C i są jakieś standardy jakości utrudniające bezmyślne uzywanie Javy. Ale rynek embedded jest znacznie większy, niż samochody. > > > Przeszkodą jest jedynie biologia, inercja i Linus Torvalds. > > Trafne. > > -- > Maciej Sobczak * http://www.inspirel.com Z branza motoryzacyjna i lotnicza kolega sie myli - w tym przypadku embeded system sa programowane w wiekszosci w Matlab/Simulik (bo daje mozliwosc symulacji zastosowanych algorytmow) i docelowy kod jest generowany w C. W C pisze sie tez niskopoziomowa i czasow krytyczna obsluge np SPI i DMA. C++ najczesciej jest uzywany gdy zachodzi potrzeba programowania ladnego GUI (z uzyciem QT najczesciej)
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2016-10-24 16:04 +0200 |
| Message-ID | <nul4f4$9ch$2@node2.news.atman.pl> |
| In reply to | #29178 |
On 2016-10-24 15:37, Adam M wrote: > Z branza motoryzacyjna i lotnicza kolega sie myli - w tym przypadku embeded system sa programowane w wiekszosci w Matlab/Simulik > (bo daje mozliwosc symulacji zastosowanych algorytmow) i docelowy kod jest generowany w C. No popatrz, a z mojejgo stołka widać że branża motoryzacyjna i lotnicza projektowane są w Verilog/UVM, VHDL. Pewno siedzimy na różnych stołkach. > C++ najczesciej jest uzywany gdy zachodzi potrzeba programowania ladnego GUI (z uzyciem QT najczesciej) W tej branzy lotniczej i samochodowej ...
[toc] | [prev] | [next] | [standalone]
| From | Adam M <amorawski@magna-power.com> |
|---|---|
| Date | 2016-10-24 07:28 -0700 |
| Message-ID | <ad9841b8-c66e-4938-a380-8c5fb3306648@googlegroups.com> |
| In reply to | #29181 |
On Monday, October 24, 2016 at 10:05:25 AM UTC-4, Sebastian Biały wrote: > On 2016-10-24 15:37, Adam M wrote: > > Z branza motoryzacyjna i lotnicza kolega sie myli - w tym przypadku embeded system sa programowane w wiekszosci w Matlab/Simulik > > (bo daje mozliwosc symulacji zastosowanych algorytmow) i docelowy kod jest generowany w C. > > No popatrz, a z mojejgo stołka widać że branża motoryzacyjna i lotnicza > projektowane są w Verilog/UVM, VHDL. Pewno siedzimy na różnych stołkach. > > > C++ najczesciej jest uzywany gdy zachodzi potrzeba programowania ladnego GUI (z uzyciem QT najczesciej) > > W tej branzy lotniczej i samochodowej ... Kolega pewnie pisze dla FPGA lub CPLD. Ja mam doczynienia z DSP/MCU - tu Verilog nie powalczy ;-) .
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2016-10-24 14:33 -0700 |
| Message-ID | <f8bf9c41-915a-45b5-ba2d-c932296f74ed@googlegroups.com> |
| In reply to | #29178 |
> > W częście "krytycznej" konkurentem dla C nie jest C++, tylko Ada/SPARK, ale branża nie zdąży tego konkursu rozstrzygnąć, bo prędzej przestawi się na kompletną generację kodu a wtedy nie będzie znaczenia, w czym. > Z branza motoryzacyjna i lotnicza kolega sie myli - w tym przypadku embeded system sa programowane w wiekszosci w Matlab/Simulik (bo daje mozliwosc symulacji zastosowanych algorytmow) i docelowy kod jest generowany w C. Dokładnie o tym pisałem powyżej. Przeczytaj jeszcze raz. Natomiast co do tej "większości" to bym nie szarżował. Na razie branża jest na etapie wniosku, że to jest dobry kierunek na przyszłość. Dopiero wtedy (w przyszłości) może to będzie większość - ale niekoniecznie Simulink i niekoniecznie C. > C++ najczesciej jest uzywany gdy zachodzi potrzeba programowania ladnego GUI (z uzyciem QT najczesciej) Co oznacza, że szansą dla C++ są gotowe biblioteki i frameworki, bo o sam język dla języka nikt walczyć nie będzie. Swoją drogą właśnie tak to zadziałało z Arduino. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2016-10-24 16:17 +0200 |
| Message-ID | <nul57d$hjs$1@node1.news.atman.pl> |
| In reply to | #29176 |
On 2016-10-24 15:21, Maciej Sobczak wrote: >> Nie szukaj daleko: Arduino. Że amatorskie? Za chwile Ci amatorzy będa >> pracować dla firm robiących embedded. > Co nie znaczy, że dalej będą pisać w C++. Pewno że nie, będa musza poczekać aż zadziala biologia w starych zespołach. Jesli ktoś zabiera Ci możliwości i każe pisać w języku z ery bita łupanego to prędzej czy później frustracja przerodzi się w zmiany. Takie zmiany generowane przez młodych bez kompleksow i wbudowanej ignorancji widuję tu i tam. > To "C++" w Arduino równie dobrze mogłoby być Javą Nie. Narzut na prosty procesor jest za duży. Nie mogłoby. Rownież z powodu faktu że Java bedzie silnie zależeć od GC co jest w wielu aplikacjach embedded niedopuszczalne nawet jesli to jakies protezy jak JavaRT. > To wcale nie jest takie oczywiste, że C++ będzie poważniej używane w embedzie. Alez nie będzie. Nikt tak nie wróży. Docelowo to będzie C z elementami C++. Tak jak obecnie coraz częsciej się robi. Może z czasem coraz większymi. Problemem programistów C jest to że sama zmiana gcc na g++ wystarcza aby z nich (ficzerów) korzystać. To tak nie daje im spać że internet jest pełen idiotyzmów dlaczego C++ nie nadaje się na uC. Zjawisko z pogranicza religii. > W części "krytycznej" C++ nie wnosi niczego istotnego, bo to, co jest jego obiektywną wartością dodaną > i tak nie obniża wymaganego wysiłku weryfikacyjnego a tego jest większość w całym cyklu życia projektu. To jest nieprawda. Podstawową wartością jaką wprowadza C++ jest znaczące ułatwienie testowania i weryfikacji bez narzutu runtime. Zarówno na etapie unit testów, jak i przy głupiej kompilacji. C tego nie ma i cieżko to zrobić bez psucia kodu. To że zdecydowana większość programistów embedded rozumie C++ jako new Foo; to jest ich problem. > To oznacza, że o ile w "normalnym" programie takie rzeczy jak RAII czy nawet sama kontrola widoczności są cenne >, to w systemie krytycznym ich zbawczy wpływ w kontekście całego projektu jest znacznie mniejszy. Zawsze możesz przedstawić przykład dlaczego mniejszy. W tym watku właśnie jeden mistrz pokazał jak sobie żyły wypruł makrem aby uzyskać popsutą symulację RAII. Oglądałem nie jeden kod embedded w którym wymyślano takie kwadratowe koła za każdym razem. Za każdym razem identycznie popsute. Na haslo "ale przeciez to działa w C++" zazwyczaj parskali albo ignoranckim śmiechem albo pustą godzinną przemową o debiliźmie młodego pokolenia. Nie ma przeszkod technicznych. A wracają do Pascala ...
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2016-10-24 15:01 -0700 |
| Message-ID | <11801d37-5de9-42df-aa2a-61f2d27b0aa1@googlegroups.com> |
| In reply to | #29182 |
> > To "C++" w Arduino równie dobrze mogłoby być Javą > > Nie. Tak. Mam na myśli oczekiwania odbiorców. Im nie zależy na języku. Ma się po prostu fajnie pisać i mają być gotowe biblioteki do pierdyliona "shieldów". Zamienisz im C++ na Javę/łotewer i nawet im powieka nie mrugnie. To miałem na myśli. Natomiast: > Narzut na prosty procesor jest za duży. Mówimy o Arduino. O branży, gdzie antenka do wifi ma w sobie uC N razy silniejszy od głównego "procesora", który do tej antenki wysyła polecenia i nikogo to nie dziwi. O branży, gdzie ludziom jest wszystko jedno, czy mają AVR czy Cortex-M4, bo diodą mruga się tak samo fajnie. O branży, gdzie niektóre płytki mają Linuksa (!) udającego, że jest AVRem i też mruga diodą - i też nikogo to nie dziwi. Wsadź tam jakiś okrojony VM i nikomu nie zrobi to żadnej różnicy. Bo niby czemu? A z biegiem lat ta nisza niezauważająca różnicy będzie coraz większa. Za parę lat będziesz miał w czajniku Linuksa z Javą udającą AVRa sterującego wyłacznikiem i nikogo to nie będzie dziwiło. Że będą nisze, gdzie to się nie stanie? Oczywiście - ale tak jak na desktopach i serwerach, to będą coraz mniejsze, choć dobrze ustalone, nisze (i w tych niszach będzie też przeciwnik w postaci VHDL). > > W części "krytycznej" C++ nie wnosi niczego istotnego, bo to, co jest jego obiektywną wartością dodaną > > i tak nie obniża wymaganego wysiłku weryfikacyjnego a tego jest większość w całym cyklu życia projektu. > > To jest nieprawda. Podstawową wartością jaką wprowadza C++ jest znaczące > ułatwienie testowania i weryfikacji bez narzutu runtime. Zarówno na > etapie unit testów, jak i przy głupiej kompilacji. Testy pisze się z wymagań i nie zależy to od tego, czy program jest w C czy w C++. A kompilacja nie jest czynnością weryfikacyjną, wręcz przeciwnie - to ją trzeba weryfikować i to właśnie w C++ ten etap jest trudniejszy. (mówimy o branży krytycznej) > > To oznacza, że o ile w "normalnym" programie takie rzeczy jak RAII czy nawet sama kontrola widoczności są cenne > >, to w systemie krytycznym ich zbawczy wpływ w kontekście całego > projektu jest znacznie mniejszy. > > Zawsze możesz przedstawić przykład dlaczego mniejszy. Powyżej. Przykładowo, testy nie będą zależały od tego, w czym napiszesz kod. Być może zaoszczędzisz trochę na pokryciu strukturalnym (bo kodu będzie trochę mniej), ale dokładnie tyle samo stracisz na wykazaniu ciągłości kompilacji, bo kodu wynikowego będzie odpowiednio więcej w stosunku do źródłowego. Dlatego fakt, że C++ automatycznie zawoła jakiś tam destruktor nie oszczędza wysiłku związanego ze sprawdzeniem, czy akcja z tego destruktora się faktycznie wykonała. Ten wysiłek jest ciągle taki sam. (mówimy o branży krytycznej) Natomiast w branży rozrywkowej oczywiście C++ ma przewagę, taką samą jak na desktopie czy na serwerze. Problem w tym, że dokładnie tak samo będzie musiał zmierzyć się z Javą (lub czymś jeszcze innym - jakieś Swifty, Rusty czy co tam jest teraz modne). Dlatego rynek embedded wcale nie będzie dla C++ łatwiejszy. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2016-10-25 07:59 +0200 |
| Message-ID | <numsck$92u$1@node1.news.atman.pl> |
| In reply to | #29186 |
On 2016-10-25 00:01, Maciej Sobczak wrote: > Tak. Mam na myśli oczekiwania odbiorców. Im nie zależy na języku. To nie jest prawda. Zależy im na jakości, redukjci bugów itp. Język C tego nie zapewnia. Jezyk C++ załatwia część problemów. Java generuje nowe (jak brak deterministycznego zachowania). Czekamy na Język Ostateczny. Chwilowo brak. > Ma się po prostu fajnie pisać i mają być gotowe biblioteki do pierdyliona "shieldów". > Zamienisz im C++ na Javę/łotewer i nawet im powieka nie mrugnie. To miałem na myśli. W sumie jest to o tyle istotne że C jest gorszy od czegokolwiek. Więc być może zmiana na łotewer będzie i tak pozytywna. >> Narzut na prosty procesor jest za duży. > Mówimy o Arduino. O branży, gdzie antenka do wifi ma w sobie uC N > razy silniejszy od głównego "procesora", który do tej antenki wysyła polecenia i nikogo to nie dziwi. W srodku takiej antenki ESP8266 siedzi *mały* ARM. Dalej Java się nie zmieści (tak wiem że zmieści się na AVR ale to już nie jest Java). > O branży, gdzie ludziom jest wszystko jedno, czy mają AVR czy Cortex-M4, bo diodą mruga się tak samo fajnie. Problem w tym że na żadnym z tych CPU w przypadku deterministycznego zchowania programu, zagadnień RT itp. bedzie bardzo cieżko zmienić na Jave. Nawet do migania diodą się taka java nie nadaje. > O branży, gdzie niektóre płytki mają Linuksa (!) udającego >, że jest AVRem i też mruga diodą - i też nikogo to nie dziwi. R-Pi to nie jest do końca embedded. Istnieje jakaś mętna granica kiedy SoC staje się zwykłym komputerem. Wydaje sie że R-Pi z Linuxem jest poza ta granicą. > Wsadź tam jakiś okrojony VM i nikomu nie zrobi to żadnej różnicy. Bo niby czemu? Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie. Nie uogólniaj embedded tylko do mocy obliczeniowej. Istnieją zagadnienia któych nie da się rozwiązać większym cpu. > A z biegiem lat ta nisza niezauważająca różnicy będzie coraz większa. > Za parę lat będziesz miał w czajniku Linuksa z Javą udającą AVRa sterującego wyłacznikiem i nikogo to nie będzie dziwiło. Problem w tym że słyszałem to po raz pierwszy około roku 2000. Nie od wróżbity tylko od człowieka który znał doskonale rynek, zawodowo parał się projektowaniem i budową calkiem sporych systemow embedded. Jak każdą wrózbę można było ją sobie wsadzić w d... Świat jest pełen ARMów z obciętymi ficzerami typu M0 i jest na to od groma rynku a Javy nie sposób odpalić. I NIC nie wskazuje na zmianę w kierunku większych prędkości i mocy obliczeniowych. Embedded które to potrzebuje to jest jakaś część, ale nie dominująca. Jazelle umarło zanim ktokolwiek go użył. Za parę lat ... czyli nigdy. Zawsze będzie przestrzeń na jakieś małe cpu które mają specjalne cechy nie spotykane w duzym świecie. Jakieś 10 lat temu było pełno wróżbitów którzy mówili że "już za pare lat" CPU połaczy się z FPGA. No i się połaczył jako Zynq który ma absurdalne ceny, idiotyczne narzędzia i maluteńki rynek zbytu. Reszta wybiera zwykłe ARMy, AVRy PICe i jakoś nic nie wskazuje żeby nagle pokochali FPGA posklejane z ARMem za $x00 kiedy osobno kosztują $x. Dochodzi do absurdów kiedy chińska firma reanimowała 6502, wsadziła w otoczenie peryferiów i sprzedaje (MegaWin). Jest rynek. Powstrzymałbym się z tymi wrózbami co będzie za pare lat. Nic nie będzie, będzie po staremu. > Że będą nisze, gdzie to się nie stanie? > Oczywiście - ale tak jak na desktopach i serwerach, to będą coraz mniejsze >, choć dobrze ustalone, nisze (i w tych niszach będzie też przeciwnik w postaci VHDL). Niszą na razie jest używanie Linuxa jako bazy w mikrokontrolerach. Za kilka lat będzie miał takie same wady jak dzisiaj. >> To jest nieprawda. Podstawową wartością jaką wprowadza C++ jest znaczące >> ułatwienie testowania i weryfikacji bez narzutu runtime. Zarówno na >> etapie unit testów, jak i przy głupiej kompilacji. > Testy pisze się z wymagań i nie zależy to od tego, czy program jest w C czy w C++. Implementacja testów zalezy od tego. Implementacja testów w C jest znacznie bardziej kłopotliwa niż w C++. Pewno że mozna powiedzieć że "implementacja to szczegół". Zerknij jednak na UVM. Z tego "szczegółu" zrobiono ogromna filozofię która *coś* znacząco poprawiła w jakości. > A kompilacja nie jest czynnością weryfikacyjną, wręcz przeciwnie > - to ją trzeba weryfikować i to właśnie w C++ ten etap jest trudniejszy. > (mówimy o branży krytycznej) Branża krytyczna określa tak wiele aspektów pracy włacznie z kolorem skarpetek developera że nie ma sensu mówić o tym co w niej samodzielnie wyewoluuje. Nic, do momentu aż komitety certyfikujące nie pozwolą. Nie rozumiem jak tak hermetyczne i toksyczne środowisko ma niby być tłem dla dyskucji o ewolucji embedded. > Powyżej. Przykładowo, testy nie będą zależały od tego, w czym napiszesz kod. Będzie zależała ich implementacja. > Być może zaoszczędzisz trochę na pokryciu strukturalnym (bo kodu będzie trochę mniej) >, ale dokładnie tyle samo stracisz na wykazaniu ciągłości kompilacji >, bo kodu wynikowego będzie odpowiednio więcej w stosunku do źródłowego. Niby dlaczeog uważasz że kodu wynikowego będzie wiecej dla C++? Bedzie go dokładnie tyle ile trzeba w testach i tyle ile trzeba w produkcji. Statyczy polimorfizm to jedna z prostych metod osiągnięcia perfekcyjnej długości kodu dla produkjci i testowania. > Dlatego fakt, że C++ automatycznie zawoła jakiś tam destruktor nie oszczędza > wysiłku związanego ze sprawdzeniem, czy akcja z tego destruktora się faktycznie wykonała. Tu musisz mieć zaufanie do kompilatora lub certyfikaty dupochronne. Nie tak dawno temu pewna firma robiąca dla wojska miała w standardzie obok MISRA rowniez własne zalecenia w których było żeby nie uzywać jakiejśtam konstrukcji językowej bo kompilator popsuty, ale certyfikowany. Rozumiem że nie ufasz że destruktor się woła, tylko wkładasz wysiłek w sprawdzenie? A nie wkładasz go przypadkiem znacznie więcej kiedy musisz sprawdzić czy programista wywołał tą akcję w każdym miejscu? > Ten wysiłek jest ciągle taki sam. > (mówimy o branży krytycznej) Nie. Kiedy kompilator wykonuje swoje zadania w sposob pewny - wysiłek jest mniejszy. Mozna nie mieć zaufania do kompilatora. Trudno, co robić, można tez kopać rowy albo przeglądać wynikowy kod maszynowy co na jedno wychodzi.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2016-10-25 02:32 -0700 |
| Message-ID | <e591b543-f401-46b7-83fb-e00b5afa2f61@googlegroups.com> |
| In reply to | #29187 |
> > Tak. Mam na myśli oczekiwania odbiorców. Im nie zależy na języku. > > To nie jest prawda. Nie zależy im na języku. Zobacz ich ostatnią nowinkę, ESLOV[*]. Na stronach słowo "C++" nie pojawia się ani razu. Przypuszczam, że a) twórcy nie chcą się przywiązywać do tego wyboru, b) odbiorcom to wisi. [*] https://blog.arduino.cc/2016/09/28/eslov-is-the-amazing-new-iot-invention-kit-from-arduino/ > Zależy im na jakości, redukjci bugów itp. I właśnie dlatego (z powyższego linku): "Draw the connections between the modules on the editor, and watch your project come to life." Proste? Właśnie w taki sposób zmniejsza się okno wejścia dla C++. Jak już pisałem, branża przestawi się na generację kodu wcześniej, niż rozstrzygnie wojnę o wyższość C, C++ czy Ady. > > O branży, gdzie niektóre płytki mają Linuksa (!) udającego > >, że jest AVRem i też mruga diodą - i też nikogo to nie dziwi. > > R-Pi to nie jest do końca embedded. Nawet mi do głowy nie przyszedł. RPi jest bardziej odpowiednikiem dawniejszych Commodere 64, na których ludzie robili "automatykę domową" i inne mrugające choinki. Dzisiaj ich dzieci mają do tego samego celu R-Pi. Ja miałem na myśli raczej Intel Galileo - bo pracuje się z tym tak samo, jak z Arduino. Bierzesz swój "sketch", który przed chwilą działał na Arduino Uno, wybierasz w menu "Target board -> Galileo", wciskasz guzik "Upload" i Twoja płytka mruga diodą. Tego Linuksa na tej płytce nie widać, on pełni bardziej funkcję firmware'u i właśnie o tym pisałem - postęp w HW pozwala takie rzeczy robić a odbiorców to nie dziwi. > > Wsadź tam jakiś okrojony VM i nikomu nie zrobi to żadnej różnicy. Bo niby czemu? > > Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie. Ta nisza to może być pojedynczy procent całego rynku embedded. Może przegapiłeś, ale obecnie istnieje coś z miliard (albo dwa) urządzeń wbudowanych z Javą. Niektórzy nazywają je smartfonami. Masz w domu tony systemów embedded. Szybkość odpowiedzi na przerwanie jest istotna tylko w... no nie wiem w ilu z nich. Ta nisza oczywiście będzie istnieć, ale to będzie nisza a nie dominacja. > Problem w tym że słyszałem to po raz pierwszy około roku 2000. Właśnie od tamtego czasu wyprodukowano ten miliard (albo dwa) smartfonów z Javą. Niedawno widziałem... lustro domowe z Androidem. Pokazuje prognozę pogody, akurat wtedy, gdy się ubierasz. Fajne, nie? > Powstrzymałbym się z tymi wrózbami co będzie za pare lat. Nic nie > będzie, będzie po staremu. Ale przecież to Ty twierdziłeś, że coś się zmieni w temacie użycia C++. Zmieniłeś zdanie? :-) > > Testy pisze się z wymagań i nie zależy to od tego, czy program jest w C czy w C++. > > Implementacja testów zalezy od tego. Testy pisze się z wymagań. > Implementacja testów w C jest > znacznie bardziej kłopotliwa niż w C++. Nie. Jeżeli wymaganie mówi, że lampka ma zgasnąć, to z punktu widzenia testu, który jest pisany z tego wymagania, nie ma znaczenia, czy lampka będzie zgaszona w C przez jawne wywołanie jakiejś funkcji, czy w C++ przez destruktor jakiegoś kończącego życie obiektu jakiegoś wrappera RAII. To jest ten sam test. I to właśnie tam jest wysiłek w sprawdzeniu tego, że lampka zgaśnie. > Pewno że mozna powiedzieć że > "implementacja to szczegół". Z punktu widzenia testu tak właśnie jest. > Zerknij jednak na UVM. Nie miałem przyjemności. Z powierzchownej lektury wynika, że to jest metodologia, którę mogę sobie zdownloadować z internetu. I chyba nie dotyczy dyskusji C vs. C++ (vs. Ada (vs. Java)). > Branża krytyczna określa tak wiele aspektów pracy włacznie z kolorem > skarpetek developera Wręcz przeciwnie. Zdumiewająco mało określa. Nawet nie narzuca języka programowania. Ale stawia cele do spełnienia, które łatwiej jest spełnić w C (!), niż w C++. > Nie > rozumiem jak tak hermetyczne i toksyczne środowisko ma niby być tłem dla > dyskucji o ewolucji embedded. Bo niektóre urządzenia embedded są krytyczne? W szczególności te, w których chciałbyś pytać o czas odpowiedzi na przerwanie? [znowu o testach] > Niby dlaczego uważasz że kodu wynikowego będzie wiecej dla C++? Bedzie > go dokładnie tyle ile trzeba w testach i tyle ile trzeba w produkcji. Właśnie to mam na myśli. Kodu wynikowego będzie tyle ile trzeba, ale ponieważ kodu źródłowego będzie mniej (RAII, itd.), to w rezultacie będzie więcej kodu wynikowego *w stosunku* do źródłowego. I właśnie ten większy stosunek utrudni weryfikację. Bo w branży krytycznej musisz wykazać ciągłość metody inżynierskiej a im większy skok pomiędzy kolejnymi artefaktami w łańcuchu, tym trudniej tą ciągłość wykazać. Właśnie dlatego C++ nie jest aż tak atrakcyjny dla branży krytycznej, jak w rozrywkowej, gdzie zmniejszenie ilości kodu albo wsparcie kompilatora są oczywistą wartością dodaną i dla której tak bardzo lubimy C++. Problem w tym, że w branży krytycznej te argumenty nie działają. > Tu musisz mieć zaufanie do kompilatora lub certyfikaty dupochronne. Bingo. Doszliśmy do najciekawszego. Otóż kompilator C jest znacznie prostszy konstrukcyjnie od C++. Dlatego istnieją kwalifikowane kompilatory C, natomiast o takowym dla C++ nie słyszałem (przyjmijmy, że wybór jest mniejszy). I teraz masz wybór: 1. piszesz w C i korzystasz z kwalifikowanego kompilatora C, który oszczędza kupę wysiłku weryfikacyjnego 2. piszesz w C++ i przy braku kwalifikowanego kompilatora C++ robisz weryfikację kodu wynikowego, co kosztuje Cię kupę czasu (i pieniędzy). Którą opcję wybierasz? Szach-mat. > Rozumiem że nie ufasz że destruktor się woła, tylko wkładasz wysiłek w > sprawdzenie? Tak. Sorry, taka branża. > A nie wkładasz go przypadkiem znacznie więcej kiedy musisz > sprawdzić czy programista wywołał tą akcję w każdym miejscu? Testy są pisane z wymagań i to od nich zależy ten wysiłek. > Mozna nie mieć zaufania do kompilatora. Trudno, co robić, > można tez kopać rowy albo przeglądać wynikowy kod maszynowy co na jedno > wychodzi. Sorry, taka branża. Do wyboru jest też Java (i takie tam), w branży rozrywkowej. Prognoza pogody w lustrze, fajna sprawa. :-) -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2016-10-25 12:27 +0200 |
| Message-ID | <nunc36$f62$1@node2.news.atman.pl> |
| In reply to | #29188 |
On 2016-10-25 11:32, Maciej Sobczak wrote: > I właśnie dlatego (z powyższego linku): > "Draw the connections between the modules on the editor, and watch your project come to life." Był kiedys taki kawałek kodu o nazwie LabView. Kiedys siedziałem, koło 2000 roku, na jakiejś konferencji i prelegentowi aż piana leciała z ust kiedy wymieniał wszelakie zalety takiego rysowania algorytmiki. Nie to żeby pracował w TI, najzwyczajniejszy habilitowany bez pojecia o czym mówi jak to zazwyczaj bywa. "I juz za rok nie bedzie trzeba nic programować". Ta... Swoją drogą znam kolesia który w tym pisywał gdzieś koło 2007. Przesiadywał po kilka godzin nad projektem żeby "jakoś narysować ta pętlę". Ewentualne refaktorowanie kosztowało uszkodzenie prawego nadgarstka. Bez watpienia mamy do czynienia z przyszłościową technologią. Nastepna proszę! > Proste? Właśnie w taki sposób zmniejsza się okno wejścia dla C++. Po LabView widac że strasznie zmniejszyło od 15 lat. O jakiś pewno promil projektów. > Jak już pisałem, branża przestawi się na generację kodu wcześniej, niż rozstrzygnie wojnę o wyższość C, C++ czy Ady. No ale jakos od 15 lat się nie daje rady przestawić. Widać nie ta rzeczywistość. > Ja miałem na myśli raczej Intel Galileo - bo pracuje się z tym tak samo, jak z Arduino. Bierzesz swój "sketch" >, który przed chwilą działał na Arduino Uno, wybierasz w menu "Target board -> Galileo", wciskasz guzik "Upload" > i Twoja płytka mruga diodą. Tego Linuksa na tej płytce nie widać, on pełni bardziej funkcję firmware'u > i właśnie o tym pisałem - postęp w HW pozwala takie rzeczy robić a odbiorców to nie dziwi. I ten projekt w Arduino to w czym napisano? >> Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie. > Ta nisza to może być pojedynczy procent całego rynku embedded. IMHO wkładasz za dużo zwykłych komputerów do pojcia embedded. > Może przegapiłeś Tak, głupi jestem, to wiem. >, ale obecnie istnieje coś z miliard (albo dwa) urządzeń wbudowanych z Javą. Niektórzy nazywają je smartfonami. Dziękuję. Ale żeby sarkazm stosować to trzeba jednak umieć. > Masz w domu tony systemów embedded. Nie. Mam tony pecetów z przyczepionym LCD i baterią. Nijak nie widzę dlaczego miałbym to nazywać embedded. Czy jak do mojego peceta dokleje monitor i klawiaturę to tez bedzie embedded? > Szybkość odpowiedzi na przerwanie jest istotna tylko w... no nie wiem w ilu z nich. Bo to pecety a nie embedded o którym tu mowa. > Ta nisza oczywiście będzie istnieć, ale to będzie nisza a nie dominacja. Ta nisza będzie może niszą, ale obawiam się że sterowanie wektorowym falownikiem dalej jest nie za bardzo w zasięgu Javy na Galaxy. > Niedawno widziałem... lustro domowe z Androidem. Pokazuje prognozę pogody, akurat wtedy, gdy się ubierasz. Fajne, nie? Jak tam wstawie płytę na iTX z Atomem to będzie embedded czy blaszak? Zawieszenie peceta na ścianie to już embedded? > Ale przecież to Ty twierdziłeś, że coś się zmieni w temacie użycia C++. Zmieniłeś zdanie? :-) Twierdze że będzie ewolucja C do C++. Nic C/C++ nie zastapi na skale masową. Nie ma jak. Chwilowo ewolucjia jest blokowana, ale na szczęscie natura rozwiązuje ten problem powoli i metodycznie. >>> Testy pisze się z wymagań i nie zależy to od tego, czy program jest w C czy w C++. >> Implementacja testów zalezy od tego. > Testy pisze się z wymagań. Dalej mówisz jak typowy managier. Się pisze testy. A w czym? Doswiadczenia z Verilog/Vhdl pokazują że to jest *zasadnicze* pytanie. Decyduje o tak szerokim spektrum przyszłych problemów że nie da się go zbyć byle jaką odpowiedzią. >> Implementacja testów w C jest >> znacznie bardziej kłopotliwa niż w C++. > Nie. Jeżeli wymaganie mówi, że lampka ma zgasnąć, to z punktu widzenia testu >, który jest pisany z tego wymagania, nie ma znaczenia, czy lampka będzie zgaszona w C > przez jawne wywołanie jakiejś funkcji, czy w C++ przez destruktor jakiegoś kończącego życie obiektu jakiegoś wrappera RAII. Dalej nie rozumiesz. Jeśli lampka ma zgasnąc z C to sprawdzenie czy kod w C woła właściwą funkcję jest znacznie trudniejsze niż w C++. Dla managera to żadna różnica, dla implementatora testu to różnica *zasadnicza* która rzutuje na jakośc testowania. W skrajnym wypadku sadza się jednostę białkową która nacicka przycisk jak się zapali bo ... bo język nie pozwala na inne wykrycie. Tak, ta jednostka białkowa tez jest potrzebna, ale dopiero na końcowym etapie. > To jest ten sam test. I to właśnie tam jest wysiłek w sprawdzeniu tego, że lampka zgaśnie. Ale możesz ten wysilek zautomatyzować mniej lub bardziej. Możesz nawet wziąć książkę do teori testowania i zastanowić się jak podzielić ścieżkę testowania na piramidę gdzie na samym dole jest tak wiele testów że wymagane jest dostrzeżenie *jak* je implementować. Nie rób z siebie takiego teoretyka. Implementacja unit testowania jest na tyle złożonym problemem że nie można jej pomijąc głupim "się jakos napisze". Ludzie od Veriloga od przynajmniej 10 lat wyprówają sobie żyły żeby to robić właśnie w tym szczególe lepiej bo kazalo się że tam przynosi to wymierne korzyści. Na tyle że obecnie testowanie bazujące na tych szczegółach trzęsie rynkiem i jest wymogiem stawianym w krytycznych aplikacjach. >> "implementacja to szczegół". > Z punktu widzenia testu tak właśnie jest. No więc teoretyzujesz lub posiadasz toskyczne środowisko testowania w którym czas implementacji testu jest już na tyle długi że nie ma znaczenia jak jest stworzony. Coś jest popsute. >> Zerknij jednak na UVM. > Nie miałem przyjemności. Z powierzchownej lektury wynika, że to jest metodologia To jest *implementacja* pewnej metodologii. >, którę mogę sobie zdownloadować z internetu. I chyba nie dotyczy dyskusji C vs. C++ (vs. Ada (vs. Java)). Ależ dotyczy wszystkiego, a w szczególności dotyczy "się jakoś napisze te testy". Masz przykład (obecnie tip top światowy) że ktoś się pochylil nad tymi szczegółami i okazalo się że można znaczaco podnieść komfort i jakośc weryfikacji. Szczegóły miały znaczenie, kwestia dostrzeżenia ich z wysokich stołków managerów od słupków w PowerPoincie. >> Branża krytyczna określa tak wiele aspektów pracy włacznie z kolorem >> skarpetek developera > Wręcz przeciwnie. Zdumiewająco mało określa. Nawet nie narzuca języka programowania. Narzuca bardzo wiele. Być może rozmawiamy o róznych dziedzinach. Gdybyś poszedł w kierunku latania z fpga ilość rzeczy organizacyjno-implementacyjnych które musisz spelnić aby w ogole rozmawiać jest zastanawiająca i dotycza może nie koloru skarpetek ale niewiele brakuje. > Ale stawia cele do spełnienia, które łatwiej jest spełnić w C (!), niż w C++. To nie może być prawda z racji że C jest w uproszczeniu podzbiorem C++. To nie jest trywializm. To tylko oznacza że możesz z C++ wziąć to co w danej chwili wyraża lepiej rozwiązanie problemu. > Bo niektóre urządzenia embedded są krytyczne? > W szczególności te, w których chciałbyś pytać o czas odpowiedzi na przerwanie? Czyli te na Javie z VM popędzane z Linuxem? Czy własnie rozmawiam z druga osobowością? > [znowu o testach] >> Niby dlaczego uważasz że kodu wynikowego będzie wiecej dla C++? Bedzie >> go dokładnie tyle ile trzeba w testach i tyle ile trzeba w produkcji. > Właśnie to mam na myśli. Kodu wynikowego będzie tyle ile trzeba >, ale ponieważ kodu źródłowego będzie mniej (RAII, itd.), > to w rezultacie będzie więcej kodu wynikowego *w stosunku* do źródłowego. Podstawową zasadą przy redukcji bugow jest trzymanie się jak najmniejszej ilości kodu źrodlowego i jak najczytelniejszego wyrażania zamiarów. Ponieważ w ten sposób programista popełnia mniej błedów. Język C musi być wspomagany przez makra, język C++ pozwala na wyrażanie wprost w mniejszei ilości kodu. > I właśnie ten większy stosunek utrudni weryfikację Nieprawda. Weryfikację utrudnia cieżki do czytania kod, kłopotliwe implementowanie testów i kiepski związek kodu (rysowanie z LabView) z wynikiem (generowany C). Pierwsze słyszę żeby 20MB kodu wynikowego więcej z powodu życia templates mialo byc przeszkodą weryfikacyjną i traktowane jako miara jakości. Po stronie kodu jest 10x mniej czytania i 10x czytelniej i 3x mniej unit testów. >. Bo w branży krytycznej musisz wykazać ciągłość metody inżynierskiej Pomiędzy jednym a drugim masz kompilator. Możesz wygazać formalnie jego działanie? FORMALNIE. Jesli nie to musisz za każdym razem sprawdzać kod w C z kodem w asm. Ręcznie. No chyba że oszukujesz i te wszystkie nadęte pojęcia o ciągłości są po prostu ponaginane że aż trzeszczy i podparte zbutwiałymi certyfikatami? > a im większy skok pomiędzy kolejnymi artefaktami w łańcuchu, tym trudniej tą ciągłość wykazać. Ale jak ją wykazujesz? Pomiędzy A i B użylismy kompilatora X? No no. Robi wrażenie. Na managerach. > Problem w tym, że w branży krytycznej te argumenty nie działają. Z powodu biologi i komitetów certyfikujących a nie rozsądku. > Bingo. Doszliśmy do najciekawszego. > Otóż kompilator C jest znacznie prostszy konstrukcyjnie od C++. > Dlatego istnieją kwalifikowane kompilatory C Już Ci napisałem jak duży producent pisal w certyfikowanym kompilatorze C z wielką dziurą. Zaznaczam przy okazji że w tym czasie kiedy oni w nim pisali gcc osiągał lepsza jakość kodu wynikowego i nie miał bugów. I nie oznacza to że należy wziąć gcc. Oznacza to że certyfikowany kompilator okazał się polem minowym. "Jakoś(ć) przez certyfikację". >, natomiast o takowym dla C++ nie słyszałem (przyjmijmy, że wybór jest mniejszy). I teraz masz wybór: > 1. piszesz w C i korzystasz z kwalifikowanego kompilatora C, który oszczędza kupę wysiłku weryfikacyjnego Nie oszczędzę. Bugi pochodzace z kompilatorów to promil promila problemu bugow w ogólności. > 2. piszesz w C++ i przy braku kwalifikowanego kompilatora C++ > robisz weryfikację kodu wynikowego, co kosztuje Cię kupę czasu (i pieniędzy). > Którą opcję wybierasz? Taką w ktorej jestem w stanie szybciej wykryć bugi w kodzie. C jest drugi a C++ przedostatni. > Szach-mat. To nie jest szach mat. Piszesz o embedded tak jak Ci w danej chwili pasuje. Raz to wypasione systemy z Linuxem i Java a po chwili certyfikowane produkty wczesnej archeologii inzynieri programowania w której ludzie rysują kreski od kodu w C do kodu w asm. Nie masz certyfikowanej ciąglości wypowiedzi ... >> Rozumiem że nie ufasz że destruktor się woła, tylko wkładasz wysiłek w >> sprawdzenie? > Tak. Sorry, taka branża. Ten promil embedded czy te miliardy smartfonów? Udowadnianie że c++ nie ma co szukać w embedded z pomocą hermetycznego promila aplikacji embedded obwarowanymi certyfikatami i komitetami wydaje mi się, przyznaje, zabawny, dlatego to ciągne dalej. A przy okazji jesli chodzi o Pascala ...
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2016-10-25 07:10 -0700 |
| Message-ID | <756034dd-ddb3-4a4e-8a0f-ad7f33acd36b@googlegroups.com> |
| In reply to | #29189 |
On Tuesday, October 25, 2016 at 12:27:51 PM UTC+2, Sebastian Biały wrote: > > I właśnie dlatego (z powyższego linku): > > "Draw the connections between the modules on the editor, and watch your project come to life." > > Był kiedys taki kawałek kodu o nazwie LabView. Sam napisałeś, że obecni amatorzy od Arduino to przyszli inżynierowie w firmach embedded. Pokazuję Ci, co ci amatorzy teraz robią. Zgadnij, co będą robić za parę lat. Pisać szablony w C++? > > Proste? Właśnie w taki sposób zmniejsza się okno wejścia dla C++. > > Po LabView widac Po ESLOV widać, że tak rośnie nowe pokolenie inżynierów. > No ale jakos od 15 lat się nie daje rady przestawić. Kolega obok twierdził, że "większość" softu w samochodach się robi w Simulinku. Trochę przesadził z tą większością, ale i tak to są rysy na Twoich argumentach. To się dzieje, niezależnie od tego, czy Ci się to podoba. > >> Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie. > > Ta nisza to może być pojedynczy procent całego rynku embedded. > > IMHO wkładasz za dużo zwykłych komputerów do pojcia embedded. Niedawno powstało takie pojęcie jak "deeply embedded", bo niektórzy nie mogą się pogodzić z postępem w hardwarze. Podsumujmy: piekarnik/pralka/zmywarka sterowana mikrokontrolerem 8051 to jest system embedded. Jeśli w następnej wersji piekarnika/pralki/zmywarki tego samego producenta będzie mały komputerek z Linuksem, to to już nie jest embedded. Dlaczego? Bo specjaliści od embedded mają naruszone ego? No to sorry. > Nie. Mam tony pecetów z przyczepionym LCD i baterią. Nijak nie widzę > dlaczego miałbym to nazywać embedded. https://en.wikipedia.org/wiki/Embedded_system > Czy jak do mojego peceta dokleje > monitor i klawiaturę to tez bedzie embedded? To zależy, czy będzie częścią większego produktu. Jeśli ten monitor i klawiatura są akurat na frontowym panelu w samochodzie, to tak, ten pecet jest systemem embedded. Sorry. Nie ja wymyśliłem definicję. > Ta nisza będzie może niszą, ale obawiam się że sterowanie wektorowym > falownikiem dalej jest nie za bardzo w zasięgu Javy na Galaxy. Cieszę się, że znalazłeś sobie ciekawą i niezagrożoną niszę zawodową. > > Testy pisze się z wymagań. > > Dalej mówisz jak typowy managier. Nie, jestem inżynierem. > Się pisze testy. A w czym? Skup się: w Excelu. (oczywiście nie jest to jedyna opcja, ale o tyle ciekawa, że kompletnie oderwana od dyskusji nt. wyższości C++ nad C) > Dalej nie rozumiesz. Jeśli lampka ma zgasnąc z C to sprawdzenie czy kod > w C woła właściwą funkcję jest znacznie trudniejsze niż w C++. Dalej nie rozumiesz. Jeśli lampka ma zgasnąć, to w jakiejś chwili na jakimś outpucie ma być LOW (powiedzmy). Albo jakaś zmienna lub wartość w jakieś tablicy albo strukturze ma być LOW. Itp. Zrobienie testu na takie coś nie zależy od tego, czy ustawianie tej wartości jest w C czy w C++. W szczególności, uwaga, test można zrobić *zanim* powstanie ten kod i tym bardziej wtedy widać, że robienie testu nie zależy od tego, czy gaszenie lampki jest w C, czy w C++. (Proszę nie mylić z TDD (Test-Driven Development), bo to nie to.) [branża krytyczna] > Narzuca bardzo wiele. Na przykład? > > Ale stawia cele do spełnienia, które łatwiej jest spełnić w C (!), niż w C++. > > To nie może być prawda z racji że C jest w uproszczeniu podzbiorem C++. Błąd logiczny. Właśnie dlatego jest łatwiej w C, że C jest (w uproszczeniu) podzbiorem C++. Dzięki temu ilość różnych rzeczy do sprawdzenia w kodzie jest mniejsza (sic!). > > Bo niektóre urządzenia embedded są krytyczne? > > W szczególności te, w których chciałbyś pytać o czas odpowiedzi na przerwanie? > > Czyli te na Javie z VM popędzane z Linuxem? Czy własnie rozmawiam z > druga osobowością? Uzupełniam: Jeżeli w danym systemie embedded nie interesujesz się czasem odpowiedzi na przerwanie, to prawdopodobnie jest to system rozrywkowy, np. lustro z Andoridem z prognozą pogody. Natomiast jeżeli jesteś zainteresowany tym czasem, to prawdopodobnie jest to system krytyczny a wtedy chcesz mieć jak najłatwiejsze narzędzia weryfikacji. > > I właśnie ten większy stosunek utrudni weryfikację > > Nieprawda. Weryfikację utrudnia cieżki do czytania kod, Więc pisz kod łatwy do czytania. Standardy kodowania po to są. > kłopotliwe > implementowanie testów Testy pisze się z wymagań. N-ty raz to powtarzam. > i kiepski związek kodu (rysowanie z LabView) z > wynikiem (generowany C). Bingo. Dlatego C++ jest trudniejszy w weryfikacji, niż C, bo w C++ jest większy przeskok między kodem (źródłowym) a wynikiem (obiektowym). > Pierwsze słyszę żeby 20MB kodu wynikowego więcej z powodu życia > templates mialo byc przeszkodą weryfikacyjną To jest tzw. total showstopper a nie przeszkoda. > Po stronie kodu jest 10x mniej Zaraz, zaraz. Powyżej napisałeś, że kodu jest 20MB więcej, teraz piszesz, że kodu jest 10x mniej. Gubisz się? Jeżeli w Twoim projekcie zrobiło się 10x mniej kodu źródłowego a jednocześnie przybyło 20MB kodu wynikowego, to leżysz na weryfikacji. Hasło: traceability. > >. Bo w branży krytycznej musisz wykazać ciągłość metody inżynierskiej > > Pomiędzy jednym a drugim masz kompilator. To jest nieciągłość. > Możesz wygazać formalnie jego > działanie? Jeżeli to jest kompilator C++, to nie da się tego zrobić jeszcze bardziej, niż nie da się gdy to jest kompilator w C. Właśnie dlatego lepiej, żeby był C. > Jesli nie to musisz za każdym razem sprawdzać kod > w C z kodem w asm. Ręcznie. Tak. Sorry, taka branża. Dlatego łatwiej się to robi gdy kod źródłowy jest w C. Naprawdę. > Już Ci napisałem jak duży producent pisal w certyfikowanym kompilatorze > C z wielką dziurą. Nie ma problemu - certyfikował tą resztę wokół dziury. > Zaznaczam przy okazji że w tym czasie kiedy oni w nim > pisali gcc osiągał lepsza jakość kodu wynikowego i nie miał bugów. Bzdura. Bugzilla pokazuje, że w historii gcc nigdy nie było takiego przedziału czasu, żeby nie było bugów. Różnica jest taka, że w przypadku tego certyfikowanego wiedza o tym gdzie są bugi (i jak trzeba pisać, żeby je ominąć) była większa. Dlatego ten certyfikowany był bardziej odpowiedni w projekcie krytycznym. > Bugi pochodzace z kompilatorów to promil promila problemu > bugow w ogólności. W branży rozrywkowej? Oczywiście. Ale pisaliśmy o krytycznej. > Piszesz o embedded tak jak Ci w danej chwili > pasuje. Raz to wypasione systemy z Linuxem i Java a po chwili > certyfikowane produkty Ty sam ten temat szeroko traktujesz. Raz o Arduino, drugi raz o falownikach... Próbuję odpisywać wg bieżącego, zmiennego kontekstu. > Udowadnianie że c++ nie ma co szukać w embedded z pomocą hermetycznego > promila aplikacji embedded obwarowanymi certyfikatami i komitetami > wydaje mi się, przyznaje, zabawny, dlatego to ciągne dalej. Ale ja nie pisałem tylko o promilu certyfikowanych. Również o tej gigantycznej masie rozrywkowych, z Javą w środku. Pytanie teraz, czy pomiędzy tymi dwoma kategoriami jest wystarczająco dużo miejsca. Pewnie jest, ale nie na tyle, żeby można było pisać o niezastąpionym C++, którego nic nie wyprze. Właśnie wypiera (albo nie dopuszcza), z obu tych stron. W branży embedded C++ jest w podobnym ścisku i pod podobną presją konkurencji, jak na desktopie, z podobnych powodów. > A przy > okazji jesli chodzi o Pascala ... Nie widziałem w embedded. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2016-10-25 17:30 +0200 |
| Message-ID | <nuntrj$d1q$1@node1.news.atman.pl> |
| In reply to | #29190 |
On 2016-10-25 16:10, Maciej Sobczak wrote: >>> I właśnie dlatego (z powyższego linku): >>> "Draw the connections between the modules on the editor, and watch your project come to life." >> Był kiedys taki kawałek kodu o nazwie LabView. > Sam napisałeś, że obecni amatorzy od Arduino to przyszli inżynierowie w firmach embedded. > Pokazuję Ci, co ci amatorzy teraz robią. Adruino. Takiego ruchu amatorow na rynku uC nie było nigdy. > Zgadnij, co będą robić za parę lat. Pisać szablony w C++? No. Mniej więcej. Moze nawet mniej bo biologia nie jest aż tak okrutna. >>> Proste? Właśnie w taki sposób zmniejsza się okno wejścia dla C++. >> Po LabView widac > Po ESLOV widać, że tak rośnie nowe pokolenie inżynierów. No, to widać po obu. Moving on. >> No ale jakos od 15 lat się nie daje rady przestawić. > Kolega obok twierdził, że "większość" softu w samochodach się robi w Simulinku. > Trochę przesadził z tą większością, ale i tak to są rysy na Twoich argumentach. > To się dzieje, niezależnie od tego, czy Ci się to podoba. Alez niech się dzieje. Tylko nic z tego nie wynika. LV nie dał rady zdominować nawet procenta rynku. Złosliwi twierdzą że jak by sprzedawali hardware za 1/10 ceny to może. Jestem pewny że co kilka lat ktoś musi przeprowadzić nastepną kompletną rewolucję na rynku embedded po której zostanie jak zwykle tylko troche rozrzuconych papierków po miętówkach na sali konferencyjnej. Moving on. >>>> Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie. >>> Ta nisza to może być pojedynczy procent całego rynku embedded. >> IMHO wkładasz za dużo zwykłych komputerów do pojcia embedded. > Niedawno powstało takie pojęcie jak "deeply embedded", bo niektórzy nie mogą się pogodzić z postępem w hardwarze. Ale to nie jest postęp że masz coraz szybsze procesory *wszedzie* bo w ogromnej i ignorowanej przez Ciebie części procesory nie zmieniają prędkości na wieksze. Ba, odchudzają się z ficzerów, zmienia rdzenie na urposzczone, dodaje hardware pozwalające zrobić coś sprzetowo itd. Takie do migania diodą i sterowania silnikiem pralki. Przypuszczalnie ten rynek to kilka rzedów więcej niż sterowników czarnych skrzynek w samolotach które uważasz za istotny w tej dyskusji (a ja komiczny). > Podsumujmy: piekarnik/pralka/zmywarka sterowana mikrokontrolerem 8051 to jest system embedded. > Jeśli w następnej wersji piekarnika/pralki/zmywarki tego samego producenta będzie > mały komputerek z Linuksem, to to już nie jest embedded. Dlaczego? Bo specjaliści od > embedded mają naruszone ego? No to sorry. Pokaż gdzie jest granica. Używanie hasła embedded do wszystkiego traci sens tej rozmowy. Smartfony to już jest wszystko, bo po drugiej stronie siedzi AtTiny13 i nijak nie ma tutaj zadnej analogii czegokolwiek a w/g Ciebie to jest wszystko embedded. Oczekuje że mój laptop jak tylko go podniosę można nazwac smartfonem a mój pecet po wsadzeniu akku i monitore na taśmie to będzie laptopem. >> Nie. Mam tony pecetów z przyczepionym LCD i baterią. Nijak nie widzę >> dlaczego miałbym to nazywać embedded. > https://en.wikipedia.org/wiki/Embedded_system I to lusterko ze smarfonem spełnia tą definicje? Smarfon spełnia tą definicję? >> Czy jak do mojego peceta dokleje >> monitor i klawiaturę to tez bedzie embedded? > To zależy, czy będzie częścią większego produktu. Jak dokleje jeszcze lusterko to już będzie embedded? A jak takie duże to już? A jak za tym lusterkime będzie monitor to już? > Jeśli ten monitor i klawiatura są akurat na frontowym panelu w samochodzie >, to tak, ten pecet jest systemem embedded. Sorry. Nie ja wymyśliłem definicję. To nie jest kwesia czy w samochdozie masz embeddeed tylko czy te miliardy telefonów z java są embedded czy są mniejszymi pecetami? A może nie ma róznicy i powinniśmy tą rozmowę nie prowadzić o embedded tylko o mikrokontolerach? To zaraz przyjdzie jakiś misio i zacznie gadać o tym że SoC to taki uC tylko większy itd itp. Wyciągasz sobie z embedded dośc szeroki zakres hardware i rzucasz nim tu i tam jak wygodniej. OK, trudno, co robić. Głuopia definicja to i głupie trolowanie. >> Ta nisza będzie może niszą, ale obawiam się że sterowanie wektorowym >> falownikiem dalej jest nie za bardzo w zasięgu Javy na Galaxy. > Cieszę się, że znalazłeś sobie ciekawą i niezagrożoną niszę zawodową. Ich jest całkiem sporo. O dziwo nie pracuje zawodowo jako programista embedded. >> Się pisze testy. A w czym? > Skup się: w Excelu. > (oczywiście nie jest to jedyna opcja, ale o tyle ciekawa, że kompletnie oderwana od dyskusji nt. wyższości C++ nad C) Interesujące. A w czym sie je implementuje? Zapewne to już nie jest istotne? A może masz na mysli systemy kontroli specyfikacji i testowania które z *faktycznym* testowaniem mają tyle wspólnego co referencja z bazy danych? >> Dalej nie rozumiesz. Jeśli lampka ma zgasnąc z C to sprawdzenie czy kod >> w C woła właściwą funkcję jest znacznie trudniejsze niż w C++. > Dalej nie rozumiesz. Jeśli lampka ma zgasnąć, to w jakiejś chwili na jakimś outpucie ma być LOW (powiedzmy). > Albo jakaś zmienna lub wartość w jakieś tablicy albo strukturze ma być LOW. Itp. > Zrobienie testu na takie coś nie zależy od tego, czy ustawianie tej wartości jest w C czy w C++. Zależy. W końcu ktoś kiedyś fizycznie musi to coś odczytać z przestrzeni w której działa C/C++. > W szczególności, uwaga, test można zrobić *zanim* powstanie ten kod Nie uzywaj aż takich oczywistości. > i tym bardziej wtedy widać, że robienie testu nie zależy od tego, czy gaszenie lampki jest w C, czy w C++. Dalej nie wyjasnileś jak ten test czyta ten LOW. To jest *istotne* i gdy zrozumiesz dlaczego UVM trzęsie światem FPGA zrozumiesz rownież dlaczego jest istotne *jak* się tam implementuje testy i dlaczego 10 lat trwało dojście do tego. Tak, w aplikacjach krytycznych też. >> Narzuca bardzo wiele. > Na przykład? Na przykład metodykę testowania od dupereli jak raporty, przez sledzenie specyfikacji po precyzyjne informacje jak testować na poziomie implementacji pojedynczych machnięć drutami. >>> Ale stawia cele do spełnienia, które łatwiej jest spełnić w C (!), niż w C++. >> To nie może być prawda z racji że C jest w uproszczeniu podzbiorem C++. > Błąd logiczny. Właśnie dlatego jest łatwiej w C, że C jest (w uproszczeniu) podzbiorem C++. > Dzięki temu ilość różnych rzeczy do sprawdzenia w kodzie jest mniejsza (sic!). Nie, ponieważ w C emulujesz zachowania ktore w C++ masz OOTB. Na tym polega róznica. Na tym że legacy programmers w C *emulują* zachowania C++ jak RAII. I to *trzeba* testować intensywniej niż wypociny kompilatora. Bo wypociny jednostek białkowych są z definicji popsute *bardziej* niż wypociny kompilatora. >>> Bo niektóre urządzenia embedded są krytyczne? >>> W szczególności te, w których chciałbyś pytać o czas odpowiedzi na przerwanie? >> Czyli te na Javie z VM popędzane z Linuxem? Czy własnie rozmawiam z >> druga osobowością? > Uzupełniam: > Jeżeli w danym systemie embedded nie interesujesz się czasem odpowiedzi na przerwanie >, to prawdopodobnie jest to system rozrywkowy, np. lustro z Andoridem z prognozą pogody. Interesujące. Przecietny DMA w byleczym wymaga krytycznego czasu odpowiedzi na przerwanie. Od mówiącej chińskiej lalki po sterownik dysku w klastrze. DMA jest wszedzie poza 8051 i AVR. I wszedzie masz zagadnienie RT. Oczywiście zawsze można ściemniać że zajmie się tym VM Javy a kod za to odpowiedzialny piszą krasnoludki. > Natomiast jeżeli jesteś zainteresowany tym czasem, to prawdopodobnie jest to system > krytyczny a wtedy chcesz mieć jak najłatwiejsze narzędzia weryfikacji. Najłatwiejsze narzedzia weryfikacji do C nie istnieją. To nie ten język. C++ też nie. Był kiedyś taki język e przeznaczony tylko do testowania o świetlanej przyszłości. Niewiele można na ten temat znaleźć bo to raczej radosna twórczość hindusów. Całkowicie poświęcony byciem abstrakcyjnym względem implementacji i języka ktory testuje. Obecnie można książkami na jego temat palić w kominku a i to krótko bo była jedna i chyba tyle. Ale za to ile szumu, konferencji i posterów! >>> I właśnie ten większy stosunek utrudni weryfikację >> Nieprawda. Weryfikację utrudnia cieżki do czytania kod, > Więc pisz kod łatwy do czytania. Standardy kodowania po to są. Standard kodowania nie czyni kodu latwiejszym w czytaniu na poziomie algorytmiki. Cieżko popelnić bład jedną spacją za dużo więc standardy kodowania w niewielkim stopniu wpływają na generację błedów przez programiste. Wpływa czytelność a więc rozumienie co autor mial na myśli. W typowych wypocinach embedded zazwyczaj oznacza to przeczesanie sześciu makr do emulacji RAII zmielone z #define na przemian z #include do emulacji template. >> kłopotliwe >> implementowanie testów > Testy pisze się z wymagań. N-ty raz to powtarzam. Jak typowy menager: piszcie tak zeby było dobrze. >> i kiepski związek kodu (rysowanie z LabView) z >> wynikiem (generowany C). > Bingo. Dlatego C++ jest trudniejszy w weryfikacji, niż C >, bo w C++ jest większy przeskok między kodem (źródłowym) a wynikiem (obiektowym). Ide o zakład że nie weryfikujesz tego związku żadnym narzedziem i to tylko puste hasła. W przypadku językow HDL taka weryfikacja zazwyczaj oznacza wykonanie tych samych czynności na dwóch symulatorach roznych producentów i komapracje wyników. I to wcale nie oznacza że choć jeden jest dobry. To nic nie oznacza. Podnosi tylko jakość snu zespołu. Przeciętny projekt fpga jest na tyle skomplikowany że nie da się go zweryfikować dowolną metodą jaką znamy. Zakłada się pewien % jakości i tyle. >> Pierwsze słyszę żeby 20MB kodu wynikowego więcej z powodu życia >> templates mialo byc przeszkodą weryfikacyjną > To jest tzw. total showstopper a nie przeszkoda. Serio? A niby jak? Masz swój embedded z 2GB flash. program zajmuje po kompilacji z 400MB. Każdy bajt Twoj zespół dronów sprawdził, czy zgadza się z kodem źrodłowym. Teraz masz +20MB więcej. To przeciez tylko kilkaset lat więcej sprawdzania bajt po bajcie. W czym widzisz problem? >> Po stronie kodu jest 10x mniej > Zaraz, zaraz. Powyżej napisałeś, że kodu jest 20MB więcej, teraz piszesz, że kodu jest 10x mniej. Gubisz się? Kodu źródlowego mniej, kodu wynikowego więcej. Co poradze na to że to kod i tamto kod? > Jeżeli w Twoim projekcie zrobiło się 10x mniej kodu źródłowego a jednocześnie przybyło 20MB kodu wynikowego, to leżysz na weryfikacji. > Hasło: traceability. Puste. Dotyczy ono kodu źródlowego. Nie wynikowego. Zaznacze też że w przypadku *ogromnych* projektów FPGA korzysta się rownież z certyfikaowanych syntezerów i symulatorów. Naprawde myslisz że ktokolwiek jak przybijał pieczatkę to mial pewnośc że takowy działa poprawnie? Tego nawet w pojedynczym promilu nie da się stwierdzić. Przechodza jakiś tam zestaw testów. Przejscie wszystkich ściezek jest niemożliwe fizycznie. Ufa się na jakiś procent. Sorry, tak działa świat. I co ważne: tam "kod wynikowy" to z grubsza sieć bramek. Każda synteza robi ją inaczej. Powiedzmy że dostajesz milion bramek i dwa miliony drutów. Drukujesz to na płachcie wielkości boiska i armia ludzi z lupami ropoczyna proces weryfikacji. Tak, naprawdę. Zupełnie jak inni bajt po bajcie oglądaja assembler po każdej kompilacji. >>> . Bo w branży krytycznej musisz wykazać ciągłość metody inżynierskiej >> Pomiędzy jednym a drugim masz kompilator. > To jest nieciągłość. Więc jak rozumiem kompilujesz na kartce (notatnikowi tez bym nie ufał!). >> Możesz wygazać formalnie jego >> działanie? > Jeżeli to jest kompilator C++, to nie da się tego zrobić jeszcze bardziej, niż nie da się gdy to jest kompilator w C. Ale możesz dla swojego? Ktoś to wykazał? Czy tylko ma pieczatkę? > Właśnie dlatego lepiej, żeby był C. Żadna roznica. I jeden i drugi nie jest mozliwy do weryfikacji. Bazujesz na kompilatorze z pieczatką i tyle. Polepsza może to jakośc snu i pozwala osiągnąc pewien poziom dupoochrony. Nie ma żadnej magicznej ciągłosci na którą się powołujesz. >> Jesli nie to musisz za każdym razem sprawdzać kod >> w C z kodem w asm. Ręcznie. > Tak. Sorry, taka branża. Współczuje. Sprawdź czy nie czeka cie przyszlośc w kopaniu rowów. Z prostej przyczyny: nie robicie tego. Ewentualnie robicie to w projektach z gatunku miganie diodą gdzie to jest fizycznie możliwe. > Dlatego łatwiej się to robi gdy kod źródłowy jest w C. > Naprawdę. Nie robicie tego lub robicie pierdołowate aplikacyjki. Tego nie da się zrobić albo można mówić że się robi a oszukiwać (np. weryfikowac kawałek i twierdzić bez podstaw że inne kawałki tego nie psują jak się zmienia kod). >> Już Ci napisałem jak duży producent pisal w certyfikowanym kompilatorze >> C z wielką dziurą. > Nie ma problemu - certyfikował tą resztę wokół dziury. Nie. Dziurę wykryto po certyfikacji. Bo tak ta certyfikacja wygląda. Ziutek, na oko działa, przyp... pieczatkę, niech se zarobią. To na oko to tysiące testów testujących może max kilka procent interakcji w kompilatorze. Tylko testów tych testów nie ma. I ich testów. Moment w którym mozna jeszcze bylo formalnie weryfikować kompilatory czegokolwiek to chyba okolice lat 80tych. Natomiast chyba można ciągle assemblery. Czy chciałbys może wyciągnąc z tego wniosek że pisanie w asseblerze jest obaczone mniejszą iloscią błedów niż w C? >> Zaznaczam przy okazji że w tym czasie kiedy oni w nim >> pisali gcc osiągał lepsza jakość kodu wynikowego i nie miał bugów. > Bzdura. Bugzilla pokazuje, że w historii gcc nigdy nie było takiego przedziału czasu, żeby nie było bugów. Zapomniałem dopisać: nie miał takich bugów. Chyba nie zakładasz że jestem aż takim idiotą, co? >> Bugi pochodzace z kompilatorów to promil promila problemu >> bugow w ogólności. > W branży rozrywkowej? Oczywiście. W każdej. Od bardzo dawna. Już mineły lata 80te. Całkiem przyzwoite kompilatory mamy. >> Piszesz o embedded tak jak Ci w danej chwili >> pasuje. Raz to wypasione systemy z Linuxem i Java a po chwili >> certyfikowane produkty > Ty sam ten temat szeroko traktujesz. Raz o Arduino, drugi raz o falownikach... Próbuję odpisywać wg bieżącego, zmiennego kontekstu. Akuratnie falowniki i Atmega leża mniej więcej w tej samej przegródce. Sam mam jeden na Atmega. >> Udowadnianie że c++ nie ma co szukać w embedded z pomocą hermetycznego >> promila aplikacji embedded obwarowanymi certyfikatami i komitetami >> wydaje mi się, przyznaje, zabawny, dlatego to ciągne dalej. > Ale ja nie pisałem tylko o promilu certyfikowanych. Również o tej gigantycznej masie rozrywkowych, z Javą w środku. Wiec po co argumenty z jednej strony przenosić na drugą? Czy któś uzywa certyfikowanych kompialtorów do Javy? A może uzywa GC w apliakcja RT w samolocie? Może i to embedded i tamto embedded ale przeciez to zupełnie inne embedded! > Pytanie teraz, czy pomiędzy tymi dwoma kategoriami jest wystarczająco dużo miejsca. > Pewnie jest, ale nie na tyle, żeby można było pisać o niezastąpionym C++ Ależ tam jest od groma miejsca. Widzisz świat z wlasnego krzesła. Troche ruchu w lewo, w prawo. ARMy przejęły rynek, w wersjach miniaturowych. Tam jest w cholere miejsca nawet na zombie 6502. jak wymyslisz za chwile coś z rdzeniem AVR i ze 100 makrokomórkami to rynek wessa bez zająknięcia. >, którego nic nie wyprze. Właśnie wypiera (albo nie dopuszcza), z obu tych stron. Tak, od 15 lat. > W branży embedded C++ jest w podobnym ścisku i pod podobną presją konkurencji, jak na desktopie, z podobnych powodów. Tak na desktopie od 30 lat. Tu wróżbitów było więcej. Co roku coś nowego jest rewolucją. Bitów szkoda. >> A przy >> okazji jesli chodzi o Pascala ... > Nie widziałem w embedded. Był. Niestety nie pomnę jaki, ale był. Autor twierdził że nic lepszego na uC nie wymyślono. Zapamiętałem to bo wtedy łatwiej poznać.
[toc] | [prev] | [next] | [standalone]
| From | "re" <re@re.invalid> |
|---|---|
| Date | 2016-10-25 18:12 +0200 |
| Message-ID | <nuo09b$2hl$1@mx1.internetia.pl> |
| In reply to | #29192 |
Użytkownik "Sebastian Biały" ... >> Ta nisza będzie może niszą, ale obawiam się że sterowanie wektorowym >> falownikiem dalej jest nie za bardzo w zasięgu Javy na Galaxy. > Cieszę się, że znalazłeś sobie ciekawą i niezagrożoną niszę zawodową. Ich jest całkiem sporo. O dziwo nie pracuje zawodowo jako programista embedded. --- Może napisz gdzie pracujesz i jako kto to będziemy wiedzieli gdzie nie iść ;-)
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2016-10-25 18:18 +0200 |
| Message-ID | <nuo0lb$fmb$1@node1.news.atman.pl> |
| In reply to | #29196 |
On 2016-10-25 18:12, re wrote: > Może napisz gdzie pracujesz i jako kto to będziemy wiedzieli gdzie nie > iść ;-) Jesli spojrzysz na to z drugiej strony to może sie okazać że to nawet lepiej że nie przyjdziesz.
[toc] | [prev] | [next] | [standalone]
| From | "re" <re@re.invalid> |
|---|---|
| Date | 2016-10-25 17:39 +0200 |
| Message-ID | <nunucj$qss$1@mx1.internetia.pl> |
| In reply to | #29190 |
Użytkownik "Maciej Sobczak" ... > A przy > okazji jesli chodzi o Pascala ... Nie widziałem w embedded. --- Czemu właściwie dyskutujesz ? Zobacz na temat. Ktoś podał tutaj środowisko komercyjne do programowania 8051 itp w Pascalu.
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2016-10-25 18:21 +0200 |
| Message-ID | <nuo0s3$fmb$2@node1.news.atman.pl> |
| In reply to | #29194 |
On 2016-10-25 17:39, re wrote: > środowisko komercyjne do programowania 8051 itp w Pascalu. Triple oxymoron! Gratuluje[my]!
[toc] | [prev] | [next] | [standalone]
| From | Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> |
|---|---|
| Date | 2016-10-26 07:59 +0200 |
| Message-ID | <58104655$0$15202$65785112@news.neostrada.pl> |
| In reply to | #29190 |
W dniu 2016-10-25 16:10, Maciej Sobczak pisze: > Niedawno powstało takie pojęcie jak "deeply embedded", bo niektórzy > nie mogą się pogodzić z postępem w hardwarze. Podsumujmy: > piekarnik/pralka/zmywarka sterowana mikrokontrolerem 8051 to jest > system embedded. Jeśli w następnej wersji piekarnika/pralki/zmywarki > tego samego producenta będzie mały komputerek z Linuksem, to to już > nie jest embedded. Dlaczego? Bo specjaliści od embedded mają > naruszone ego? No to sorry. Nie przesadzałbym, tu nie chodzi o ego... W firmie w której pracuje mamy takie urządzenie zaprojektowane jako jedno z pierwszych po powstaniu firmy, po małych modyfikacjach cały czas produkowane. Pierwszym systemem był oczywiście okrojony linux, bo można było to zrobić szybko i oprogramować i w wielu wypadkach takie coś wystarcza, jednak są miejsca, gdzie stworzony musiał być inny system i powstał w międzyczasie. Tak więc (pomijając inne problemy), sam start samego linuksa na tym sterowniku to ok pół minuty + start programu, który ma działać na tym urządzeniu. Nowy system, to samo urządzenie, system + program - czas startu 4 sekundy. Więc jeśli sterownik pracuje jako komunikacyjny, czy steruje urządzeniami, gdzie nie zależy nam na natychmiastowej reakcji (np sterowanie oświetleniem), tam spokojnie można użyć linuksa, jednak, tam gdzie chodzi o bezpieczeństwo, czas reakcji musi byc przewidywalny, tam linux się po prostu nie sprawdza. -- Kaczus http://kaczus.ppa.pl
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2016-10-26 00:07 -0700 |
| Message-ID | <ec1aa4a7-dd8f-4a46-8bd7-7f75baedc457@googlegroups.com> |
| In reply to | #29200 |
> > Podsumujmy: > > piekarnik/pralka/zmywarka sterowana mikrokontrolerem 8051 to jest > > system embedded. Jeśli w następnej wersji piekarnika/pralki/zmywarki > > tego samego producenta będzie mały komputerek z Linuksem, to to już > > nie jest embedded. Dlaczego? Bo specjaliści od embedded mają > > naruszone ego? No to sorry. > > Nie przesadzałbym, tu nie chodzi o ego... [...] > tam spokojnie można użyć linuksa, jednak, > tam gdzie chodzi o bezpieczeństwo, czas reakcji musi byc przewidywalny, > tam linux się po prostu nie sprawdza. I nadal nie wiemy, czy to będzie embedded, czy nie embedded. Przecież ja tych definicji nie wymyślam. System jest systemem embedded niezależnie od tego, czy tam jest Linux, czy Java, czy FPGA. System jest embedded przez sam fakt bycia "zaembedowanym" i nie ma znaczenia, że ktoś się osobiście nie może pogodzić, że na jego ulubione specjalistyczne podwórko wkraczają rozwiązania, które uważa za niegodne. Wraz z postępem w hardwarze rynek się rozszerza a wraz z tym rozszerzaniem dotychczasowa "dominacja" jakiegokolwiek rozwiązania przestaje być oczywista. BTW: https://www.google.com/search?q=ARM+Cortex+Java Mnie to nie dziwi. A jeśli chodzi o czas startu systemu - Twoja historia jest ciekawa, ale nie musiałem szukać zbyt długo, żeby znaleźć: https://www.youtube.com/watch?v=-l_DSZe8_F8 "This demonstration shows an embedded Linux system booting in less than one second." Ten filmik jest z 2009 roku. Wygląda na to, że z Linuksem można wystartować szybciej, niż Wasz system startuje bez Linuksa. :-) Mnie to nie dziwi. Ale to jest właśnie to znikające okno szansy dla C++. Dlatego twierdzę, że C++ *nie zdąży* wygrać wojny z C. A to, że dla kogoś to nie będzie już wtedy Prawdziwy System Wbudowany (TM), to już nie mój problem. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> |
|---|---|
| Date | 2016-10-26 09:53 +0200 |
| Message-ID | <581060ee$0$15197$65785112@news.neostrada.pl> |
| In reply to | #29201 |
W dniu 2016-10-26 09:07, Maciej Sobczak pisze: >>> Podsumujmy: >>> piekarnik/pralka/zmywarka sterowana mikrokontrolerem 8051 to jest >>> system embedded. Jeśli w następnej wersji piekarnika/pralki/zmywarki >>> tego samego producenta będzie mały komputerek z Linuksem, to to już >>> nie jest embedded. Dlaczego? Bo specjaliści od embedded mają >>> naruszone ego? No to sorry. >> >> Nie przesadzałbym, tu nie chodzi o ego... > [...] >> tam spokojnie można użyć linuksa, jednak, >> tam gdzie chodzi o bezpieczeństwo, czas reakcji musi byc przewidywalny, >> tam linux się po prostu nie sprawdza. > > I nadal nie wiemy, czy to będzie embedded, czy nie embedded. > > Przecież ja tych definicji nie wymyślam. System jest systemem embedded niezależnie od tego, czy tam jest Linux, czy Java, czy FPGA. System jest embedded przez sam fakt bycia "zaembedowanym" i nie ma znaczenia, że ktoś się osobiście nie może pogodzić, że na jego ulubione specjalistyczne podwórko wkraczają rozwiązania, które uważa za niegodne. Wraz z postępem w hardwarze rynek się rozszerza a wraz z tym rozszerzaniem dotychczasowa "dominacja" jakiegokolwiek rozwiązania przestaje być oczywista. > > BTW: > > https://www.google.com/search?q=ARM+Cortex+Java > > Mnie to nie dziwi. > > A jeśli chodzi o czas startu systemu - Twoja historia jest ciekawa, ale nie musiałem szukać zbyt długo, żeby znaleźć: > > https://www.youtube.com/watch?v=-l_DSZe8_F8 > > "This demonstration shows an embedded Linux system booting in less than one second." > > Ten filmik jest z 2009 roku. > > Wygląda na to, że z Linuksem można wystartować szybciej, niż Wasz system startuje bez Linuksa. :-) A wiesz, że to zależy od sprzętu, a wiesz, że szybszy procesor ma problemy z przejściem badań (procesory używane u nas mają poniżej 100Mhz, choć nowe, ale jednak), które pozwoliłyby na pracę w niektórych miejscach, no chyba, że zainwestujesz w super pancerne obudowy izolujące (procesory z mniejszym taktowaniem i większym można znaleźć w podobnych cenach, więc tu nie chodzi o koszt tych procesorów, tym bardziej, że aby realizował wszystkie rzeczy taki sterownik wyposażony jest w 3 procesory). Dodatkowo - nie pokazał rzeczywiście co wypluwa na konsoli i co się dzieje, czy było to wyłaczenie, czy reset, wiesz obraz na module wyświetlającym tez pojawia się u nas od razu, tyle, że jest to obraz sprzed wyłączenia. Więc sam filmik - ładny, ale nic nie prezentuje. -- Kaczus http://kaczus.ppa.pl
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2016-10-26 09:57 +0200 |
| Message-ID | <nupnmk$p1l$1@node2.news.atman.pl> |
| In reply to | #29201 |
On 2016-10-26 09:07, Maciej Sobczak wrote: > "This demonstration shows an embedded Linux system booting in less than one second." I pokazała rownież jak przez najbliższe miliard lat beda to weryfikować formalnie żeby dopuścić do aplikacji krytycznych z gatunku strzelanie poduszkami. Tak, bardzo ładne wskaźniki.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2016-10-26 06:26 -0700 |
| Message-ID | <81e02eba-9061-49b3-ae2f-36be172eb0c4@googlegroups.com> |
| In reply to | #29203 |
On Wednesday, October 26, 2016 at 9:58:13 AM UTC+2, Sebastian Biały wrote: > > "This demonstration shows an embedded Linux system booting in less than one second." > > I pokazała rownież jak przez najbliższe miliard lat beda to weryfikować > formalnie Dalej nie rozumiesz. Albo trolujesz. W każdym razie mieszasz wątki. Jeszcze raz: Rynek dzieli się na dwie części: 1. rozrywkową - tam jest miejsce na Javę (lustro z prognozą pogody) oraz na bootującego się w sekundę Linuksa do zmywarki. Tego się nie weryfikuje. To się, jak to ostatnio słyszałem, "nak..wia kod" i sprzedaje. W tej działce nikogo nie interesuje rozgrywka pomiędzy C i C++, nikt tego meczu nie będzie oglądał, bo nie ma na to czasu. Wybór języka będzie kwestią preferencji zespołu, tak jak to się dzieje na desktopach, gdzie każdy klepie w czym lubi a dyskusje pasjonują tylko flejmerów na grupach dyskusyjnych. 2. krytyczną - tam się robi weryfikację na tak bolesnym poziomie, że zastosowanie mają jedynie maksymalnie *uproszczone* języki imperatywne (MISRA-C, Ada), być może uzupełnione o metody formalne (Frama-C, SPARK). W tej działce nikt nie będzie ryzykował wprowadzenia C++, bo wartość dodana na poziomie składni języka nie jest warta dodatkowej komplikacji po stronie narzędzi i ich ewentualnej kwalifikacji. 1.5. Istnieje jakaś przestrzeń na granicy tych światów, czyli coś, co już jest twardym RT ale jeszcze nie zabija ludzi. Tam jest miejsce na C++ (nawet to nowoczesne), bo środowiska zarządzane nie mają sensu a bolesnej weryfikacji wymaganej przez regulacje branżowe jeszcze nie trzeba robić. Ale spokojnego snu bym się tu nie spodziewał, bo presja techniczna jest z obu stron. We wszystkich tych obszarach wchodzą (realnie) techniki generacji kodu, przy których dyskusja o wyższości *składni* jednego języka nad drugim jest bezprzedmiotowa. W skrócie: nie ma takiej przestrzeni w embedach, w której C++ byłby "niezagrożony", "niezastąpiony", czy jeszcze niejakiś. Zwłaszcza, że i tak go w tej przestrzeni jeszcze nie ma (!). W tym punkcie pozycja C++ jest gorsza, niż na desktopach, bo na desktopach miał silną pozycję i został częściowo wyparty, a w embedach nawet nie zaczął mieć silnej pozycji a konkurencję już ma. Jeśli są jakieś nowe argumenty, chętnie się czegoś dowiem. Ale trolować mi się nie chce. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
Page 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
Back to top | Article view | pl.comp.programming
csiph-web