Рішення частих проблем – ЧАСТИНА 3

сти пропозицію, подібне попередньому, так як це дає всі факти

Не вважайте, що неполадка виникла через розміру файлу, і не говорите: Коли я звертаюся до великого файлу, Emacs друкує Сьогодні я себе чудово почуваю”. Це саме те, що ми називаємо поясненням на здогадах . Настільки ж можливо, що помилка сталася через те, що в імені файлу мається z. Якщо це так, то коли ми отримали б ваш опис, ми намагалися б вирішити проблему з великим файлом ,

ймовірно, без z в його імені і не знайшли б ніякої помилки Ми ніяк не могли б здогадатися, що повинні були спробувати звернутися до файлу з буквою z в імені

З іншого боку, помилка могла виникнути через те, що файл починається точно з

25 пробілів Тому ви повинні переконається в тому, що проінформували нас про точний зміст будь-якого файлу, який буде потрібно, щоб відтворити помилку Що якщо помилка зустрічається тільки тоді, коли ви до того набрали команду Cx Ca Ось чому ми просимо вас давати точну послідовність знаків, які ви набрали з часу запуску Emacs

Ви не повинні навіть говорити звернутися до файлу замість Cx Cf, якщо не впевнені, що немає відмінностей в тому, яка команда звернення використовується Аналогічно, краще сказати після того як я набираю hRETA B C hRETCp , що говорити якщо у мене є три букви на рядку , якщо ви ввели текст саме таким способом

Тому, будь ласка, не припускайте пояснення, коли повідомляєте про помилку Якщо насправді ви хочете дослідити цю проблему в відладчик і повідомити пояснення, які вже є щось більше, ніж припущення, це буде нам корисно – але будь ласка, повідомте також і факти

3233  Форма звіту про помилки

Кращий спосіб повідомити про помилку – відправити електронний лист супровідників Emacs за адресою bug-gnu-emacs@gnuorg (Якщо ви хочете запропонувати зміну або поліпшення, використовуйте цю ж адресу)

Якщо ви хочете читати звіти про помилки, ви можете знайти їх в групі новин

‘Gnuemacsbug; памятайте однак, що як спостерігач ви не повинні критикувати нічого з того, що ви там побачите Мета повідомлень про помилки – давати інформацію супровідників Emacs Спостерігачі вітаються до тих пір, поки вони не втручаються в це Зокрема, деякі звіти містять великі обсяги даних спостерігачі не повинні на це скаржитися

Будь ласка, не надсилайте повідомлення про помилки через мережеві новини пошта надійніша тим, що дає ваш точну адресу, який може знадобитися, щоб попросити у вас більше інформації

Якщо ви не можете послати електронну пошту, оперувати звіт про помилку на папері або на машінночітаемом носії за наступною адресою:

GNU Emacs Bugs

Free Software Foundation

59 Temple Place, Suite 330

Boston, MA 02111-1307 USA

Ми не обіцяємо виправити помилку але якщо помилка серйозна, або жахлива, або її легко виправити, то найімовірніше ми захочемо це зробити

Зручний спосіб послати звіт про помилку в Emacs – використовувати команду Mx report-emacs-bug Вона готує буфер повідомлення (див Глава 26 [Посилка пошти], с 267) і автоматично вставляє деяку важливу інформацію Однак, вона не може надати всю необхідну інформацію ви все одно повинні прочитати наведені нижче рекомендації і слідувати їм, тоді ви можете ввести інші потрібні відомості вручну перед відправленням повідомлення

Підтримку особи могли досліджувати помилку, ваш звіт має включати всі сле-

дмуть відомості:

Номер версії Emacs Без цього ми не зможемо дізнатися, чи є сенс шукати цю помилку в поточній версії GNU Emacs

Ви можете отримати номер версії, набравши Mx emacs-version hRETi Якщо ця команда не працює, то у вас, ймовірно, коштує не GNU Emacs, а щось інше, тому вам краще повідомляти про помилку за іншою адресою

Тип використовуваної вами машини і назву і номер версії операційної системи

