« first day (987 days earlier)      last day (2044 days later) » 

Bretbas
Bretbas
5:48 AM
@VladD ну тоесть получается интегратор должен быть и программистом и дизайнером:)
 
 
2 hours later…
Bretbas
Bretbas
7:57 AM
А кто скажет, равносильна ли две такие привязки:
ItemsSource="{Binding Path=ppl,RelativeSource={RelativeSource FindAncestor,AncestorType=Window}}"
и 
<Window x:Class="WpfApplication.Test"
        Name="TestWindow">
...
ItemsSource="{Binding Path=ppl, ElementName=TestWindow}"
 
Андрей NOP
Андрей NOP
8:17 AM
@Bretbas равносильны
 
 
5 hours later…
VladD
VladD
1:26 PM
@vitidev Вот тут не понимаю. Вы, как мне кажется, считаете чтение переменной равносильным доступу к памяти.
Потому что у барьера есть требование насчёт чтения памяти, а не переменных. И нигде нет требования, что чтение переменной есть чтение памяти. И контрпример я уже упоминал раз двести.
@Bretbas Ну, обязан быть немного программистом, и уметь понимать дизайнеров и говорить на их языке, да
@Bretbas Думаю, что равносильны. Хотя, имя можно по идее и поменять динамически? (Не уверен.)
 
Андрей NOP
Андрей NOP
2:12 PM
@VladD имя если поменять, привязка тоже изменится что ли? Элемент так-то в дереве тоже можно перенести, правда можно ли в другое окно - не знаю. Думаю, привязка выбирает элемент-источник единовременно, но это надо проверять.
 
VladD
VladD
2:46 PM
@АндрейNOP Вот этого не знаю, если честно
@АндрейNOP Ещё непонятно, есть ли привязки по имени в Loose XAML
Ну то есть когда оно без code-behind, в котором привязываются имена к полям
 
Bretbas
Bretbas
3:13 PM
@VladD, @АндрейNOP, я имел ввиду не по результату равносильны, а по функционалу? По скорости
 
vitidev
vitidev
4:00 PM
я считаю что язык первичен, а компилятор и тем более джит вторичен. Компилятор знает что такое барьер и не будет портить работу - иначе такой компилятор будет выброшен. Джит аналогично ведет себя так же

так что с бухты бараты ни тот ни другой не начнут делать рискованные оптимизации видя барьер

и еще - в жава модели памяти тоже нет понятия перестановки, а волатилы есть
прямо заговор против человеков программистов )
@VladD прежде чем выбросить локальную переменную и пробросиь чтение поля за барьер джит должен доказать что поле не используется другими потоками. Доказать он этого не может и никогда не сможет. Потому видя барьер он просто не ломает его. И с чего вдруг разрабы джита должны сойти с ума и начать делать неработающий выхлоп только по причине "в шарпе не указано, значит делаем шо хотим"- вот этого я не понимаю
скорее всего шарп задумывался как процессоронезависимый потому в модели памяти ничего такого нет, но релаьный мир процессоров потребовал необходимость такой инструкции и в шарпе, как указатель для всех, кто заинтересован (для этого барьеры и были придуманы так то). Можно сказать что это процессорозавимость, но процессоры все такие и без вот таких вещей никуда. Может не слишком спеково, но таковая реальность и нет планов на ее изменение.
(посмотрим что за процы будут после мелтдаун) но вряд ли исчезнет спекулитвное выполнение
 
Андрей NOP
Андрей NOP
4:18 PM
@Bretbas если есть разница, я не думаю, что она хоть сколько-то существенна в сравнении с остальным GUI, тем более если привязка единовременно определяет источник.
@Bretbas по функционалу одно и то же
@VladD что такое loose xaml? Вы, кстати, не имели дела с XAML 2009? Непонятно, почему MS забросили его и не стали до ума доводить...
Там по идее есть несколько очень полезных фишек, в том числе поддержка дженериков в разметке
 
 
2 hours later…
VladD
VladD
5:57 PM
@vitidev Язык первичен — да. Но на барьер нет гарантий в терминах языка. Отсюда вывод: барьер для тех, кто пишет на языке, бесполезен.
@vitidev Это вы можете подтвердить чем-то? Как я уже говорил, вы, скорее всего, предполагаете, что обращение к переменным тождественно обращению к памяти. Контрпримеры к этому уже были.
Поскольку барьер даёт только гарантии в терминах памяти, а не в терминах переменных, а отображение переменных на память не специфицировано, то барьер не даёт никаких гарантий.
@vitidev В Java и C# есть барьер, который чётко специфицирован в терминах модели памяти языка. И там в определениях нет ни слова о «процессоре», «ядрах» и прости господи «когерентности кешей». Поэтому я не согласен с данным высказыванием.
@АндрейNOP Ну, в принципе можно XAML загрузить в браузер (наверное, нужна поддержка Silverlight), и он будет показываться так, без code behind.
@АндрейNOP Думаю, банально из-за недостатка ресурсов
 
vitidev
vitidev
6:17 PM
в терминах языка шарп нет понятия реордер. в терминах языка жавы тоже нет. небось и в терминах с++ тоже нет ведь с++ не под конктретный проц
но реордер есть и дали специально людям такую инструкцию как барьер. Так она и вошла в реализации и шарпа и жавы и плюсов и в ядрах линукса есть.

на сферическом процессоре конечно реордера нет, потому похоже и в спеке нет. а на фактическом есть - компилятор шарпа/жавы джиты - все знают про реордер и про особое оношение к волатилам барьерам и прочему. - а значит барьер это прямой указатель всей тройке (компилятор. джит, проц) -как НЕ НАДО оптимизировать.
 
Bretbas
Bretbas
Ребят, посмотрите пожалуйста, модель предметной области для файлобменника. Нормально? Это первые наброски
Я первый раз хочу написать клиент-приложение.
 
VladD
VladD
6:39 PM
@vitidev Это не так.
Спека, 3.10 Execution Order:
> . The execution environment is free to change the order of execution of a C# program, subject to the following constraints: [...]
То есть изменения порядка выполнения вполне себе предусмотрены спекой.
 
VladD
VladD
6:53 PM
@Bretbas Я бы не делал такой жёсткий репозиторий: GetAll, возвращающий IList, плохо скалируется
Тут, возможно, @PashaPash что-нибудь бы добавил
 
 
2 hours later…
A K
A K
8:45 PM
@Bretbas веб-сайт?
 
 
2 hours later…
PashaPash
PashaPash
10:26 PM
@Bretbas в качестве тренировки - нормально. В качестве реального веб-файлообменника - нет. В основном из-за технических ограничений. Файлы, например, надо уметь заливать кусками. Identity вообще стоит отделить (bound context). Т. е. Не останавливаясь и продолжайте писать :)
 

« first day (987 days earlier)      last day (2044 days later) »