BG Development


Страници: (3) [1] 2 3   ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> Приеха ми най-накрая пача във Wine.
johnfound
Публикувано на: 02-06-2019, 18:57
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7420
Регистриран на: 27.05.04



Ето то къмита: https://source.winehq.org/git/wine.git/comm...89e96bd46c015e3

Хваля се, защото едно, че пиша на Ц с огромни усилия и неудоволствие icon_lol.gif , друго, че WINE е проект в който трудно приемат пачове.

Но с удоволствие или не, свободния софтуер си е свободен – когато нещо не ти харесва, можеш да си го оправиш.

Това мнение е било редактирано от johnfound на 02-06-2019, 18:58


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
PMEmail PosterUsers Website
Top
bvbfan
Публикувано на: 02-06-2019, 20:08
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 3170
Регистриран на: 08.12.13



Виж как добре си го написал на С, сравнено с асемблер е красота icon_smile.gif


--------------------
QUOTE (Bender @ 23-04-2015, 19:11)
Xamarin: ЛАПАЙ!
Ти: Добре...
PMEmail Poster
Top
Delegate
Публикувано на: 02-06-2019, 20:30
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1782
Регистриран на: 30.05.09



Като видях заглавието помислих, че Рабин пак се оплаква от неква пача.
Иначе поздравления, това го мъчиш от поне 3 години, ако не ме лъже паметта.
PMEmail Poster
Top
johnfound
Публикувано на: 02-06-2019, 21:24
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7420
Регистриран на: 27.05.04



QUOTE (Delegate @ 02-06-2019, 21:30)
...това го мъчиш от поне 3 години, ако не ме лъже паметта.

По принцип бъга го открих в 2016-та и го вписах в бъгзилата, заедно с първата версия на пача. Обаче нещо ме ядосаха разработчиците, така че не го пуснах за комитване. Е, тая година ми мина и преди месец го постнах в мейл-листа за официален комит. С малко доработки за по-добър стил.


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
PMEmail PosterUsers Website
Top
v1rusman
Публикувано на: 03-06-2019, 19:41
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 421
Регистриран на: 15.09.07



Не отнема ли много време да влезеш в кода на такова нещо, че да почнеш да правиш каквото си искаш?
PMEmail Poster
Top
johnfound
Публикувано на: 03-06-2019, 20:40
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7420
Регистриран на: 27.05.04



QUOTE (v1rusman @ 03-06-2019, 20:41)
Не отнема ли много време да влезеш в кода на такова нещо, че да почнеш да правиш каквото си искаш?

Ами не всъщност. Разбира се зависи от много фактори, но като цяло не е трудно. Само изглежда така. Процеса е следния:

1. Решаваш какво искаш да прави/да не прави програмата, различно от сегашното.

2. Намираш мястото в кода, което отговаря за дадената функция - това е всъщност най-сложната част. Тука се налага да се рови из кода, но ако структурата на проекта е добре организирана, нещата се намират сравнително лесно. Може да се питат и разработчиците – те със сигурност знаят, поне приблизително, а отговорът е лесен, ако просто питаш в кой файл се обработват drag&drop операциите (както беше в моя случай). Може и банално да се използва груба сила – търсене по специфични ключови думи. (пак в моя случай "grep -р WS_EX_ACCEPTFILES ./*" връща 5..6 файла, което стеснява значително обема на търсенето).

3. Четеш кода и търсиш къде е проблема и какво трябва да се промени – това е вече леката част.

4. Променяш - тестваш - променяш - тестваш, докато стане. Лично за мене това е проблем, когато става въпрос за големи проекти на C++, защото всяка компилация трае вечност. Затова се налага да пиша на сухо, да си проверявам кода по три пъти и да тествам рядко. Затова и не пиша на C/C++ (отделно, че не харесвам синтаксиса) а на асемблер, където 500К реда се компилират за 4 секунди на CPU 1GHz. icon_wink.gif


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
PMEmail PosterUsers Website
Top
AK-85
Публикувано на: 04-06-2019, 00:11
Quote Post



Име:
Група: Потребител
Ранг: Старо куче

Мнения: 790
Регистриран на: 06.07.06



QUOTE (johnfound @ 03-06-2019, 19:40)
Лично за мене това е проблем, когато става въпрос за големи проекти на C++, защото всяка компилация трае вечност.

