Linq+Февральский СТР
От: Flem1234  
Дата: 28.02.08 11:18
Оценка: 10 (1)
У меня этот код при компиляции выдает ошибку:
Error 1 there is no member named `Where' in list.Cons[int-] with type ?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Console;

module Program
{
  Main() : void
  {
    def l = [1, 2, 3, 4, 5];
    def r = l.Where(i=> i%2 ==0);
    WriteLine($"..$r");
    _ = ReadKey();
  }
}
Re: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 28.02.08 14:12
Оценка:
Здравствуйте, Flem1234, Вы писали:

F>У меня этот код при компиляции выдает ошибку:

F>Error 1 there is no member named `Where' in list.Cons[int-] with type ?
F>
F>using System;
F>using System.Collections.Generic;
F>using System.Linq;
F>using System.Console;

F>module Program
F>{
F>  Main() : void
F>  {
F>    def l = [1, 2, 3, 4, 5];
F>    def r = l.Where(i=> i%2 ==0);
F>    WriteLine($"..$r");
F>    _ = ReadKey();
F>  }
F>}
F>


LINQ'овские extension methods работают на лямбдах-делегатах. Коими не являются немерловые лямбды. Я над этим как-то уже думал. Может быть, что-то и удастся придумать.
--
Re[2]: Linq+Февральский СТР
От: Flem1234  
Дата: 28.02.08 15:13
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:

СТ>LINQ'овские extension methods работают на лямбдах-делегатах. Коими не являются немерловые лямбды. Я над этим как-то уже думал. Может быть, что-то и удастся придумать.


Но в ноябрьской интеграции все работало, я пробывал, и на формуме Nemerle есть пост
Автор: VladD2
Дата: 27.11.07
на эту тему. Разве компилятор не должен сам приводить функции Nemerle к делегатам?
Re[3]: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 28.02.08 15:17
Оценка:
Здравствуйте, Flem1234, Вы писали:

F>Но в ноябрьской интеграции все работало, я пробывал, и на формуме Nemerle есть пост
Автор: VladD2
Дата: 27.11.07
на эту тему. Разве компилятор не должен сам приводить функции Nemerle к делегатам?


Вот как, это даже работало? Посмотрю.
--
Re[2]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.08 15:36
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:

СТ>LINQ'овские extension methods работают на лямбдах-делегатах. Коими не являются немерловые лямбды. Я над этим как-то уже думал. Может быть, что-то и удастся придумать.


Ерунду говоришь. В Немерле автоматическое конвертирование из функциональных типов в делегаты.

Почти 100%, что баг в твоем коде. Раньше подобный код работал на ура. По крайне мере так:
using System.Linq;
using System.Console;

module Program
{
  Main() : void
  {
    def l = [1, 2, 3, 4, 5];
    def r = Enumerable.Where(l, i => i % 2 == 0);
    WriteLine($"..$r");
    _ = ReadKey();
  }
}

все работает.

Учитывая варнинги что теперь выдает компилятор, твой код надо откатывать. Писать тесты и уже потом думать, что и как делать.

А на будущее, надо делать тесты прежде чем комитить фичи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.08 15:47
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:

F>>Но в ноябрьской интеграции все работало, я пробывал, и на формуме Nemerle есть пост
Автор: VladD2
Дата: 27.11.07
на эту тему. Разве компилятор не должен сам приводить функции Nemerle к делегатам?


СТ>Вот как, это даже работало? Посмотрю.


Скромный вопрос. А что ты там правил, если даже не знал, что функциональность уже есть?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 28.02.08 16:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Сергей Туленцев, Вы писали:


СТ>>Вот как, это даже работало? Посмотрю.


VD>Скромный вопрос. А что ты там правил, если даже не знал, что функциональность уже есть?


А с линком и делегатами я ничего не делал.
... << RSDN@Home 1.2.0 alpha rev. 788>>
--
Re[3]: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 28.02.08 16:40
Оценка:
VD>Учитывая варнинги что теперь выдает компилятор, твой код надо откатывать. Писать тесты и уже потом думать, что и как делать.