M-x emacs-version hRETi  надає також і цю інформацію Скопіюйте її ви-

вод з буфера * Messages *, щоб привести його повно і точно

Операнди, задані команді configure під час установки Emacs

Повний перелік будь-яких змін, які ви внесли у вихідний текст Emacs (У нас може не виявитися часу на дослідження помилки, якщо вона не відбувається в незміненому Emacs Але якщо ви внесли модифікації і не сказали нам, ви просите нас піти туди-ні-знаю-куди принести то-ні-знаю-що

Говоріть про ці зміни точно Пояснення англійською недостатньо – при-

шліть контекстну латку для них

Додавання своїх файлів або перенесення на іншу машину теж є зміною вихідного тексту

Подробиці про будь-яких інших відхиленнях від стандартної процедури установки GNU Emacs

Повний текст будь-яких файлів, необхідних для відтворення помилки

Якщо ви можете вказати нам спосіб викликати помилку не звертаючись до яких файлів, будь ласка, зробіть це Це зробить налагодження набагато простіше Якщо для цього дійсно потрібні файли, переконайтеся, що ви вжили заходів, щоб ми могли побачити їх точний зміст Наприклад, часто може мати значення, чи є прогалини в кінцях рядків або переклад рядка після останнього рядка в буфері (нікого не повинно хвилювати, обірвана чи останній рядок, але спробуйте розповісти це помилку)

Точні команди, які ми повинні надрукувати, щоб відтворити цю помилку

Простий спосіб записати точно введення, отриманий Emacs, – написати файл супро-

ждения Для цього виконайте лісповское вираз

(open-dribble-file &quot~/dribble&quot)

використовуючи M-: або з буфера * scratch * відразу після старту Emacs З цього моменту Emacs копіює весь ваш введення в зазначений файл супроводу, поки процес Emacs не буде знищений

Для можливих помилок зображення, тип терміналу (значення змінної середовища TERM), повний запис termcap для терміналу з / etc / termcap (так як цей файл не ідентичний для всіх машин) і висновок, який Emacs насправді посилав на термінал

Щоб зібрати цей висновок, виконайте лісповское вираз

(open-termscript &quot~/termscript&quot)

використовуючи M-: або з буфера * scratch * відразу після старту Emacs З цього моменту Emacs копіює весь термінальний висновок також і в заданий файл термінального протоколу до тих пір, поки процес Emacs НЕ буде знищений Якщо помилка сталася в процесі запуску Emacs, помістіть цей вираз у ваш файл . Emacs, таким чином, файл термінального протоколу буде відкриватися, коли Emacs відобразить екран в перший раз

Слід попередити: часто важко, а іноді й неможливо виправити помилку, яка від терміналу, без доступу до терміналу того типу, який цю помилку породжує

Опис поведінки, яке ви спостерігали і визнали неправильним Наприклад, Процес Emacs отримує фатальний сигнал або Виходить ось такий текст, що, як я думаю, неправильно 2

2 Писати звіти потрібно, звичайно, англійською Якщо ви не знаєте англійської самі, знайдіть того, хто вам допоможе (Прим перекладача)

Звичайно, якщо помилка виявляється в тому, що Emacs отримує фатальний сигнал, її не можна не помітити Але якщо помилка – це неправильний текст, супровідник може не помітити, де ж тут проблема Навіщо залишати таку можливість

Навіть якщо проблема в тому, що виникає фатальний сигнал, ви тим не менше повинні сказати це явно Припустимо, сталося щось дивне, наприклад, ваша копія вихідного тексту не синхронізована або ви натрапили на помилку в бібліотеці Сі у вашій системі (Таке траплялося) Ваша копія може отримати фатальний збій, а наша може не отримати Якщо ви скажете, що очікується крах, тоді, якщо наш Emacs не отримає фатальний збій, ми дізналися б, що помилки не відбувається Якби ви не сказали, то ми не дізналися б, чи відбувається помилка, – ми не змогли б зробити ніяких висновків з наших спостережень

Якщо прояв неполадки – це повідомлення Emacs про помилку, то важливо описати точний текст повідомлення і слід, що показує, яким чином Лісп-програма в Emacs прийшла до помилки

Щоб точно отримати текст повідомлення про помилку, скопіюйте його з буфера

‘* Messages * в ваш звіт Скопіюйте його повністю, а не тільки частина

Щоб отримати слід для помилки, виконайте лісповское вираз (setq debugon-error t) перед тим, як відбудеться помилка (тобто ви повинні виконати цей вираз, а потім повторити ситуацію, що приводить до помилки) При виникненні помилки це викликає запуск відладчика Лиспа, який покаже вам слід Скопіюйте текст сліду відладчика в опис помилки

Таке використання відладчика можливо тільки в тому випадку, якщо ви знаєте, як викликати помилку знову Якщо ви не можете відтворити її, принаймні скопіюйте повне повідомлення про помилку

Перевірте всі програми, які ви завантажили в середу Лиспа, включаючи ваш файл

‘. Emacs, не встановлюють вони якісь змінні, які можуть впливати на функціонування Emacs Також подивіться, чи трапляється помилка у щойно запущеному Emacs без завантаження файлу . Emacs (Запустіть Emacs з ключем-q, це запобіжить завантаження файлу ініціалізації) Якщо в цьому випадку помилка не стрінеться, ви повинні повідомити точний зміст усіх програм, які ви повинні завантажити в середу Лиспа для того, щоб змусити помилку проявитися

Якщо виявилося, що помилка залежить від файлу ініціалізації або інших Лісппрограмм, які не є частиною стандартної системи Emacs, тоді ви повинні упевнитися, що це не помилка цих програм, звертаючись спершу до тих, хто їх супроводжує Після того, як вони підтвердять, що використовують Emacs так, як ними передбачалося, вони повинні повідомити про цю помилку

Якщо ви хочете послатися на якесь місце в початковому тексті GNU Emacs, покажіть цей рядок коду і кілька рядків контексту Не давайте тільки номер рядка

Номери рядків у робочих вихідних текстах не збігаються з номерами в ваших файлах Зясування того, який код знаходиться у зазначеному рядку у вашій версії, створить додаткову роботу супровідників, і ми не зможемо бути точно впевнені

Додаткова інформація з відладчика Сі, такого як GDB, може дозволити нам знайти проблему, що виникає на машині, яка нам недоступна Якщо ви не вмієте користуватися GDB, будь ласка, прочитайте керівництво по ньому – воно не дуже довге, а GDB простий у застосуванні Ви можете знайти дистрибутив GDB з інтерактивним керівництвом в більшості тих же місць, де ви можете отримати дистрибутив Emacs Щоб запустити Emacs під GDB, вам потрібно перейти в підкаталог src, в якому було скомпільовано Emacs, і виконати gdb emacs. Важливо, щоб каталог src був поточним, щоб GDB вважав в ньому файл . Gdbinit.

Однак, при зборі додаткових відомостей вам доведеться подумати, якщо ви хочете,

щоб вони показали, що ж саме викликає помилку

Наприклад, багато посилають тільки слід, але сам по собі він не дуже корисний Простий слід з аргументами часто мало говорить про те, що відбувається всередині GNU Emacs, тому що більшість перелічених у ньому аргументів є покажчиками на лісповскіе обєкти Чисельні значення цих покажчиків не мають ніякої значущості все, що грає роль – це вміст обєктів, на які вони вказують (і велика частина їх вмісту – теж покажчики)

Щоб надати корисну інформацію, вам потрібно показати значення лісповскіх обєктів в лісповской запису Зробіть це для кожної змінної, що є лісповскім обєктом, в декількох нижніх фреймах стека Подивіться у вихідний текст, щоб дізнатися, які змінні є лісповскімі обєктами, тому що відладчик вважає їх цілими числами

Щоб показати значення змінної в лісповской записи, спочатку надрукуйте її значення, а потім використовуйте певну користувачем команду GDB pr, яка надрукує лісповскій обєкт в синтаксисі Лиспа (Якщо вам доводиться використовувати інший відладчик, викличте функцію debug_print з цим обєктом як аргумент) Команда pr визначена у файлі . Gdbinit і працює, тільки якщо ви налагоджуєте запущений процес (Не дамп памяті)

Щоб помилка в Ліспі зупиняла Emacs і повертала в GDB, встановіть кон-

контрольну точку в Fsignal

Щоб отримати короткий список виконуються в даний момент лісповскіх функ-

ций, наберіть команду GDB xbacktrace

Якщо ви хочете дослідити аргументи лісповскіх функцій, переходите вгору по стеку і кожен раз, коли потрапляєте у фрейм функції Ffuncall, вводите такі команди GDB:

p *args pr

Щоб надрукувати перший аргумент, отриманий цією функцією, використовуйте ці команди:

p args[1]

pr

Інші аргументи ви можете надрукувати подібним же чином Аргумент nargs функції Ffuncall каже, скільки аргументів отримала Ffuncall це включає саму лісповскую функцію і її аргументи

Файл . Gdbinit визначає інші команди, корисні для перегляду типів і вмісту лісповскіх обєктів Їх імена починаються з x. Ці команди працюють на більш низькому рівні, ніж pr, і менш зручні, але вони можуть працювати, навіть коли pr не працює, наприклад при налагодженні дампа памяті, або коли Emacs отримав фатальний сигнал

Якщо симптом помилки полягає в тому, що Emacs не відповідає, не припускав, що він завис – він може бути в нескінченному циклі Щоб зясувати, що ж саме відбувається, відтворіть проблему під GDB і зупиніть Emacs, коли він не відповідає (Якщо Emacs безпосередньо використовує X Windows, ви можете його зупинити, набравши в GDB команду Cz) Потім спробуйте виконати один крок за допомогою

‘Step. Якщо Emacs завис, команда step не повернеться Якщо Emacs зациклився, step

повернеться

Якщо це покаже, що Emacs завис на системному виклику, зупиніть його знову і перевірте аргументи цього виклику У вашому звіті вкажіть точно, де в початковому тексті знаходиться цей системний виклик, і які його аргументи

Якщо Emacs потрапив в нескінченний цикл, будь ласка, визначте, де цей цикл починається і де завершується Найпростіший спосіб зробити це – використовувати команду GDB finish. При кожному її використанні Emacs продовжує виконання, поки не

вийде з одного фрейма стека Продовжуйте набирати finish, поки вона не перестане повертатися – це означатиме, що нескінченний цикл знаходиться в тому фреймі стека, який ви тільки що намагалися завершити

Зупиніть Emacs знову і вводите послідовно finish, поки ви не повернетеся в той же фрейм Тоді використовуйте next, щоб пройти крізь цей фрейм За допомогою покрокового виконання ви побачите, де цикл починається і де закінчується Також, будь ласка, перевірте використовувані в циклі дані і спробуйте зясувати, чому цикл не завершується, коли потрібно Додайте всі ці відомості в ваш звіт про помилку

Ось деякі речі, які необовязкові в звіті про помилку:

Вичерпний опис умов виникнення і не виникнення помилки – це не потрібно для відтворюваних помилок

Нерідко люди, що зіштовхуються з помилкою, витрачають багато часу на зясування того, які зміни у вхідному файлі змусять помилку зникнути, а які не торкнуться її

Це часто вимагає багато часу і не настільки корисно, тому що ми будемо шукати помилку, запускаючи один приклад в відладчик з контрольними точками, а не чистої дедукцією із серії прикладів Ви також можете заощадити час, не вишукуючи додаткові приклади

Зрозуміло, якщо ви можете знайти більш простий приклад для повідомлення замість споконвічного, це буде зручніше Помилки у виведенні буде легше виявити, робота в відладчик займе менше часу, і так далі

Однак, спрощення візового режиму не життєво важливо якщо ви не можете це зробити, або у вас немає часу намагатися, будь ласка, повідомте про помилку з початковим тестовим прикладом

Наступ системних викликів роботи Emacs

Сліди системних викликів дуже корисні для деяких особливих видів налагодження, але найчастіше вони дають мало корисної інформації Тому дивно, що багато, як здається, вважають, що саме оправлення сліду системних викликів – це і є звіт про фатальному збої Можливо, ця звичка сформувалася з досвіду налагодження програм, до яких немає вихідного тексту, або в яких немає налагоджувальних символів

У більшості програм слід викликів підпрограм набагато, набагато інформативніше сліду системних викликів Навіть у Emacs простий слід підпрограм зазвичай більш інформативний, хоча щоб дати всі відомості, ви повинні доповнити слід, показавши значення змінних і надрукувавши їх як лісповскіе обєкти за допомогою pr (дивіться вище)

Латка для помилки

Латка для помилки корисна, якщо це гарна латка Але не опускайте в звіті про помилку іншу необхідну інформацію, таку як тестовий приклад, в припущенні, що латки достатньо Ми можемо побачити недоліки у вашій латці і вирішити проблему іншим способом або не понять її зовсім І якщо ми не можемо зрозуміти, яку помилку припускає виправити ваша латка, або чому вона повинна бути поліпшенням, ми не повинні її встановлювати

Припущення про те, чим є ця помилка, або від чого вона залежить

Такі припущення зазвичай невірні Навіть експерти не можуть правильно Догада-

тися про такі речі, які не застосувавши спочатку відладчик для зясування фактів

3234  Відправка латок для GNU Emacs

Якщо хочете написати виправлення помилок або поліпшення для GNU Emacs, це дуже нам допоможе Коли ви посилаєте ваші зміни, будь ласка, дотримуйтесь цих рекомендацій, щоб супровідників було легше їх використовувати Якщо ви не дотримуєтесь їм, ваші

зміни проте можуть бути корисні, але використання їх потребують додаткової роботи Супровід GNU Emacs – це в найкращих обставин багато роботи, і нам буде важко справлятися, якщо ви не зробите все від вас залежне, щоб нам допомогти

Посилайте разом з вашими змінами пояснення, яку проблему вони вирішують, або яке поліпшення вони приносять Для виправлення помилки просто включіть опис цієї помилки і поясніть, як це зміна її виправляє

(Посилання на повідомлення про помилку не так хороша, як включення самого повідомлення, тому що тоді нам доведеться шукати, і можливо, ми його вже видалили, якщо помилка вже виправлена)

Завжди включайте хороший опис проблеми, яку, як ви думаєте, ви вирішили

Ми повинні переконатися, що зміна правильно, перед тим як його встановлювати Навіть якщо воно правильно, у нас можуть бути труднощі з його розумінням, якщо самі ми не можемо відтворити цю помилку

Включайте всі необхідні коментарі, які в майбутньому допоможуть зрозуміти мету цієї зміни іншим людям, читаючою вихідний текст

Чи не перемішуйте зміни, зроблені з різних причин Посилайте їх раз

дельно

Якщо ви робите два зміни з різних причин, ми можемо не захотіти встановлювати їх обидва Можливо, ми захочемо встановити тільки одне Якщо ви пошлете їх перемішаними в одному наборі латок, ми повинні будемо робити додаткову роботу, щоб їх розплутати – щоб зрозуміти, які частини зміни служать яким цілям Якщо у нас немає на це часу, ми можемо проігнорувати ваші зміни цілком

Якщо ви посилаєте кожну зміну, як тільки ви його написали, з окремим поясненням, то два цих зміни не переплутаються, і ми зможемо детально розглянути кожне, не витрачаючи додаткових зусиль на їх поділ

Посилайте кожну зміну, як тільки ви його закінчили Іноді люди вважають, що допомагають нам, накопичуючи багато змін і посилаючи їх всі разом Як пояснено вище, це найгірше, що ви можете зробити

Оскільки ви повинні посилати кожну зміну окремо, ви також могли б посилати їх негайно Це дасть нам можливість встановити ваше зміна відразу ж, якщо це важливо

Для створення латок використовуйте diff-c. Латки без контексту важко встановити надійно Більш того, їх важко вивчати ми повинні завжди вивчати латку, щоб вирішити, чи потрібно її встановлювати Обєднаний формат краще Бесконтекстние, але його не так легко читати, як формат -c.

Якщо у вас є GNU diff, використовуйте при створенні латок в коді на Сі команду diff

-C-F ^ [_a-zA-Z0-9 $] + * (‘. Це покаже кожне імя функції, в якій знаходиться зміна

Уникайте будь неоднозначності в тому, що є старою версією, а що новою

Будь ласка, задавайте стару версію першим аргументом diff, а нову версію другого І будь ласка, давайте тієї чи іншої версії таке імя, яке показувало б, старий це файл або ваш змінений

Пишіть для ваших змін журнальні записи Це позбавить нас від додаткової роботи по їх написання і допоможе розяснити ваші зміни, щоб ми могли їх зрозуміти

Мета журналу змін – показати людям, де шукати змінені місця Тому ви повинні точно вказувати, які функції ви змінили у великих функціях також часто корисно вказувати, де саме в цій функції було зроблено зміна

З іншого боку, коли ви показали людям, де знайти зміна, вам не потрібно пояснювати його мета в журналі змін Таким чином, якщо ви додали нову функцію, все, що ви повинні сказати, – це що вона нова Якщо ви відчуваєте, що мета цього вимагає розяснення, то це, швидше за все, так і є, але розміщуйте розяснення в коментарях в коді Там воно буде більш корисно

Будь ласка, прочитайте файли ChangeLog в каталогах src і lisp, щоб зрозуміти, якого сорту відомості в них треба писати, і освоїти використовуваний нами стиль Якщо ви хочете, щоб у рядку заголовка, б показала автора зміни, зявилося ваше імя, пошліть нам цей заголовок Див Розділ 2212 [Change Log], с 224

Коли ви пишете виправлення, памятайте, що ми не можемо встановити зміна, яке могло б порушити роботу на інших системах Будь ласка, подумайте про ефект, який може мати ваше зміна, якщо його скомпілювати на системі іншого типу

Іноді люди надсилають виправлення, які можуть бути поліпшенням загалом – але переконатися в цьому важко Встановити такі зміни важко, тому що ми повинні вивчити їх дуже уважно Звичайно, гарне пояснення міркувань, завдяки яким ви прийшли до усвідомлення правильності такої зміни, може допомогти переконати нас

Найбезпечніші зміни – це зміни в конфігураційних файлах для конкретної машини Вони безпечні, тому що не можуть спричинити за собою нових помилок на інших машинах

Допоможіть нам справлятися з навантаженням, розробляючи латку таким чином, щоб було ясно, що її установка безпечна

324  Сприяння в розробці Emacs

Якщо ви хотіли б допомогти в тестуванні випусків Emacs, щоб переконатися, що вони працюють правильно, або якщо ви хотіли б працювати над поліпшенням Emacs, будь ласка, звяжіться з супровідників за адресою bug-gnu-emacs@gnuorg Випробувач повинен бути готовий як до дослідження помилок, так і до їх опису Якщо ви бажаєте покращити Emacs, будь ласка, запитайте про пропоновані проекти або запропонуйте свої ідеї

Якщо ви вже написали розширення, будь ласка, повідомте нам про це Якщо ви ще не почали роботу, буде корисним звязатися із bug-gnu-emacs@gnuorg до того, як ви почнете тоді ми зможемо порадити, як зробити так, щоб ваші розширення краще стикувалися з іншою частиною Emacs

325  Як отримати допомогу по GNU Emacs

Якщо ви потребуєте допомоги з установки, використання або модифікації GNU Emacs, у вас є два способи отримати її:

Послати повідомлення в список розсилки help-gnu-emacs@gnuorg або опублікувати ваш запит з групи новин gnuemacshelp (Цей список розсилки і група новин повідомляються між собою, тому байдуже, що саме ви будете використовувати)

Подивитися в каталозі послуг, чи немає когось, хто зможе вам допомогти за плату

Цей каталог знаходиться у файлі з імям etc / SERVICE в дистрибутиві Emacs

Джерело: Річард Столмен, Керівництво по GNU Emacs

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*