Готов съм да се обзаложа, че си правил нещо тотално погрешно. Първо, концепцията за инкрементална компилация е на вече буквално няколко десетилетия, така че да, първата компилация трае вечност, но следващите не (освен ако не промениш header файл или нещо подобно, което се използва на доста места, но твоят случай не е такъв). Второ, ако скоростта пак е проблем, винаги можеш да изключиш оптимизациите (които отнемат навярно по-голямата част от времето) примерно с "export CFLAGS=-Og CXXFLAGS=-Og", което така или иначе се препоръчва, докато работиш върху промените си, защото оптимизираният код не е най-приятният за дебъгване, а и едва ли си започнал веднага с тестовете за производителност. Трето, паралелният "make" ("make -j($nproc)") помага.

Това мнение е било редактирано от AK-85 на 04-06-2019, 00:19
PM
Top
johnfound
Публикувано на: 04-06-2019, 00:31
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7420
Регистриран на: 27.05.04



QUOTE (AK-85 @ 04-06-2019, 01:11)
Готов съм да се обзаложа, че си правил нещо тотално погрешно. Първо, концепцията за инкрементална компилация е на вече буквално няколко десетилетия, така че да, първата компилация трае вечност, но следващите не (освен ако не промениш header файл или нещо подобно, което се използва на доста места, но твоят случай не е такъв). Второ, ако скоростта пак е проблем, винаги можеш да изключиш оптимизациите (които отнемат навярно по-голямата част от времето) примерно с "export CFLAGS=-Og CXXFLAGS=-Og", което така или иначе се препоръчва, докато работиш върху промените си, защото оптимизираният код не е най-приятният за дебъгване, а и едва ли си започнал веднага с тестовете за производителност. Трето, паралелният "make" ("make -j($nproc)") помага.

А бе и аз така знам, но кой-знае защо при мене тия зависимости много често се случват. Разбира се да, вероятно правя нещо тотално погрешно. Но когато компилирам проект на асемблер, не правя нищо, нито грешно, нито правилно. Просто пускам компилация и след няколко секунди получавам изпълним файл. Няма хедъри, няма зависимости, няма инкрементална компилация. Няма нищо, което мога да направя грешно.

Едно обаче е сигурно – ако някога ми се наложи да пиша сериозно на C/C++ (вероятността е близка до 0, но знае ли човек...) ще трябва да ги науча всичките тези магии. А за 50 реда код, май не си струва. Редактирам, пиша make и много-много не се замислям...


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
PMEmail PosterUsers Website
Top
AK-85
Публикувано на: 04-06-2019, 00:44
Quote Post



Име:
Група: Потребител
Ранг: Старо куче

Мнения: 790
Регистриран на: 06.07.06



Иронията е, че от трите неща, които изброих, точно това, което има най-голям ефект - инкременталната компилация, не изисква да направиш нещо, по-точно изисква да направиш нищо. Изпълняваш "make" веднъж, изчакваш търпеливо, след което си правиш промените и пак изпълняваш "make" без никакви допълнителни стъпки ("make clean", триене на build директорията или междинни файлове и т.н. са точно такива стъпки). Или по собствените ти думи:
QUOTE (johnfound @ 03-06-2019, 23:31)
Редактирам, пиша make и много-много не се замислям...


Това мнение е било редактирано от AK-85 на 04-06-2019, 00:46
PM
Top
johnfound
Публикувано на: 04-06-2019, 06:36
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7420
Регистриран на: 27.05.04



QUOTE (AK-85 @ 04-06-2019, 01:44)
Иронията е, че от трите неща, които изброих, точно това, което има най-голям ефект - инкременталната компилация, не изисква да направиш нещо, по-точно изисква да направиш нищо. Изпълняваш "make" веднъж, изчакваш търпеливо, след което си правиш промените и пак изпълняваш "make" без никакви допълнителни стъпки ("make clean", триене на build директорията или междинни файлове и т.н. са точно такива стъпки). Или по собствените ти думи:
QUOTE (johnfound @ 03-06-2019, 23:31)
Редактирам, пиша make и много-много не се замислям...

Да де, ама при мене много често когато работя със C++ код, когато напиша make компилира огромни части от кода. Сега не говоря за Wine и пача от темата. Там не помня как е било, защото беше преди 3 години. Говоря като общо впечатление от сумарния ми опит с езика. А общото впечатление е именно: "безкрайна компилация, предизвикваща отвращение". icon_smile.gif


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
PMEmail PosterUsers Website
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (3) [1] 2 3  Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2019 | BG Development | All Rights Reserved
RSS 2.0