VD>А на будущее, надо делать тесты прежде чем комитить фичи.


Делать — в смысле, писать? Так откуда ж я знал, что он на лямбды повлияет?
Делать — в смысле, прогонять? Так прогонял.
... << RSDN@Home 1.2.0 alpha rev. 788>>
--
Re[3]: Linq+Февральский СТР
От: Иванков Дмитрий Россия  
Дата: 28.02.08 16:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Почти 100%, что баг в твоем коде. Раньше подобный код работал на ура.

+1
Сдается мне, что это оно
Index: internal.n
===================================================================
--- internal.n    (revision 7892)
+++ internal.n    (revision 7893)
@@ -216,6 +216,14 @@
   }
 }
 
+namespace System.Runtime.CompilerServices
+{
+    [System.AttributeUsage (System.AttributeTargets.Class|System.AttributeTargets.Method)]
+    public class ExtensionAttribute : Attribute
+    {}
+}
+
+
 namespace Nemerle.Utility
 {
   public class Identity ['a, 'b] : Builtins.Function ['a, 'b] where 'a : 'b


VD>Учитывая варнинги что теперь выдает компилятор, твой код надо откатывать. Писать тесты и уже потом думать, что и как делать.

Какие кстати.. или не ворнинги, а ошибки?

VD>А на будущее, надо делать тесты прежде чем комитить фичи.

Да, надо добавить тест на использование внешних Extension методов, обломалось-то именно оно.

Как поаккуратнее это разгрести еще подумать надо, т.к. boot, как оказалось, сейчас корявый.
Самое простое конечно — откатить целиком, если при этом trunk выйдет адекватный (вроде должно быть нормально все, врядли есть код, который зависит от внесенных изменений).
Re[4]: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 28.02.08 17:07
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Здравствуйте, VladD2, Вы писали:



ИД>Как поаккуратнее это разгрести еще подумать надо, т.к. boot, как оказалось, сейчас корявый.

ИД>Самое простое конечно — откатить целиком, если при этом trunk выйдет адекватный (вроде должно быть нормально все, врядли есть код, который зависит от внесенных изменений).

Кажется, я знаю, как разгрести, не откатывайте пока что.
... << RSDN@Home 1.2.0 alpha rev. 788>>
--
Re[5]: Linq+Февральский СТР
От: Иванков Дмитрий Россия  
Дата: 28.02.08 17:25
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Здравствуйте, Иванков Дмитрий, Вы писали:


ИД>>Здравствуйте, VladD2, Вы писали:



ИД>>Как поаккуратнее это разгрести еще подумать надо, т.к. boot, как оказалось, сейчас корявый.

ИД>>Самое простое конечно — откатить целиком, если при этом trunk выйдет адекватный (вроде должно быть нормально все, врядли есть код, который зависит от внесенных изменений).

СТ>Кажется, я знаю, как разгрести, не откатывайте пока что.


Ест-но, самим-то откатывать неинтересно , ждем
Re[6]: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 28.02.08 18:17
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

СТ>>Кажется, я знаю, как разгрести, не откатывайте пока что.


ИД>Ест-но, самим-то откатывать неинтересно , ждем


Кстати, хотел как-то у тебя спросить что-то, так твоих контактов нигде не нашел. На мойкруге пустой профиль у тебя. Поделись контактами скайпа и аськи, а?
... << RSDN@Home 1.2.0 alpha rev. 788>>
--
Re[7]: Linq+Февральский СТР
От: Иванков Дмитрий Россия  
Дата: 28.02.08 19:11
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Кстати, хотел как-то у тебя спросить что-то, так твоих контактов нигде не нашел. На мойкруге пустой профиль у тебя. Поделись контактами скайпа и аськи, а?

Добавил аську туда. Ну и почта всегда есть
Re[6]: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 28.02.08 21:22
Оценка: 207 (9)
Здравствуйте, Иванков Дмитрий, Вы писали:

СТ>>Кажется, я знаю, как разгрести, не откатывайте пока что.


ИД>Ест-но, самим-то откатывать неинтересно , ждем


Починил. В качестве полезного бонуса оказалось вот что:
— убрался тот ворнинг про ambiguous type в проекте интеграции.
— стало доступным поведение как у VS2008 в режиме совместимости с .NET 2.0: если при компиляции будет доступен атрибут System.Runtime.CompilerServices.ExtensionAttribute (либо импортированный из System.Core, либо определеный в коде), то extension methods будут им помечены и, как результат, их можно будет использовать из сишарпа.

На самом деле, так надо было с самого начала делать, но тогда не сумел.

Добавил также тест. Только тут опять не всё гладко. Не получилось заставить tests.exe заставить компилятор зареференсить System.Core, которая лежит в GAC. Поэтому, в качестве временного решения, пришлось её подложить туда, в папочку. Если кто знает, как это сделать, буду очень признателен.
... << RSDN@Home 1.2.0 alpha rev. 788>>
--
Re[7]: Linq+Февральский СТР
От: Иванков Дмитрий Россия  
Дата: 29.02.08 05:32
Оценка: 14 (1) +1
Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Добавил также тест. Только тут опять не всё гладко. Не получилось заставить tests.exe заставить компилятор зареференсить System.Core, которая лежит в GAC. Поэтому, в качестве временного решения, пришлось её подложить туда, в папочку. Если кто знает, как это сделать, буду очень признателен.


В качестве теста можно сделать затычку с определенными в ней атрибутом и методами-расширениями.
Примерно так:
using SCG = System.Collections.Generic;
using SRCS = System.Runtime.CompilerServices;
using SAT = System.AttributeTargets;

namespace System
{
 namespace Runtime.CompilerServices
 {
  [System.AttributeUsage (SAT.Class | SAT.Method)]
  public class ExtensionAttribute : Attribute
  {}
 }
 public delegate Func[T, TResult] (arg : T) : TResult;
 namespace Linq
 {
  [SRCS.ExtensionAttribute]
  public module Enumerable
  {
    [SRCS.ExtensionAttribute]
    public Where[TSource] (
      source : SCG.IEnumerable[TSource], 
      predicate : Func[TSource, bool]
    ) : SCG.IEnumerable[TSource]
    {
      foreach (x in source)
      when (predicate(x))
        yield x;
    }
  }
 }
}

[Nemerle.Internal.ExtensionAttribute]
public module Test2
{
  [Nemerle.Internal.ExtensionAttribute]
  public Where2[T] (
    source : SCG.IEnumerable[T], 
    pred : T->bool
  ) : SCG.IEnumerable[T]
  {
    foreach (x in source)
    when (pred(x))
      yield x;
  }
}

public module Test3
{
  public Where3[T] (
    this source : SCG.IEnumerable[T], 
    pred : T->bool
  ) : SCG.IEnumerable[T]
  {
    foreach (x in source)
    when (pred(x))
      yield x;
  }
}

using System.Collections.Generic;
using System.Linq;
using System.Console;

module Program
{
  Main() : void
  {
    def l = [1, 2, 3, 4, 5];
    def r = l.Where(i=> i%2 ==0);
    WriteLine($"..$r");
    def r = l.Where2(i=> i%2 ==0);
    WriteLine($"..$r");
    def r = l.Where3(i=> i%2 ==0);
    WriteLine($"..$r");
  }
}
/*
REFERENCE: external-extension-method-lib

BEGIN-OUTPUT
2, 4
2, 4
2, 4
END-OUTPUT
*/


Вроде как ничего страшного не делается, т.к. тест с настоящей System.Core.dll не пересекается.
Под Mono надо еще проверить и из C# поиспользовать, и, конечно, с/без System.Core.dll в системе.
В общем, кому не лень — киньте это у себя в тесты и проверьте что работает
Да, если будет вопить про переопределение ExtensionAttribute, то значит цепляется бажная версия компилера.
Re[6]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.02.08 10:42
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:

СТ>А с линком и делегатами я ничего не делал.


Причем тут линк и делегаты. Речь идет о поддержке анонимных методов (именно на нужна для поддержки LINQ to Objects). Ранее она работала. Код написал еще Москаль. Написал чуть ли не год назад. Твои изменения его убили.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.02.08 10:58
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:

VD>>Учитывая варнинги что теперь выдает компилятор, твой код надо откатывать. Писать тесты и уже потом думать, что и как делать.


VD>>А на будущее, надо делать тесты прежде чем комитить фичи.


СТ>Делать — в смысле, писать? Так откуда ж я знал, что он на лямбды повлияет?


Какие еще лямбды? Это твое
Автор: Сергей Туленцев
Дата: 12.02.08
сообщение? Вот это и угробило "поддержку LINQ-а", так как она вся заключалась в том, что Немерле поддерживал методы-расширения из C# 3.0/

СТ>Делать — в смысле, прогонять? Так прогонял.


И прогонять и добавлять.

ЗЫ

Еще раз. Лябмды тут не причем. Ты угробил логику позволявшую подхватывать методы-расширения написанные на C# 3.0.
Теперь что надо делать. Надо откатывать твои изменения. Если ты хочешь что-то там добавить, то сначала надо сделать тесты проверяющие, что методы-расширения написанные на C# 3.0 работают, а потом вносить твои изменения и думать над тем, чтобы они не убили имеющийся функционал.

Раньше была такая логика. Если к проекту подключена сборка в которой объявлен атрибут System.Runtime.CompilerServices.ExtensionAttribute, то при подключении сборок производилась попытка найти в них методы-расширения помеченные этим атрибутом. Так же производилась попытка найти методы помеченные Немерловым атрибутом Nemerle.Internal.ExtensionAttribute, который использовался для немерловых методов.

Собственно сейчас основной вопро, что за изменения ты внес и почему они привели к неработоспособности прошлой схемы?
Опиши, что ты добавлял и зачем, плиз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 29.02.08 11:02
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Сергей Туленцев, Вы писали:


СТ>>А с линком и делегатами я ничего не делал.


VD>Причем тут линк и делегаты. Речь идет о поддержке анонимных методов (именно на нужна для поддержки LINQ to Objects). Ранее она работала. Код написал еще Москаль. Написал чуть ли не год назад. Твои изменения его убили.


Не делал я ничего с анонимными методами. Мои изменения убили рапознавание extension methods из подключаемых сборок как extension methods. Вот и всё.
... << RSDN@Home 1.2.0 alpha rev. 788>>
--
Re[4]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.02.08 11:06
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Сдается мне, что это оно

ИД>
 
ИД>+namespace System.Runtime.CompilerServices
ИД>+{
ИД>+    [System.AttributeUsage (System.AttributeTargets.Class|System.AttributeTargets.Method)]
ИД>+    public class ExtensionAttribute : Attribute
ИД>


Да, видимо это и привело к тому, что компилятор перестал обнаруживать методы описанные с атрибутом из сборки System.Core, так как стал находить такой же атрибут в коде компилятора. Там используется метод IsDefined который по всей видимости проверяет наличие конкретного атрибута (а не атрибута с похожим именем).
public IsExtension (attrsProvider : System.Reflection.ICustomAttributeProvider) : bool
{
  SystemTypeCache.ExtensionAttribute != null && attrsProvider.IsDefined (SystemTypeCache.ExtensionAttribute, false) ||
  SystemTypeCache.SQ_ExtensionAttribute != null && attrsProvider.IsDefined (SystemTypeCache.SQ_ExtensionAttribute, false)
}


VD>>Учитывая варнинги что теперь выдает компилятор, твой код надо откатывать. Писать тесты и уже потом думать, что и как делать.

ИД>Какие кстати.. или не ворнинги, а ошибки?

А как раз ворнинг о том, что найдено два атрибута System.Runtime.CompilerServices.ExtensionAttribute и что будет использоваться первый из них.

VD>>А на будущее, надо делать тесты прежде чем комитить фичи.

ИД>Да, надо добавить тест на использование внешних Extension методов, обломалось-то именно оно.

+1 Но это не так просто, так как он требует наличия сборки System.Core. Видимо ее надо закомитить вместе с этим тестом.

ИД>Как поаккуратнее это разгрести еще подумать надо, т.к. boot, как оказалось, сейчас корявый.


Слава богу мы нигде в компиляторе не использовали внешних методов-расширений. Так что по идее должно все скомпилиться. Или нет?

ИД>Самое простое конечно — откатить целиком, если при этом trunk выйдет адекватный (вроде должно быть нормально все, врядли есть код, который зависит от внесенных изменений).


А можно откатить изменения только этой версии? Ну, так чтобы последующие таки остались?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 29.02.08 11:13
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Собственно сейчас основной вопро, что за изменения ты внес и почему они привели к неработоспособности прошлой схемы?

VD>Опиши, что ты добавлял и зачем, плиз.

Починил уже. Читай в том топике.
... << RSDN@Home 1.2.0 alpha rev. 788>>
--
Re[8]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.02.08 16:41
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>В качестве теста можно сделать затычку с определенными в ней атрибутом и методами-расширениями...

ИД>Вроде как ничего страшного не делается, т.к. тест с настоящей System.Core.dll не пересекается.

Ага. Но надо иметь и тест с System.Core.dll.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.02.08 16:45
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:

СТ>...На самом деле, так надо было с самого начала делать, но тогда не сумел.


+1 Я тебе об этом и говорил, но ты тогда меня не понял видимо.

СТ>Добавил также тест. Только тут опять не всё гладко. Не получилось заставить tests.exe заставить компилятор зареференсить System.Core, которая лежит в GAC. Поэтому, в качестве временного решения, пришлось её подложить туда, в папочку. Если кто знает, как это сделать, буду очень признателен.


Сослаться на сборку из гака очень легко если используется студийный проект. В нам достаточно указать имя сборки без расширения.

Но для твоего случая как раз это делать не надо! Дело в том, что тест должен работать и на втором фрэймворке (где нет этой длл). Так что просто закомить ее как часть теста. Можно положить ее в подкаталог и сослаться с помощью относительного пути.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 29.02.08 18:45
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Сослаться на сборку из гака очень легко если используется студийный проект. В нам достаточно указать имя сборки без расширения.


Так в том-то и дело, что используется не студийный проект. Я вчера целый час потратил на то, чтобы разобраться, как к тестам подключать сборки.

VD>Но для твоего случая как раз это делать не надо! Дело в том, что тест должен работать и на втором фрэймворке (где нет этой длл). Так что просто закомить ее как часть теста. Можно положить ее в подкаталог и сослаться с помощью относительного пути.

Ну так я так и сделал. Ты это можешь увидеть, посмотрев логи.
... << RSDN@Home 1.2.0 alpha rev. 788>>
--
Re[9]: Linq+Февральский СТР
От: Иванков Дмитрий Россия  
Дата: 29.02.08 19:12
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Здравствуйте, VladD2, Вы писали:


VD>>Но для твоего случая как раз это делать не надо! Дело в том, что тест должен работать и на втором фрэймворке (где нет этой длл). Так что просто закомить ее как часть теста. Можно положить ее в подкаталог и сослаться с помощью относительного пути.

СТ>Ну так я так и сделал. Ты это можешь увидеть, посмотрев логи.

Ага, а я потом снесу , как только одно из двух:
— станет ясно как врубить ссылку на Gac или еще через какое-нибудь место притянуть System.Core.dll
— сделаю тест по-другому, например заставив компилятор ругаться на множественное наличие этого атрибута (уже почти, осталось подводные камни потестить).

Хранить чужой бинарник ради одного теста конечно же не дело (да и непонятно как это с правовой точки зрения выглядит).
Re[10]: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 29.02.08 19:22
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:


ИД>Ага, а я потом снесу , как только одно из двух:

ИД>- станет ясно как врубить ссылку на Gac или еще через какое-нибудь место притянуть System.Core.dll
ИД>- сделаю тест по-другому, например заставив компилятор ругаться на множественное наличие этого атрибута (уже почти, осталось подводные камни потестить).

Так там же не надо ничего делать специально. Оно само ругается. Это тот ворнинг, про который Влад говорил.
... << RSDN@Home 1.2.0 alpha rev. 788>>
--
Re[11]: Linq+Февральский СТР
От: Иванков Дмитрий Россия  
Дата: 29.02.08 19:43
Оценка:
Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Так там же не надо ничего делать специально. Оно само ругается. Это тот ворнинг, про который Влад говорил.


При компиляции из консоли вроде ж не ругалось, иначе было бы не "Error 1 there is no member named `Where' in list.Cons[int-] with type ?", а "warning: он самый + error", еще посмотрю.
Может это студия ругалась, т.к. я этот warning так и не видел, хотя я мог просто упустить его из вида
Re[12]: Linq+Февральский СТР
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 29.02.08 20:03
Оценка: +1
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Здравствуйте, Сергей Туленцев, Вы писали:


СТ>>Так там же не надо ничего делать специально. Оно само ругается. Это тот ворнинг, про который Влад говорил.


ИД>При компиляции из консоли вроде ж не ругалось, иначе было бы не "Error 1 there is no member named `Where' in list.Cons[int-] with type ?", а "warning: он самый + error", еще посмотрю.

ИД>Может это студия ругалась, т.к. я этот warning так и не видел, хотя я мог просто упустить его из вида

Он был в старой версии, при компиляции проекта интеграции.
... << RSDN@Home 1.2.0 alpha rev. 788>>
--
Re[10]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.03.08 05:00
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Ага, а я потом снесу , как только одно из двух:

ИД>- станет ясно как врубить ссылку на Gac или еще через какое-нибудь место притянуть System.Core.dll

Не надо сносить! Еще раз повторяю: Компилятор обязан компилироваться со вторым фрэймворком, где этой ДЛЛ нет. По сему ее надо просто хранить в проекте. За одно она будет полезна при тестировании других фич линка которые еще только предстоит реализовать.

ИД>- сделаю тест по-другому, например заставив компилятор ругаться на множественное наличие этого атрибута (уже почти, осталось подводные камни потестить).


Компилятор и так ругается. Но какое это имеет отношение, например, к данному прецеденту деградации функциональности?

ИД>Хранить чужой бинарник ради одного теста конечно же не дело (да и непонятно как это с правовой точки зрения выглядит).


Надо. Ничего страшного в нем нет. Собственно, по большому счету этот бинарник и отличает 2-ой фрэймворк от 3.5-го.

В общем, не трогай его.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.03.08 05:02
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>При компиляции из консоли вроде ж не ругалось,...


Естественно, так как теперь атрибут присутствует в одном экземпляре. Раньше же он был как в Nemerle.dll сборке, так и в System.Core.dll, что приводило к выдаче ворнига при попытке скомпилироваться с этой сборкой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Linq+Февральский СТР
От: Иванков Дмитрий Россия  
Дата: 04.03.08 05:46
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Не надо сносить! Еще раз повторяю: Компилятор обязан компилироваться со вторым фрэймворком, где этой ДЛЛ нет.

Да, в частности под mono тоже
VD>По сему ее надо просто хранить в проекте. За одно она будет полезна при тестировании других фич линка которые еще только предстоит реализовать.
К общим юниттестам компилятора это отношения не имеет:
1) почти всегда можно нарисовать короткий тест без нее
2) никакого желания при каждом обломе теста лезть в дебри этой либы и в ее спецификации нет.

