Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, __kot2, Вы писали:
__>>паттерны это естественные конструкции, которые возникают по мере разработки архитектуры WH>Не правильно. WH>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.
паттерн это идея, а не код. Таким образом Ваши предпосылки ошибочны.
WH>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача. WH>Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен. WH>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет. WH>Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу.
Это все очень мило, только "сделать свой язык для того чтобы решить задачу" это тоже паттерн.
Здравствуйте, __kot2, Вы писали:
WH>>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача. WH>>Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен. WH>>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет. WH>>Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу. __>есть жутчайшие языки программирования, которые возникли просто по ошибке и которые давно стоит закопать — например, sql. он как чемипалый пяти.. __>не имеет смысла плодить языки, да и не все языки, которые хорошо решают одну задачу сделаны с умом
Вот на SQL не надо наговаривать. Отличный язык запросов для релятиционных БД.
И вообще складывается ощущение, что критика SQL вызвана его не заннием.
Здравствуйте, 11molniev, Вы писали: 1>Вот на SQL не надо наговаривать. Отличный язык запросов для релятиционных БД. 1>И вообще складывается ощущение, что критика SQL вызвана его не заннием.
у меня была (да и есть) возможность сравнить профессиональный sql и C# код, написанный часто даже одним человеком. sql — гавнище в столбик и копипаста, C# — ну ниче так. что говорит скорее об ограничениях языка, чем о том, что его кто-то не знает.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, 11molniev, Вы писали: 1>>Вот на SQL не надо наговаривать. Отличный язык запросов для релятиционных БД. 1>>И вообще складывается ощущение, что критика SQL вызвана его не заннием. __>у меня была (да и есть) возможность сравнить профессиональный sql и C# код, написанный часто даже одним человеком. sql — гавнище в столбик и копипаста, C# — ну ниче так. что говорит скорее об ограничениях языка, чем о том, что его кто-то не знает.
Покажите пример. И под C# Вы подразумеваете LINQ? Или его функциональное расширение?
Здравствуйте, 11molniev, Вы писали: 1>Покажите пример. И под C# Вы подразумеваете LINQ? Или его функциональное расширение?
под C# я подразумеваю C# обвчный код где классики между собой взаимодействуют вызывая методы
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, 11molniev, Вы писали: 1>>Покажите пример. И под C# Вы подразумеваете LINQ? Или его функциональное расширение? __>под C# я подразумеваю C# обвчный код где классики между собой взаимодействуют вызывая методы
Пример?
Здравствуйте, 11molniev, Вы писали: 1>Здравствуйте, __kot2, Вы писали: __>>Здравствуйте, 11molniev, Вы писали: 1>>>Покажите пример. И под C# Вы подразумеваете LINQ? Или его функциональное расширение? __>>под C# я подразумеваю C# обвчный код где классики между собой взаимодействуют вызывая методы 1>Пример?
я не могу взять показать код из проекта. мой sql код гавно, тем более что sql я не знаю.
если хотите, можете показать любой не примитивный sql код который гавном не считаете
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, 11molniev, Вы писали: 1>>Здравствуйте, __kot2, Вы писали: __>>>Здравствуйте, 11molniev, Вы писали: 1>>>>Покажите пример. И под C# Вы подразумеваете LINQ? Или его функциональное расширение? __>>>под C# я подразумеваю C# обвчный код где классики между собой взаимодействуют вызывая методы 1>>Пример? __>я не могу взять показать код из проекта.
ок, понимаю. __>мой sql код гавно, тем более что sql я не знаю.
не факт, возможно я не сталкивался с вашей ситуации и даю однобокую оценку.
хотя отсутствие опыта использования sql мне кажется более вероятным. __>если хотите, можете показать любой не примитивный sql код который гавном не считаете
приведите задачу, что за запрос нужен. Будет не совсем коректно если я накатаю сферический запрос в вакууме для сферической базы.
Здравствуйте, Sinclair, Вы писали:
T>>Вот это я не понял, поясни пожалуйста. Как детектить дабл клики я знаю. А что такое активный стиль в RX ? S>Ну собственно это и есть активный стиль. Когда я пишу алгоритм над IObservable так, как будто это pull, пользуясь либо IEnumerable, либо Query Comprehension.
Я запутался, что значит в таком случае пассивный и реактивный стили ? Мог бы ты для сравнения примером в RX продемонстрировать ?
T>>blocking input нормально решается с короутинами. Шедулинг будет такой же как и с await. S>Ну то есть вы эмулируете await, только без синтаксической поддержки. Смысл неясен. Особенно пугают упоминания monitor.PulseAll и прочие прожорливые вещи.
int result = await<int>().FromDelay(5000).Then(() => 100);
или
int result = await<int>().AsyncResult(xxx);
Вызывающий код сам решит, как ему вызывать короутину которая содержит await. Если не надо никаких UI, то все будет работать как будто с синхронным кодом. Если надо таки работать независимо, то короутина будет запускаться ну например через метод async.
monitor.PulseAll +Wait ни разу не тяжелее того шедулинга, который в C# для async + await.
Есть проблемы — если из короутины напрямую дергать например контролы, здесь всегда будет вызов из другого потока.
T>>Это и есть короутины S>Корутины — это всего лишь один из способов представить требуемое. И не факт, что самый хороший. T>>Диспозить вобщем не проблема, но я это даже не начинал, S>Диспозить проблема в присутствии исключений. Почитайте блог Липперта на предмет особенностей обработки исключений в iterator block.
В c# yield, грубо говоря, сам же и вызывает внешний код, потому внешний код может забросить исключение в генератор == короутины в C# просто баловство
У нормальных короутин есть свой контекст. Все можно обработь внутри короутины или при желании перебросить внешнемоу кода. Помех от внешнего кода не будет. Исключения внешнего кода будет обрабатывать внешний код.
Т.е. я могу написать вот так
var g = new Generator<string>(yield =>
{
try
{
using(var res = Resource())
{
yield(res.Something());
throw new Exception();
}
}
catch(Exception ex)
{
DoSomething1();
throw;
}
finally()
{
DoSomething2();
}
});
...
try
{
foreach(var item in g) // если надо, MoveNext бросит исключение
{
throw new Exception() // это исключение никода не попадет в короутину, ибо стеки разные
}
}
catch(Exception ex)
{
}
T>>А можно даже завести цикл и получится один из вариантов рекурсии. S>Интересно.
Я хочу получить нечто вроде:
var q := new queue
coroutine produce
loop
while q is not full
create some new items
add the items to q
yield to consume
coroutine consume
loop
while q is not empty
remove some items from q
use the items
yield to produce
Здравствуйте, Tanker, Вы писали:
T>Я запутался, что значит в таком случае пассивный и реактивный стили ? Мог бы ты для сравнения примером в RX продемонстрировать ?
Пассивный стиль (он же реактивный) — это
public bool ReceiveDataChunk(byte[] data)
{
..
}
Активный стиль — это, понятное дело,
var readBytes = source.ReadDataChunk(buffer, count);
Я не очень понимаю, какой пример из Rx тут необходим.
T>
T>int result = await<int>().FromDelay(5000).Then(() => 100);
T>или
T>int result = await<int>().AsyncResult(xxx);
T>
T>Вызывающий код сам решит, как ему вызывать короутину которая содержит await. Если не надо никаких UI, то все будет работать как будто с синхронным кодом. Если надо таки работать независимо, то короутина будет запускаться ну например через метод async.
Непонятно. Внутри await() у вас должен быть способ отдать управление. Я вижу ровно два варианта:
1. Вызвать некий _next.GetControl(), увеличив глубину стека. Тот, кто у нас _next, может в свою очередь снова вызвать нас в своём теле метода, и так далее. Всё происходит в одном потоке, но с каждым пинг-понгом между продюсером/консумером нарастает глубина стека.
2. Вызвать некий _monitor.PulseAll, передав управление в другой поток. Стек "замёрзнет", но мы будем тратить по native thread (омг!) на каждую "корутину".
3. Вызвать SwitchToFiber(). Это наиболее приемлемый по ресурсам
T>monitor.PulseAll +Wait ни разу не тяжелее того шедулинга, который в C# для async + await.
С чего бы это вдруг? Monitor.PulseAll подразумевает наличие других потоков. На всякий случай процитирую общеизвестное:
The async and await keywords don't cause additional threads to be created. Async methods don't require multithreading because an async method doesn't run on its own thread
А всё потому, что настоящий async, в отличие от вашего самопального, не углубляется в стек, а наоборот — возвращает управление.
T>Есть проблемы — если из короутины напрямую дергать например контролы, здесь всегда будет вызов из другого потока.
Проблемы у вас не в этом. Проблемы в том, что вы имеете O(N) потоков, а это пипец как дорого. Если бы не было async/await, то такая реализация имела бы смысл в некоторых изолированных сценариях (скажем, в сервере бы её ни в жизни не стали запускать). С учётом наличия изкоробочного async/await, ваша реализация корутин не более полезна, чем ДеСметовская арифметика натуральных чисел на основе лямбд и игрек-комбинатора.
T>В c# yield, грубо говоря, сам же и вызывает внешний код, потому внешний код может забросить исключение в генератор == короутины в C# просто баловство
Ну, не стоит так грубо Всё же есть разница между "вызывает внешний код" и "возвращает управление внешнему коду".
T>У нормальных короутин есть свой контекст. Все можно обработь внутри короутины или при желании перебросить внешнемоу кода. Помех от внешнего кода не будет. Исключения внешнего кода будет обрабатывать внешний код. T>Т.е. я могу написать вот так T>
T> var g = new Generator<string>(yield =>
T> {
T> try
T> {
T> using(var res = Resource())
T> {
T> yield(res.Something());
T> throw new Exception();
T> }
T> }
T> catch(Exception ex)
T> {
T> DoSomething1();
T> throw;
T> }
T> finally()
T> {
T> DoSomething2();
T> }
T> });
T>...
T>try
T>{
T> foreach(var item in g) // если надо, MoveNext бросит исключение
T> {
T> throw new Exception() // это исключение никода не попадет в короутину, ибо стеки разные
T> }
T>}
T>catch(Exception ex)
T>{
T>}
T>
Осталось выяснить, каким образом вы собрались обработать ваш finally DoSomething2(), если исключение, брошенное в foreach "никогда не попадёт в корутину". Тот же вопрос и про res.Dispose(), который надо бы сделать в cвязи с выходом из using{}.
Я же говорю — читайте Липперта.
T>Я хочу получить нечто вроде: T>
T>var q := new queue
T>coroutine produce
T> loop
T> while q is not full
T> create some new items
T> add the items to q
T> yield to consume
T>coroutine consume
T> loop
T> while q is not empty
T> remove some items from q
T> use the items
T> yield to produce
T>
Что-то мне подсказывает, что async/await тут будут как раз в тему.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я не очень понимаю, какой пример из Rx тут необходим.
Я понял, спасибо.
T>>Вызывающий код сам решит, как ему вызывать короутину которая содержит await. Если не надо никаких UI, то все будет работать как будто с синхронным кодом. Если надо таки работать независимо, то короутина будет запускаться ну например через метод async. S>Непонятно. Внутри await() у вас должен быть способ отдать управление. Я вижу ровно два варианта: S>1. Вызвать некий _next.GetControl(), увеличив глубину стека. Тот, кто у нас _next, может в свою очередь снова вызвать нас в своём теле метода, и так далее. Всё происходит в одном потоке, но с каждым пинг-понгом между продюсером/консумером нарастает глубина стека. S>2. Вызвать некий _monitor.PulseAll, передав управление в другой поток. Стек "замёрзнет", но мы будем тратить по native thread (омг!) на каждую "корутину". S>3. Вызвать SwitchToFiber(). Это наиболее приемлемый по ресурсам
У меня это п.2, файбров ведь не предвидится. Есть возможности для оптимизации, но это пока что фантазии.
S>А всё потому, что настоящий async, в отличие от вашего самопального, не углубляется в стек, а наоборот — возвращает управление.
Хорошо, я понял
T>>Есть проблемы — если из короутины напрямую дергать например контролы, здесь всегда будет вызов из другого потока. S>Проблемы у вас не в этом. Проблемы в том, что вы имеете O(N) потоков, а это пипец как дорого. Если бы не было async/await, то такая реализация имела бы смысл в некоторых изолированных сценариях (скажем, в сервере бы её ни в жизни не стали запускать). С учётом наличия изкоробочного async/await, ваша реализация корутин не более полезна, чем ДеСметовская арифметика натуральных чисел на основе лямбд и игрек-комбинатора.
S>Осталось выяснить, каким образом вы собрались обработать ваш finally DoSomething2(), если исключение, брошенное в foreach "никогда не попадёт в корутину". Тот же вопрос и про res.Dispose(), который надо бы сделать в cвязи с выходом из using{}. S>Я же говорю — читайте Липперта.
Уже читаю А если так:
using(var g = new Generator(yield=>{}))
{
...
}
T>>Я хочу получить нечто вроде: T>>
T>>var q := new queue
T>>coroutine produce
T>> loop
T>> while q is not full
T>> create some new items
T>> add the items to q
T>> yield to consume
T>>coroutine consume
T>> loop
T>> while q is not empty
T>> remove some items from q
T>> use the items
T>> yield to produce
T>>
S>Что-то мне подсказывает, что async/await тут будут как раз в тему.
Всё же есть разница между "вызывает внешний код" и "возвращает управление внешнему коду".
