Здравствуйте, YF, Вы писали:
YF>Сообщение об ошибке там вываливается такое: YF>error : expected (int * int * int)-, got void in computation branch: (int * int * int) is not a subtype of void [simple require] YF>Если сделать по нему двойной клик (оно есть в списке сообщений об ошибке, кстати), то в редакторе выделяется не весь if, а YF>именно строчка с MessageBox. т.е. куда уж точнее. YF>Вопрос: в части сообщения "computation brach", нельзя ли указать "else", может эта информация у компилятора есть? А то "computation branch", это и правда не очень понятно.
Нельзя. Ключевые слова — это части макроса. Они не доступны типизатору. Типизатор типизирует то во что раскрываются макросы.
Но проблема решает проще. Можно выдавать два сообщения об ошибке (идущие друг за другом) указывающее на обе ветви, и сделать текст более понятным для новичка в языке. Именно это я и предлагал сделать. Но в ответ получил нудную дисскуссию.
Ziaw, я сильно переделал алгоритм вывода типов для match (в который, в частности, переписывается и if). Так что теперь компилятор реагирует на подобные ошибки иначе (близко к тому, что хотел FDSC).
Проблема только в том, что новый алгоритм медленнее предыдущего. Сейчас вот думаем имеет ли смысл применять его, или просто улучшить сообщение об ошибке (без изменения алгоритма). Без изменения же алгоритма добиться того что хочет FDSC невозможно в принципе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, YF, Вы писали:
YF>>VladD2, разумеется, это увидел, оставил комментарий и закрыл его, справедливо полагая, что hardcase тебе уже все сказал. Другое дело, что тебя этот ответ не устроил.
VD>Надо уточнить. Оставил комментарий, не дождался ответа на него, и только потом закрыл.
Он минуту ждал или две? Дефект был открыт 22 августа и закрыт в 11:55 утра того же дня. Если это называется "не дождался реакции", то я тебя поздравляю.
VD>Ну, почему же? Очень даже ожидают. Но если реакции нет, то других средств уже не остается.
И сколько же ждали? Я вижу, что его закрыли сразу же в тот же день.
VD>Если проблема есть, то ее все равно поднимут снова и снова. Кто-нибудь обязательно опишет ее более корректно и она будет решена.
Полная чушь. Если есть проблема, она может годами висеть, отпугивать и мешать пользователям, но программист о ней узнает совершенно случайно, а то и не узнает вообще.
YF>>Здесь же никто реакции пользователя не ждал. Объяснили и закрыли.
VD>Не правда. Реакцию ждали, но она не последовала.
Наглая ложь.
VD>Плюс было явное не понимание происходящего тем кто создал issue. Сочетание отсутствия ответа, невнятности issue и явно неверных предпосылок автора и привело к данному решению.
А это уже хамство.
VD>Учитывая, что ответ можно дать и после закрытия проблемой это не является. Будет внятное объяснение, issue можно и переоткрыть.
Учитывая, что пользователь не знает, будет ли реакция на его ответ ПОСЛЕ закрытия бага, это является серьёзной проблемой.
VD>Вот именно. Хорошо, что хоть кто-то это понимает.
Влад, спасибо, что "возишься", но хамство это не отменяет.
P.S. Я, кстати, тебе писал личное сообщение через форум, оно до тебя дошло? Мне никакого ответа назад что-то не пришло, а писал давно.
Re[5]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
Здравствуйте, VladD2, Вы писали:
VD>Я несколько раз прочел.
Не верю. Судя по тому, что ты мне писал пару дней в ответ на мои сообщения, ты поверхностно просмотрел то, о чём я писал. В том числе, не смотрел код.
VD>Это то понятно, но информации от этого не много.
Достаточно, чтобы понять, что я говорю о том, что мне не нравится сообщение об ошибке
FDS>>Если не понял — не закрывать дефект, а переспросить, что имеется в виду.
VD>Но там же ведь были какие-то домыслы по поводу того что и где ищет компилятор.
Таких домыслов там не было.
VD>Из них явно следует, что автор просто не знает языка и делает не верные предположения.
Соотв., из них ничего не могло следовать.
VD>Соответственно исправить "дефект" не представляется возможным.
Соотв., об исправлении даже никто не подумал
VD>На вопросы автор тоже не реагировал.
Потому что их никто не ждал ни секунды.
VD>Такие темы сразу же закрываются.
Вот и я про то же.
VD>Этот сумбур и домыслы никак не является описанием проблемы. В следующий раз остановись на том, что тебе не ясно сообщение об ошибке. Будет куда конструктивнее.
Это было в заголовке: "нехорошее сообщение об ошибке". Так что я на этом сразу же и остановился, никаких следующих разов и не нужно.
Плюс к этому, так как я не знаю, как работал компилятор, в #56 я указал конкретно, что оно не просто плохо, но ещё и не на то место.
VD>Да. Очевидно. Очевидно, что человек в компиляторе ничего не понимает, но пытается чего-то там предвидеть.
Я про внутренности компилятора ни слова не сказал. А где должна быть ошибка любому пользователю компилятора ясно, если он не погряз в дебрях условностей.
FDS>>то это — описание проблемы. Или для тебя ошибка не на той строке — это не проблема?
VD>Отвечаю последний раз. Это твои домыслы. По текущей логике работы компилятора ошибка на той строке, что нужно.
Так любой дефект можно убрать: "по текущей логике САУ здесь атомный реактор взрывается — это не дефект".
VD> Компилятор не может знать в какой из веток был возвращен неверный тип.
1. Это было учтено при написании дефекта #56, где я изложил всё подробнее
2. В данном случае вполне мог знать, и твой новый алгоритм даже должен это понять, насколько я его понял.
FDS>>Далее в #56 я указал, что компилятор возвращает мне не тот тип, которым может быть if. Это тоже не проблема?
VD>Ага проблема твоего понимания.
Понимания чего?
Это проблема твоего понимания, что то "как работает компилятор" не есть то, что однозначно хорошо.
FDS>>Какие ещё домыслы и предположения? Это компилятор так пишет, для него if возвращает int * int * int. FDS>>Читать надо внимательно
VD>Ага. Пишет. У него алгоритм такой. Это не ошибка.
"по текущей логике САУ здесь атомный реактор взрывается — это не дефект". Ну да, у неё алгоритм такой, а то, что кто-то говорит, что это не так, просто ламер.
VD>Ну, а то что сообщение не внятное — это отдельный вопрос. Никак не связанный с алгоритмом.
Только что ты говорил, что я нефига не понимаю алгоритма, и тут же, что вопрос этот не связан с алгоритмом. Ты уж определись.
VD> И путей решения проблемы тут несколько. Один из них — понять что происходит тебе.
И? От этого сообщение станет внятнее, а компилятор — умнее?
VD> Другой усложнить алгоритм (что может быть чревато другими проблемами), изменить сообщение чтобы оно давало больше информации.
VD> Там, кстати, еще hint выдается, которые подсказывает что происходит. Но ты его смело проигнорировал.
Он подсказывает ровно то же, что и само сообщение об ошибке. Естественно, всё поняв из сообщения об ошибке, я не стал дальше читать никаких хинтов — зачем мне на что-то ещё тратить время, если я вижу, где ошибка?
Здравствуйте, VladD2, Вы писали:
VD>Почему не может? Вроде как может. Но если даже не может, то это даже хоршо.
Не может
VD>Главное, что он может добавить комментарий в котором разяснить свою позицию (или связаться с админом по другим каналам).
Но он не знает, прочтёт ли кто-то этот комментарий после закрытия дефекта. Особенно если учесть, что сам по себе дефект был закрыт с бессмысленной и оскорбительной формулировкой.
FDS>>Тем более, если речь идёт о закрытии бага, который содержал описание "в котором трудно было что-то понять", судя по твоим же словам. Такие баги надо уточнять, благо ответы приходят на почту.
VD>Если был бы внятный ответ, то открыли бы.
Внятный ответ на бессодержательное сообщение? И я его должен постить в пустоту, не зная, будет он прочтён или нет?
VD>Это не проблема. Или завели бы другой issuse в котором уже было бы описано все правильно.
Ну я и завёл другой issue, чтобы на него обратили внимание, и описал там подробнее. Но его тоже закрыли не дожидаясь от меня никакой реакции.
VD>Тут еще вот что нужно понимать. Issuse-ы используются для формирования лога изменений в инсталляторах и как средство слежения за текущим состоянием проекта. По сему невнятной фигни в них быть не должно. Открытые issuse-ы должны отражать список проблем которые мы намереваемся решить. А закрытые и помеченные специальными тегами являются информацией о проделанной работе.
Это ваш неверный способ использования issue как списка todo, т.к. вы не привыкли, что к вам приходят сторонние пользователи и постят баги.
Очередной нонсенс, вызванный чувством собственности к языку.
FDS>>Если issue закрывают те, кто чинит ошибку, то у постера должно быть открыто право на reopen, т.к. именно и только постер может окончательно заключить, исправлена ошибка или нет.
VD>Ну, вот совсем недавно был случай. Починил я баг и закрыл его, так как считал, что все ОК. Но автор issuse-а обнаружил, что есть определенные случаи где баг все же проявляется. Он написал об этом соответствующее сообщение и я переоткрыл issuse.
Этот алгоритм работы закрытий-переоткрытий совершенно не очевиден человеку, который хоть сколько нибудь работал с багтрекерами в реальных проектах. Его надо описывать, чтобы ему можно было следовать.
VD>В твоем случае все будет несколько иначе. Так как сообщение совршенно не внятное, то будет создан новый issuse. Вопрос только какой. Если примем решение принять измененный алгоритм
, то создадим issuse-Фича-реквест описывающий этот алгоритм. В нем уже сошлемся на твой issuse, как на смежный. Если, же алгоритм окажется отклонен, то просто исправим сообщение об ошибке, и место его дислакации. При этом будет создан другой issuse, в котором будет описана проблема и принятое решение.
Безграмотное и нелогичное использование багтрекера, с какой стороны не посмотри.
В данном случае, если уж issue не внятный, его надо прояснить и закрыть, открыв два других, или отредактировать первоначальную версию, или открыть два других со перекрёстными ссылками, где всё внятно описано.
Если мы создаём вместо него другой issue, то он должен не отражать то, что "принято" или "не принято", а то, что должно быть (в данном случае, дефект на сообщение и фич-реквест на алгоритм вывода типов). Если алгоритм не будет принят, то issue по алгоритму должен быть отклонён, а по изменению сообщения об ошибке — исправлен и закрыт. При этом количество issue остаётся всегда одним и тем же, так как это issue определяют, что будет делаться, а не факт того, что что-то сделано или не сделано определяет наличие issue.
VD>В любом случае нам нужно полноценное описание чтобы те кто получит новую версию могли понять, что же за проблема была, и как ее устранили.
Согласен.
FDS>>Влад, я пользователь, и у меня свои проблемы. Куча других пользователей вообще плюёт на ошибки и пользуется бажным ПО годами, ленясь написать хоть что-то.
VD>Никто ни на что не плюет.
Плюют, и очень часто.
VD> Ну, не по-твему немного. Ничего страшного. Ты сам в этом виноват.
В том, что баги есть в компиляторе, issue используется извращёнными методами, а пользователям хамят — виноват явно не я.
VD>Иди сходи на багтреккеры МС. Погляди как там дела осбтоят. Там тебе вежливо ответят, что твое мнение услышано и точно так же закроют запись, только при этом ничего не объяснят.
Влад, у меня есть опыт постинга в Microsoft сообщений о багах. Там вежливо благодарят за найденный баг, если не поняли, переспрашивают, и указывают, что он будет исправлен в новом релизе, а не хамят и чего-то закрывают с сообщениями, что я нефига не понимаю.
VD>>>Если issue является непродуманным, ошибочным или того хуже, автору задаются наводящие вопросы. Если он не отвечат на них в течении какого-то времени, то issue закрывается с пометкой "Not a bug".
FDS>>Влад, мне никаких вопросов никто не задавал.
VD>О, как? А это что?
Это уже вопрос на второй дефект, причём он сразу был после этого закрыт, причём после этого я эту тему и открыл — т.е. ответ на этот вопрос разработчикам с моей стороны поступил. Поступил через форум, т.к. использование багтрекера разработчиками неадекватно.
FDS>>Влад, если поведение закрывающего неадекватно,
VD>Не тебе судить о поведении закрывающего.
Очень даже мне судить. Благо и сам баги закрывал, и заводил.
VD>Считаешь, что он ошибся — добавь сообщение в ту же тему.
Данный шаблон поведения не очевиден, мало того, я отказался от этого шаблона, т.к. в большинстве систем багтрекинга он был бы просто забыт.
VD>Или создай тему на форуме. Тут еще не было случаев когда кого-то игнорировали.
В итоге пришлось создать.
VD>А вот истерик и обвинений — не надо.
Истерик я тут не вижу, а вот обвинения здесь вполне уместны, т.к. поведение в багтрекере разработчиков неадекватно и оскорбительно.
YF>VladD2, разумеется, это увидел, оставил комментарий и закрыл его, справедливо полагая, что hardcase тебе уже все сказал. Другое дело, что тебя этот ответ не устроил.
В том то и дело, что пользователь вряд ли будет просто так открывать ещё один дефект. И "справедливо полагать" надо было то, что что-то не так и что-то не сказано, а пользователь почему-то не продолжил работу в предыдущем дефекте (видимо, были какие-то препятствия этому, о чём надо было задать вопрос). Затем прочитать оба дефекта и сделать нужные действия.
YF>Проблема в том, что закрывают issue и не ожидают обратной реакции того, кто issue создал.
Мало того, закрывают не разобравшись что к чему. Легкомысленно относятся к багтрекеру.
YF>Насчет хамства- ну побойся Б-га, он же совершенно бескорыстно возится тут со всеми, как с детьми малыми, развернуто отвечая на все вопросы и ничего не требуя взамен.
Хамства это не отменяет. В своё время я тоже кое с кем совершенно бескорыстно возился и был наделён полномочиями казнить и миловать, так что опыт есть. И если кто-то говорил, что я что-то не так сказал, мы это обсуждали с другим, таким же бескорыстным, человеком и, если приходили к тому, что я не прав, я официально извинялся и менял своё поведение.
Собственно, сам алгоритм, видимо, работает, однако сообщения об ошибках плохие.
public c(a: int): int
{
if (a == 1)
()
else
(1);
}
Данный код выдаёт ошибку "error : expected int, got void in function return value: void is not a subtype of int"
на строке с объявлением заголовка функции
Ожидается, что сообщение будет выдано на ветку. Фраза в данном случае устраивает
Аналогично
public c(a: int): int
{
def b()
{
if (a == 2)
1
else
();
}
if (a == 1)
b()
else
(1);
}
выдаёт ошибку "error : expected int, got void in computation branch: void is not a subtype of int"
на строке "if (a == 2)",
хотя в самом сообщении явно речь идёт о "computation branch"
Далее
public c2(a: int): void
{
def b()
{
if (a == 2)
1
else
();
}
if (a == 1)
b()
else
(1);
}
Выдаёт ошибку на "if (a == 2)" и на ветвях, что в принципе, вполне приемлемо. Причём ошибка не самого понятного для непосвящённого содержания:
"error : typing fails on delayed typing of conditional expression computation branchs"
Конечно, здесь идёт вложенный match, так что алгоритм в данной редакции и не должен понимать что как, но сообщение об ошибке лучше поправить на более понятное, если есть возможность.
Такой код
public c2(a: int): void
{
def b()
{
if (a == 2)
1
else
();
}
if (a == 1)
b()
else
();
}
вызывает вполне нормальное предупреждение
Плюс, не смог собрать сборку с помощью DevBuildForCommit.cmd . Почему-то лезет в каталог C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v9.0 , он существует, но 2008-ой студии на компе у меня нет и никогда не было и он не находит там файла с целями для билда. Пришлось дособирать DevBuildQuick-4.cmd, но вроде после этого всё равно алгоритм работает новый, насколько я могу судить.
Стало гораздо удобнее.
Здравствуйте, FDSC, Вы писали:
FDS>Собственно, сам алгоритм, видимо, работает, однако сообщения об ошибках плохие.
FDS>
FDS>public c(a: int): int
FDS>{
FDS> if (a == 1)
FDS> ()
FDS> else
FDS> (1);
FDS>}
FDS>
FDS>Данный код выдаёт ошибку "error : expected int, got void in function return value: void is not a subtype of int" FDS>на строке с объявлением заголовка функции FDS>Ожидается, что сообщение будет выдано на ветку. Фраза в данном случае устраивает
Некрасиво, конечно, но закономерно. Там ведь приведение типов идет.
Попробую подхимичить. Главное чтобы от этого не прибавилось тормозов.
FDS>Плюс, не смог собрать сборку с помощью DevBuildForCommit.cmd . Почему-то лезет в каталог C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v9.0 , он существует, но 2008-ой студии на компе у меня нет и никогда не было и он не находит там файла с целями для билда. Пришлось дособирать DevBuildQuick-4.cmd, но вроде после этого всё равно алгоритм работает новый, насколько я могу судить. FDS>Стало гораздо удобнее.
DevBuildForCommit.cmd собирает версию для 2008-й студии.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FDSC, Вы писали:
FDS>Собственно, сам алгоритм, видимо, работает, однако сообщения об ошибках плохие.
Переработал алгоритм еще раз. К сожалению, без ломающих изменений не обошлось. Новый алгоритм мне нравится больше, но он дал некоторые побочные эффекты. В сложных случаях может потребоваться аннотация типов. Но, зато, алгоритм стал умнее. Поддерживает приведения типов и "берет" типы из внешних выражений.
FDS>
FDS>public c(a: int): int
FDS>{
FDS> if (a == 1)
FDS> ()
FDS> else
FDS> (1);
FDS>}
FDS>
FDS>Данный код выдаёт ошибку "error : expected int, got void in function return value: void is not a subtype of int" FDS>на строке с объявлением заголовка функции FDS>Ожидается, что сообщение будет выдано на ветку. Фраза в данном случае устраивает
Фразу я кое-где поменял на "Cannot implicitly convert type 'А' to 'Б'.".
Все приведенные примеры теперь выдают вменяемые сообщения. Ну, по крайней мере, на мой взгляд .
Просьба протестировать что получилось.
ЗЫ
Любопытные могут наблюдать новое поведение компилятора в изменениях тестов. здесь и здесь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