VD>Компилятор и так ругается. Но какое это имеет отношение, например, к данному прецеденту деградации функциональности?

Теперь ругается. А раньше — не всегда, на тесте: fw2+system.core+another_attr(в себе) молчал про проигнорированный атрибут.
И теперь при левом атрибуте в самом компиляторе/в зависимостях отвалится нужный тест/будет соответствующее сообщение.

VD>Надо. Ничего страшного в нем нет. Собственно, по большому счету этот бинарник и отличает 2-ой фрэймворк от 3.5-го.

И зачем нам это отличие у себя хранить?
Опять же в правовую сторону: на каких основаниях, под какой лицензией?

VD>В общем, не трогай его.

Уже снес и написал эквивалентный тест, и пока не вижу смысла возвращать.
Если край надо уметь писать набор тестов с зависимостью от него, то надо делать именно это: сделать отдельную пачку тестов и научиться ставить зависимость от System.Core.dll из системы (хоть костылем вроде "%ProgramFiles%\Reference Assemblies\Microsoft\..." если уж совсем никак не получится). Отдельной она может даже не быть, т.к. при неподгружаемой библиотеке тест пропускается.
Re[12]: Linq+Февральский СТР
От: Аноним  
Дата: 04.03.08 07:10
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>...и научиться ставить зависимость от System.Core.dll из системы...


