Не дает собрать компилятор из свн
Testing positive/bug-1158.n...failed
Unexpected Nemerle compiler's message :
positive/bug-1158.n:11:21:14:22: error: unbound type `matchobj.Groups["language"]'
Unexpected Nemerle compiler's message :
positive/bug-1158.n:11:21:14:22: error: unbound name `matchobj.Groups["language"].ToString'
Кто знает в чем дело ?
Re: Новая фича (надеюсь, последняя) - макрос Resource
Здравствуйте, _nn_, Вы писали:
__>Не дает собрать компилятор из свн
Просто измени расширение файла.
ЗЫ
А вообще, тесты для не исправленных ошибк нужно
класть в подкаталог, например — "fail".
Есть логика намерений и логика обстоятельств,
последняя всегда сильнее .
Re[2]: Новая фича (надеюсь, последняя) - макрос Resource
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _nn_, Вы писали:
__>>Не дает собрать компилятор из свн
VD>Просто измени расширение файла.
Ну до этого я додумался
VD>ЗЫ
VD>А вообще, тесты для не исправленных ошибк нужно
VD>класть в подкаталог, например — "fail".
Вот это я хотел узнать. Эта ошибка будет исправлена в ближайшее время или лучше ее в Bugs положить сейчас ?
Здравствуйте, _nn_, Вы писали:
__>Кто знает в чем дело ?
Макрос regexp match падает если его использовать в правой части оператора присваивания:
def x = regexp match(str) {
| "\d+" => "digits"
| "\w+" => "symbols"
| _ => "other"
}
Я сломал мозг но так и не понял как починить его.
/* иЗвиНите зА неРовнЫй поЧерК */
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, _nn_, Вы писали:
__>>Кто знает в чем дело ?
H>Макрос regexp match падает если его использовать в правой части оператора присваивания
При том не всегда.
Пример выше например вполне рабочий.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[2]: Новая фича (надеюсь, последняя) - макрос Resource
Здравствуйте, VladD2, Вы писали:
VD>А вообще, тесты для не исправленных ошибк нужно
VD>класть в подкаталог, например — "fail".
Ок. Буду иметь в виду.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[3]: Новая фича (надеюсь, последняя) - макрос Resource
Здравствуйте, _nn_, Вы писали:
__>Вот это я хотел узнать. Эта ошибка будет исправлена в ближайшее время или лучше ее в Bugs положить сейчас ?
Можно и в Bugs. Там сейчас тольконеисправимыебаги, но их там ровно один, так что не запутаемся.
Есть логика намерений и логика обстоятельств,
последняя всегда сильнее .
Здравствуйте, _nn_, Вы писали:
__>Не дает собрать компилятор из свн
__>__> Testing positive/bug-1158.n...failed
__> Unexpected Nemerle compiler's message :
__> positive/bug-1158.n:11:21:14:22: error: unbound type `matchobj.Groups["language"]'
__> Unexpected Nemerle compiler's message :
__> positive/bug-1158.n:11:21:14:22: error: unbound name `matchobj.Groups["language"].ToString'
__>Кто знает в чем дело ?
Сейчас покрутил пример. Если явно прописать тип, то компиляция проходит:
def get_language(paths : list[string] ) {
mutable result;
foreach (path in paths) {
result =
regexp match (path.ToLower()) {
| @"file-(?<lang>..)\.txt" => lang
| _ => "none"
}
}
result
}
WriteLine(get_language([ "file-fr.txt" ]));
Переписывание цикла в рекурсию также помогает:
def get_language(paths) {
mutable result;
def walk(paths) {
| [] => ();
| path :: paths =>
result =
regexp match (path.ToLower()) {
| @"file-(?<lang>..)\.txt" => lang
| _ => "none"
}
walk(paths);
}
walk(paths);
result
}
WriteLine(get_language([ "file-fr.txt" ]));
Может быть дело в foreach ?
/* иЗвиНите зА неРовнЫй поЧерК */
Здравствуйте, hardcase, Вы писали:
H>Сейчас покрутил пример.
Использование Iter тоже не приводит к ошибкам:
def get_language(paths) {
mutable result;
paths.Iter(fun(path) {
result =
regexp match (path.ToLower()) {
| @"file-(?<lang>..)\.txt" => lang
| _ => "none"
}
});
result
}
WriteLine(get_language([ "file-fr.txt" ]));
/* иЗвиНите зА неРовнЫй поЧерК */
Здравствуйте, hardcase, Вы писали:
H>Может быть дело в foreach ?
Наверное с типизацией что-то.
Или foreach или regexp match не типизируют выражение.
Минимализируем пример.
def f(paths)
{
foreach (path in paths)
{
_ = regexp match (path) { | "(?<a>.*)" => a | _ => "x" }
}
}
f(["a" ]);
Тут не срабатывает
А так работает
foreach (path in ["a" ])
{
_ = regexp match (path) { | "(?<a>.*)" => a | _ => "x" }
}
Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, hardcase, Вы писали:
H>>Может быть дело в foreach ?
__>Наверное с типизацией что-то.
__>Или foreach или regexp match не типизируют выражение.
Нашел причину появления сообщения. Видимо по какой-то причине при типизации тела foreach-макрос передает управление ветке, соответствующей InErrorMode:
if (ctx.InErrorMode && !ctx.Manager.IsIntelliSenseMode) {
<[ // ВОТ СЮДА
ignore ($val : string);
match (false) {
| true => $(build_checking (alternatives))
| _ => $defexpr
}
]>
}
else {
def tb = tb.DefineNestedType (<[ decl:
private module $(static_regobj : name) {
public $(value : name) : Regex =
Regex ( $(pat.ToString () : string), RegexOptions.ExplicitCapture %| RegexOptions.Compiled );
}
]>);
tb.Compile ();
<[
def matchobj = $(static_regobj : name).$(value : name).Match ($val);
match (matchobj.Success) {
| true => $(build_checking (alternatives))
| _ => $defexpr
}
]>
Видно что переменная matchobj не объявляется, но код для сопоставления всеравно генерируется.
/* иЗвиНите зА неРовнЫй поЧерК */
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, _nn_, Вы писали:
__>>Здравствуйте, hardcase, Вы писали:
H>>>Может быть дело в foreach ?
__>>Наверное с типизацией что-то.
__>>Или foreach или regexp match не типизируют выражение.
H>Нашел причину появления сообщения. Видимо по какой-то причине при типизации тела foreach-макрос передает управление ветке, соответствующей InErrorMode:
В общем это все кино происходит из-за того, что форич не может с первого раза типизировать выражение paths. В последующих вызовах колбэка DelayMacro даже при успешной типизации paths тело форича тем не менее разворачивается в режиме InErrorMode. Как разрулить эту ситуацию?
/* иЗвиНите зА неРовнЫй поЧерК */
Здравствуйте, hardcase, Вы писали:
Fixed .
/* иЗвиНите зА неРовнЫй поЧерК */
Пока на собственное сообщение не было ответов, его можно удалить.
Удалить