А тут все просто, надо указывать не "System.Core", а ее полное имя, что в общем-то логично.
Примерно такое "System.Core, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".

P.S. это я же
Re[12]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.03.08 13:43
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Может это студия ругалась, т.к. я этот warning так и не видел, хотя я мог просто упустить его из вида


Студия использует компилятор. Сама она ругаться не обучена.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.03.08 13:55
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

VD>>Не надо сносить! Еще раз повторяю: Компилятор обязан компилироваться со вторым фрэймворком, где этой ДЛЛ нет.

ИД>Да, в частности под mono тоже

Это обычная ДЛЛ, так что и с Моно она обязана работать.

VD>>По сему ее надо просто хранить в проекте. За одно она будет полезна при тестировании других фич линка которые еще только предстоит реализовать.

ИД>К общим юниттестам компилятора это отношения не имеет:
ИД>1) почти всегда можно нарисовать короткий тест без нее
ИД>2) никакого желания при каждом обломе теста лезть в дебри этой либы и в ее спецификации нет.

Туда лезть и не надо. Ошибки ведь у нас. И вообще, это какие-то отмазки. Тебе никто не запрещает кроме тестов с этой ДЛЛ сделать и более поверхностные тесты.

В общем, верни тест с этой ДЛЛ обратно, плиз.

VD>>Компилятор и так ругается. Но какое это имеет отношение, например, к данному прецеденту деградации функциональности?

ИД>Теперь ругается. А раньше — не всегда, на тесте: fw2+system.core+another_attr(в себе) молчал про проигнорированный атрибут.

Он ругался когда атрибуты были в разных сборках. Боюсь что теперь в таких условиях ругань будет удваиваться.

ИД>И теперь при левом атрибуте в самом компиляторе/в зависимостях отвалится нужный тест/будет соответствующее сообщение.


И где гарантиях, что при наличии атрибутов в двух сборках не будет двойного сообщения?

VD>>Надо. Ничего страшного в нем нет. Собственно, по большому счету этот бинарник и отличает 2-ой фрэймворк от 3.5-го.

ИД>И зачем нам это отличие у себя хранить?

Чтобы тем кто тесты ганяет на втором фрэймворе или Моно не вываливались сообщения об ошибках на ровном месте. И, если снова кто-то что-то поломает, чтобы мы об этом узнали сразу.

ИД>Опять же в правовую сторону: на каких основаниях, под какой лицензией?


На основании того, что приложение (тест) использует эту сборку. И вообще, это уже балшит. Вот когда МС через суд докажет, что так делать нельзя, то поговорим.

VD>>В общем, не трогай его.

ИД>Уже снес и написал эквивалентный тест, и пока не вижу смысла возвращать.

Вижу и мне это очень не нравится. Ни фига он не эквивалентный! Он синтетический, а значит не дающий гарантии.

ИД>Если край надо уметь писать набор тестов с зависимостью от него, то надо делать именно это: сделать отдельную пачку тестов и научиться ставить зависимость от System.Core.dll из системы (хоть костылем вроде "%ProgramFiles%\Reference Assemblies\Microsoft\..." если уж совсем никак не получится). Отдельной она может даже не быть, т.к. при неподгружаемой библиотеке тест пропускается.


Не над из системы. Все должно быть автономно! И тесты отдельные на фиг не уперлись. Там каждый отдельный файл это отдельный тест. В общем, верни назад длл-ку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Linq+Февральский СТР
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.03.08 14:13
Оценка:
Кстати, ты почту читаешь... ту что указана в профайле? Если нет, то напиши мне на мыло, чтобы у меня был твое работающее мыло.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Linq+Февральский СТР
От: Иванков Дмитрий Россия  
Дата: 04.03.08 17:39
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Он ругался когда атрибуты были в разных сборках.

Нет, не всегда, легко проверить: тест negative/external-extensions.n компилятор ревизии 7891 не проходит.
Однако наконец-то нашел это предупреждение, когда именно возникает и почему не возникло строчкой выше — todo.

VD>И где гарантиях, что при наличии атрибутов в двух сборках не будет двойного сообщения?

Будет, "warn: attr from 1 ignored", "hint: attr first defined in 0", "warn: attr from 2 ignored", "warn: attr from 3 ignored".
Т.е. полная и не избыточная информация, little todo — выше.

VD>Чтобы тем кто тесты ганяет на втором фрэймворе или Моно не вываливались сообщения об ошибках на ровном месте.

Они не будут вываливаться, как не вываливается positive/gtk.n.

VD>И, если снова кто-то что-то поломает, чтобы мы об этом узнали сразу.

Сразу не выйдет, т.к. весь интероп nemerle и system.core не покрыт тестами
А как узнаем — все равно надо локализовать проблему, найти причину и сделать микротест, явно демонстрирующий и проверяющий проблему, и, возможно, посмотреть давно ли эта проблема существует.

VD>Вижу и мне это очень не нравится. Ни фига он не эквивалентный! Он синтетический, а значит не дающий гарантии.

Более того, нет тестов с гарантиями.
Однако ж гораздо правильнее проверять не "ncc дружит с данной конкретной либой", а "ncc поддерживает такие-то общие фишки, благодаря которым можно дружить с этой либой". System.Core в репозитории — костыль, не более того.

VD>Не над из системы.

FullName на то и FullName чтобы однозначно идентифицировать эту загогулину, если хочется ее тестить, то и ссылаться на нее стоит именно так. (да, в сообщении выше я на system.core из беты судя по всему ссылку дал, а правильное имя легко подсмотреть в гаке)

VD>... В общем, верни назад длл-ку.

В общем, я против наличия этой (и любой другой) dll в репозитории и это мое, так сказать, заднее слово.

Тесты с ссылкой по FullName — пожалуйста, обнаруженные глюки в трекер — сколько угодно, можно даже сразу на меня вешать
Re[13]: Linq+Февральский СТР
От: Иванков Дмитрий Россия  
Дата: 04.03.08 17:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Кстати, ты почту читаешь... ту что указана в профайле? Если нет, то напиши мне на мыло, чтобы у меня был твое работающее мыло.

Очевидно, что да, я ж с нее пишу в рассылку
Другое дело что только по мере возможности, но тут ничего не поделать.
Re[14]: Linq+Февральский СТР
От: Иванков Дмитрий Россия  
Дата: 04.03.08 18:50
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Здравствуйте, VladD2, Вы писали:


VD>>Кстати, ты почту читаешь... ту что указана в профайле? Если нет, то напиши мне на мыло, чтобы у меня был твое работающее мыло.

ИД>Очевидно, что да, я ж с нее пишу в рассылку

О, не так очевидно, там один редирект происходит, сорри.., в общем всю почту читаю
Re[14]: Linq+Февральский СТР
От: Иванков Дмитрий Россия  
Дата: 05.03.08 06:13
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Здравствуйте, VladD2, Вы писали:


VD>>Не над из системы.

ИД>FullName на то и FullName чтобы однозначно идентифицировать эту загогулину, если хочется ее тестить, то и ссылаться на нее стоит именно так. (да, в сообщении выше я на system.core из беты судя по всему ссылку дал, а правильное имя легко подсмотреть в гаке)
см. positive/linq.n
Если кто-то без System.Core.dll у себя поломает коммитом подобный тест, не поломав остальных — вызывайте
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.