- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
class cxx_query {
elements operator()(const std::string &css_query);
void operator()(std::function<void()> callback);
http_request get(const std::string &url);
// ...
} $;
#define function []
$(function() {
$.get(some_url, function(const std::string &data) {
$("#result").html(data);
});
});
Follow us!
А еще майкрософт когда-то спалился на подобной хрени. Они задефайнили interface как struct в одной из олешных ашек.
уверен, что хер они одумались
Вот на лор зайдите - сразу видно, что у людей здоровая елда в заднице - кричат, кровью харкают, пену ртом пускают....
Любовь за деньги - это не любовь :)
Как тонко.
искренне говорит, что жаба гораздо лучше с#
гораздо более многосторонняя среда
по крайней мере с js она дружит на порядок лучше, студии до такого уровня как до китая раком
равно как и поддерживает ещё миллион других языков
эта монета двусторонняя
VB тоже туп как валенок
А ещё есть скала, до которой этому вашему шарпу как раком до Китая
Забавно выглядит описание форм на F#.
не понял чем тебе скала так приглянулась
Поддерживает, угу. Наелся я уже этих псевдофункциональщиков (http://govnokod.ru/14162), не нужно в жабке фп, дай дуракам yield стеклянный...
пей цейлоский чай - программируй на цейлоне
Утомило меня всё это. В чём преимущество очередной вундервафли перед существующими вундервафлями? Некоторые даже от скалки уже отказались (http://www.infoq.com/news/2011/11/yammer-scala), ибо часто приходится ломать голову над тривиальными вещами, а производительностью и отзывчивостью программ управлять становится всё труднее.
Зачем мне тратить время на вещи, которыми никто никогда не будет пользоваться? Я не вольный художник @wvxvw, обвиняющий всех в невежестве и тупом копировании уже созданных шедевров, втихушку админящий венду и правящий быдлосайты на кнокауте с мечтами о лишпах. Я - инженер и хочу делать вещи, которые работают, и работают хорошо. Для этого инструменты должны быть простыми, понятными и прозрачными. Иначе код становится илитарным и умирает. Проекты могут жить только тогда, когда существуют люди, способные в них разобраться за разумное время.
А вообще я открыл для себя книжку Robert Love - Linux Kernel Development, лажу по линуксовым сорцам (как завещал нам борманд) и любуюсь красотой тупорылой сишки.
P.S. Беглый обзор цейлона показал, что он практически ничем не лучше хацкеля, разве что наличием вездесущей жабомашины под капотом, но это не только преимущество.
А ведь все-таки царь в чем-то был прав... :)
У него были моменты просветов, когда в его бредопотоке школосознания проскакивали достойные мысли, но мне всегда было лень читать его портянки.
Теорема о 100500 обезьян, или как там ее правильно ;)
Это же классика - у меня есть молоток и я все им чиню. нужно забить гвоздь - молоток. Нужно открутить болт - молоток. Нужно склеить вазу - молоток. нужно склеить телку - молоток....
Просто люди видят технологию, шары закатывают и кричат - "мать ее это же скала/ фунциональшина/ ооп".
Может я не понял чего да не о том говорю.
Хаскель под jvm может стать неплохой вещью - многие задачи в контексте лямбда исчислений решаются лаконичнее. Но это не значит, что и VC на нем писать нужно
А зачем хаскелю jvm? Он и так неплохо компилится в нативный код ;)
А зачем математике физика?)
Jaskell
Блин, он существует...
Haskell даже cil умеет генерировать
Узнал о нём случайно из книжки The Productive Programmer, сам ни разу не использовал.
Q.E.D.
Ну ты молоток...
Cyton?
https://www.google.ru/search?q=%D1%81%D0%B0%D0%B9%D0%BB%D0%BE%D0%BD&newwindow=1&rls=com.microsoft:en-US:IE-Address&source=lnms&tbm=isch&sa=X&ei=yavKUrq 5Bofj4wSOv4C4Bw&ved=0CAcQ_AUoAQ&biw=1088&bih=506
Ну конечно! Как-будто что-то может быть лучше Хаскеля.
О_о. А можно его аргументацию услышать? Ну и сравнивает он только языки, или всю инфраструктуру jvm/.net в целом?
чем старше человек, тем тупее ему нужен инструмент, чтобы быстро решать поставленные задачи
по крайней мере переход на жабу он сделал с огромным воодушевлением
знание дотнета от него не убежит никуда, и много раз уже помогало - как в ускоренном освоении жабы, так и в архитектурных вопросах - поиск параллелей и использование опыта
также он в свое время наелся asp.net (который не mvc) и прочих дотнетных говнотехнологий - благодаря ему мы в свое время не вступили в ад java server faces
чем старше человек, тем тупее ему нужен инструмент, чтобы быстро решать поставленные задачи
Никогда бы не подумал, что это плюс. Никто не запрещает писать без сахара, более того сахар помогает решать повседневные задачи быстрее.
Проблема тут в том, что читать приходится с сахаром (потому что он кому-то помог решить повседневную задачу быстрее). А при командной работе и поддержке проекта ты читаешь гораздо больше чем пишешь.
Да что вы говорите... Как отличить экстеншн метод от обычного не глядя в подсказку IDE? :)
> 10 секундный поиск в гугле
Ок. Загугли мне 2 кубика сахара:Время пошло.
> он просто банально не знает
В том и суть, что для полноценной работы с языком ты должен знать весь сахар, который в нем есть. И тогда нет особого смысла в его неиспользовании.
с = (a!=null)? a:b;
Int? x - обвертка для метода значения, способная принимать null.
Если это шарп.
Но это я тупо знал)
Сахар не настолько сложен и неудобен, что бы его не знать) Если сахар неудобен и\или сложен для понимания - то это уже соль, и разговор другой.
Хотя тут сказывается мое личное отношение - люблю я сахарок типа рубишного
а ||=b unless c
<Тип-значение>? x - обвертка, способная принимать null.
Я в курсе, что T? это nullable<T> :) Я даже загуглил это в свое время. Вот только загуглить это было ой как не просто.
> Сахар не настолько сложен и неудобен, что бы его не знать
Ну и какой тогда смысл брать более сложный язык, и не юзать сахар из него?
Начали с твоей фразы "никто не запрещает писать без сахара". Пришли к противоречию ;) Q.E.D.
> а ||= b unless c
Нравится запоминать приоритеты операторов? :) Мне - нет.
Тут ничего сказать не могу, я прочитал это у Троелсона
> Нравится запоминать приоритеты операторов? :) Мне - нет.
мне все это кажется логичным и элементарным. Ну и никто не мешает писать в лисп стиле)
Подведу итог - сахар - сугубо личное дело каждого. Лично я не считаю сахар недостатком, скорее наоборот (поэтому и полюбил практически бесполезный руби).
И тем не менее нельзя сказать, что жаба лучше шарпа основываясь только на том, что в шарпе больше сахара. Тот же сахар async-await дает большое приимущество на мой взгляд
Имхо, имеет смысл только для GUI потока (ну и, возможно, для потоков, обслуживающих сокеты). Так что довольно специфический сахарок.
А где она нужна, кроме случая с гуем, к которому нельзя лезть из других потоков, и случая с I/O мультиплексором, который делают из-за слишком дорогих потоков? :)
Я не правильно выразился
Тот же сахар async-await дает большое приимущество в решении асинхронных задач на мой взгляд
Да и либа для паралеллизма в .Net побогаче
Что такое асинхронная задача?
Я неверно выразился?
Почему их необходимо решать асинхронно?
Предпочтительно решать их асинхронно, так как это помогает увеличить скорость выполнения за счет максимально эффективного распределение ресурсов и снижения времени простоя
Слова не мальчика, но эффективного менеджера...
Ок, значит мы имеем задачу, которую можно решать эффективней, если исполнять несколько ее подзадач параллельно (например на нескольких ядрах SMP системы). Здесь мы плавно подходим к вопросу, почему "помогает увеличить скорость выполнения" именно идиома async-await (аля сопрограммы)? Для этого следует рассмотреть другие существующие решения, позволяющие распараллелить исполнение кода, и обосрать их описать их недостатки. А не просто сказать "вот серебряная пуля, юзайте".
Ой, не нужно, я весь красный от гордости
>>"помогает увеличить скорость выполнения" именно идиома async-await
Она помогает не скорость исполнения увеличить, а быстро сделать из последовательного кода асинхронный. Не нужно переписывать кучу кода, достаточно пары вставок.
Ок, допустим была у Васи прога, которая листала порнофотки с сетевого диска по нажатию стрелочки. Фотки были в хорошем качестве, сеть была плохая, в итоге фотки менялись довольно медленно, и интерфейс подвисал на время чтения-декодирования (т.к. код был простым и синхронным).
Вася добавил в код await и вызвал асинхронную загрузку вместо синхронной.
Вопросы на засыпку:
- что произойдет, если Вася во время лага будет яростно тыкать стрелочку вправо, не видя никакого эффекта?
- как Вася поймет, что прога что-то делает, а не просто висит (вспомни загрузку win8, в которой во время получасового chkdsk крутится та же самая вертящаяся херня, что и при нормальной загрузке, и хуй поймешь что там вообще происходит)?
- достаточно ли Васе добавить пару вставок, или все-таки придется закусить удила и переписать кучу кода?
Или я задачу не понял.
Даже если мыслить так - задача стала асинхронной, проблемы теперь с гуем. Ололо
Без async -await - все тоже самое, плюс асинхронность ручками
Имеет, как минимум можно прикрутить отмену ну и ось не будет ругаться "эта программа не отвечает".
> Вот если бы у него сеть была быстрая, но при закачке одной картинки грузилась не полностью, имело бы смысл грузить картинки асинхронно.
prefetch? Ну ок, разумно.
> задача стала асинхронной, проблемы теперь с гуем
Именно так. async-await не стал для Васи серебрянной пулей.
> Без async -await - все тоже самое, плюс асинхронность ручками
Суть примера была всего лишь в том, чтобы показать, что "Не нужно переписывать кучу кода, достаточно пары вставок" - ложь, пиздежь и сплошная провокация маркетинговый бред. Существующий синхронный код один хрен придется реинжинирить (даже не рефакторить, а именно реинжинирить, со всеми вытекающими последствиями!), с учетом асинхронности.
Ок, значит твой следующий аргумент - с async-await кода писать меньше, чем при других способах? Хорошо. Тогда перечисли, пожалуйста, какие способы ты знаешь помимо async-await (можно в контексте Васиной задачи).
мы вставили пару слов -> код стал асинхронным - > что не так то?)
Это опять путаница с понятиями - конечно хотелось бы что бы вообще ничего менять не нужно было, только написал - а тут выполнять асинхронно - и забить хуйцы.
Это выглядит так же, будто нельзя сказать, что массив создается одной строкой, хотя при переходе от 100 отдельных переменных к массиву придется менять хуеву тучу кода.
ИМХО
Способы
1. Перейти на разделение загрузки-просмотра.(картинки грузим при нажатии кнопки, можно все сразу, а смотрим -когда загрузилась полностью)
2. Пилить код с продолжениями
3. Сменить провайдера
4. отказаться от порно и завести женщину
5. Познать дзен
6 Смириться
7 ???
8 PROFIT!
Всего лишь то, что проблем у Васиной проги стало больше, чем до вставки пары слов :) Что означает всего лишь то, что вставки пары слов явно недостаточно, и Васе еще пилить и пилить, и материться на того, кто предложил ему "вставить пару слов".
> 1. Перейти на разделение загрузки-просмотра
Вася нетерпелив. Он хочет дрочить здесь и сейчас, а не через час, когда все докачается. И он не знает заранее, сколько картинок ему понадобится.
> 2. Пилить код с продолжениями
Хех, ну и засрали же вам моск эти ребята из M$ и node js... Если думать, что кроме продолжений нет других решений - тогда да, async-await это единственное верное решение :)
P.S. Варианты 4-8 рулят :)
Тем неменее главная проблема Васи решена - код асинхронный, ему не пришлось думать, как запилить эту задачу, а все остальное Вася умеет делать)
Это не ребята их MS, это я зеленый и неопытный) MS(DN) я вообще не люблю - воду разводят. Пытался найти как узнать, пересекаются ли 2 shape, в итоге только на stackoverflow нашел.
Если посоветуете литературу по асинхронщине (да и по продолжениям) - с удовольствием почитаю.)
Я тоже с этим сталкивался - час, два на свалку, пользы -0. Поэтому и не хожу больше к ним.
Хех, ну тут я соглашусь. Вася так и не узнал о потоках и т.п., а задачу решить смог.
Но... Почему мы выбрали для него именно этот способ, а не какой-то еще? Согласись, "давайте поюзаем async-await и все будет заебись, нам даже не надо знать про треды", звучит как реклама... А работа инженера начинается все-таки не в том, чтобы схватить первый попавшийся в рекламном проспекте вариант, а в рассмотрении того, как задачу решали другие люди, какие у этих способов были достоинства и недостатки. Да, он может выбрать именно этот вариант. Но осознанно, а не потому что это круто и все так делают.
P.S. А как там у async/await с отменой?
Ясно дело. А то как с AssParallel получится
Таску же в await суем - соответственно cancellationToken запихиваем и все
Стандартные асинхронные методы (типа чтения из файла) принимают его? UPD: да, принимают.
> Ясно дело.
Ну так все-таки. Почему из известных нам способов мы выбираем именно async-await, а не какой-то другой? Меня именно это интересует.
Ну вот пример когда эффективно
есть у нас код
но тут мы поняли, что т2 зависит от т1, а т3 - сферическая в вакууме. поэтому мы можем написать что то типа
Другой вопрос: такая схема просто игнорирует возможность дедлоков, т.е. очень просто самого себя наказать вызвав тред вызывающий вызывающего. Нужно вручную разруливать потенциальные возможности дедлоков - а это очень плохо скейлится.
(Флеш тоже использует похожую концепцию, и в нем есть известные грабли, когда в обработчике события addedToStage добавляется элемент на сцену, и событие запускается по новой, попадая в тот же самый обработчик).
Еще негативный момент: фьючерсы по факту одноразовые, мусорщика напрягают.
И еще эта схема плохо работает в ситуации когда ответы на запросы приходят не в ЛИФО порядке, а в "каком-нибудь" - в таком случае мы можем нарваться на АБА проблему, или просто никогда не получить ожидаемого ответа, не смотря на то, что отправитель его честно пошлет (как в ситуации когда пользователь очен быстро что-то печатает а автодополнение появляется со все более заметным опозданием / вообще не в тему).
Я прекрасно понимаю, как работает async/await (хотя в данном примере хватило бы банального future).
Я просто прошу, чтобы мне обосновали егопреимущества перед другими способами. Пока я вижу только рекламу серебрянной пули.
P.S. await перед вызовом task12 разве не нужен?
Я имею в виду метод task. await методы могут быть только внутри async методов
> начинает выполняться т1 - управление выпадает на выход из процедуры и начинает выполнятся т3. когда т1 завершится - начнет выполнятся т2.
Да, сорри, я тупанул, время позднее было. Но тогда subTask1() и subTask2() надо переделать так, чтобы они возвращали future (Task в c#)?
Что есть future?)
Я слишком псевдокодно описал прошлый пример)
Ололо! Шарпеи юзают future даже не зная, что это такое!
> Я слишком псевдокодно описал прошлый пример)
> Их заворачивают в таск и запускают.
Тогда ок. Меня вот и смутило, что await на обычном методе дернули.
Пример нашел, понял как оно работает и забил, не вникал в детали)
Или я туплю, или код делает совсем не это ;) мое понимание - выполнится таск1 на тредпуле, затем таск2 тоже на тредпуле, затем таск3 в главном потокн. Разве нет?
Этож процедуры, нет возвращаемого значения. Более того, когда основной поток выполнит т3 он дальше пойдет гулять за пределы функции)
Была бы эта прога гуишной - t4 и t5 повешали бы event dispatching thread (или как там у вас его зовут в шарпе) :P
Но пример годный, показывает удобство async/await.
Что делает эта штука? Может аналог вспомню
Вообще в гуи я так же делал - такс с вычислениями на await ставил, а основной поток на гуишку падал
Ну тред, в котором крутится цикл обработки сообщений от гуя. И который нежелательно вешать всякой херней, т.к. страдает отзывчивость интерфейса.
P.S. Пойду поставлю фреймворк 4.5 на виртуалку, чтобы поразбираться с примером.
P.P.S. Ёбаная срань, обновление версии .NET Framework 4, характеризующееся высокой степенью совместимости не встающее на XP...
А мне почему-то кажется, что это именно тот поток, в котором срабатывают все обработчики событий от всяких там кнопочек ;)
P.S. Фреймворк поставил, компилю пример.
Про поток - сорри, не понял вопроса. Если просто поток формы - то поток и хрен с ним) А если там за кулисами плавает загадочный поток, который отлавливает события и передает обработку в основой - то вообще хз)
Именно так, и файл создавал через блокнотик. Ну не ставить же целую вижуалку ради этого...
> Если просто поток формы - то поток и хрен с ним)
Там что, на каждую форму по потоку? :) Да вот не хрен бы с ним. Повиснет - ось подумает, что прога зависла, юзер тоже. Кнопочки не тыкаются, ничего не рисуется...
Из async/await методов можно лезть к гую?
как и из любого потока. Это ж просто сахар
А ничего, что фреймворк дает по рукам за попытки потрогать гуй из левых потоков? :)
Т.е. в любом коде с async/await я должен делать проброс коллбека в UI тред, как и в обычной многопоточке? :) Но почему все утверждают мне обратное, что можно юзать гуй прямо из тела async метода, если сам async метод изначально был вызван из ui треда? :) Так могу я или не могу писать вот такой простой и понятный код:И почему я могу (или не могу) его писать?
P.S. Лишний раз убедился в том, что шарпеи ничего не понимают даже в своем инструменте. Что уж тут говорить о других языках и парадигмах.
Да тут претензии не столько к абстракции, сколько к ее юзерам. Ну ты посмотри, как они ее юзают: из async метода делают Invoke, т.к. не знают, будет там главный поток или нет... И я не думаю, что только Kegdan так тупанул.
А с абстракцией ниже по треду разобрались. Действительно, все просто и понятно:
- если есть контекст синхронизации (гуй, вебсервер, прочая херня, где важно в каком треде будет ответ), то await вернется в тот же тред, откуда был вызван
- если нет контекста синхронизации (свободный поток, тредпул или ко-ко-консолька), или привязку отключили вручную, то await не будет менять тред, и исполнит продолжение где повезет.
Согласись, правила не такие уж сложные? А зная их можно представлять, что получится в результате, и не перестраховываться лишний раз.
Мне, лично, как-то спокойней кодить, если я знаю все ограничения абстракции. Особенно если их совсем немного, и абстракция почти никогда не течет.
А что тут такого? И откуда берется контекст синхронизации?
> А что тут такого?
А зачем инвочить, если из тела async метода, вызванного из ui треда, можно дергать методы уя напрямую?
> откуда берется контекст синхронизации
SynchronizationContext.Current
Чтоэта?
Свойство, в котором лежит контекст синхронизации текущего треда ;)
Вот кегдан кидал ссылку:
http://blogs.msdn.com/b/pfxteam/archive/2012/01/20/10259049.aspx
P.S. Пля, почему я это рассказываю вам, а не вы мне? Я же шарп последний раз лапал году в 2007 :)
Так откуда этот контекст берется-то?
Ну вот, в случае с гуем, его создал и положил туда метод Application.Run() (или что-то, что вызвалось из этого Run'а, не суть).
После чего async методы, запущенные в ui треде будут отправлять продолжения через этот контекст, а значит они будут исполняться в ui потоке, и все будет заебись.
Почитай статью, она короткая.
Скоро пойдут вопросы что такое параллельное программирование в целом и семафоры в частности)
То есть, создатель треда вешает на него флаг "запускать async только из этого треда"?
Ебучая опера, вызывает меню при переключении по alt+shift.
В шарпе это называется атрибутом - записывает метаданные в код, которые потом можно вытянуть рефлексией. собствеено это классы наследники System.Attribute с атрибутом System.AttributeUsage
> записывает метаданные в код, которые потом можно вытянуть рефлексией
Ну вот это самое и есть :)
Да зная шарп, ты почти всю жабу уже знаешь ;) Там язык то очень простой. Не сложнее питона. Засада только в дженериках.
Гораздо проще. В питоне все такое динамичненькое. Метапрограммирование же.
Дальше не захотелось читать, да и синтаксис не родной.
Хочешь правды - иди в Дельфы [к Оракулу]
Скорее все-таки то, что крутится внутри этого треда.
> вешает на него флаг "запускать async только из этого треда"?
Ну примерно так. Ну там не флаг, а приемник колбеков, но не суть.
Идея вот такая: "если в этом треде кто-то сделает await, то, когда то чего ждал await завершится, надо бы вернуть управление именно в этот тред".
То есть внутри треда вешается этот флаг?
Ну не флаг, ссылка на объект. Но да. Как я понял, вешается она в thread local storage конкретному треду.
Все.Очень.Плохо.
Толсто.
Потому что csc не один. Который из них добавлять в path?
python-3.3
> python-3.3
Ну да, вариант. Х.з.тогда. Может быть просто посчитали, что кому надо - добавит сам. А остальным нинужно.
А их как-то програмно можно найти, кроме d:\WINDOWS\Microsoft.NET\Framework\*\csc .exe ?
Да там вроде даже апишки в дотнете были для вызова компилера. Я х.з. На этот вопрос пусть дотнетчики отвечают.
Если надо вынести обработку в отдельный поток гораздо лучше создать отдельный класс и передать ему необходимые данные, обеспечив их когерентность. И этом случае каждый увидит создание таски и поймет, что тут будет асинхронный код и надлежащим образом будет его использовать.
Дальше, где выполняется вся эта хрень? На каждый вызов создается отдельный поток? Или в тредпуле? В последнем случае как его регулировать? Можно раскидать обработку на разные тредпулы?
Когда в синтаксический сахар примешивают логику выполнения начинается пиздец
1 поток главный - держит форму. Загружать его длительными операциями недопустимо.
2 поток качает картинки, по мере подгрузки ассигнует их с image
3 поток следит за состоянием сети, действиями юзера, правит 2 поток, если что не так, отрубает его. Если я правильно понял поставленную задачу, я бы решил ее так.
Я об этом и писал в 1 пункте.
Мы говорим - грузи нам x с сайта.
пока грузятся мы наблюдаем на каждой страницы просмотра что то типа "10 секунд до онанизма!" а когда загрузится - смотрим картинку. Можно сделать загрузку по мере просмотра - (добавлять в загрузку текущую и n следующих)
Ну третий поток, имхо, лишний. Первый вполне справится с управлением вторым. Довольно низкоуровнево (но в делфи емнип больше никак), но как один из вариантов решения - ок, имеет право на жизнь.
>Суть примера была всего лишь в том, чтобы показать, что "Не нужно переписывать кучу кода, достаточно пары вставок" - ложь, пиздежь и сплошная провокация маркетинговый бред.
Суть, в первую очередь - асинхронный код выглядит как синхронный. Да, это корпоративная многозадачность, как в win 3.1 и получаем с ней проблемы win 3.1 - если одна задача не отдает управление, виснут все, что юзают тот же потом. Насколько я знаю, единственная проблема. Взамен избавляемся ото всех проблем многопоточности (если все работает в одном треде, а не в нескольких).
Ну это даже не проблема async-await. Это, если я не туплю, проблема любых схем с future...
Ну ок, запускаем пример Kegdan'а, который он кидал выше (с небольшим дополнением - выводится айдишка текущего треда, и таймаут у t3 2000мс):Как видим, даже код внутри async метода исполнялся хуй пойми в каком треде... Привет всем проблемам многопоточности ;)
Руками переписывал из виртуалки :) Добавь вывод Thread.CurrentThread.ManagedThreadId да перепроверь сам ;) Там еще по IsThreadPoolThread видно, что 3 и 4 треды работают в пуле.
Поиграйся за одно с
System.Threading.Tasks.Parallel.For<TLoc al>(Int32, Int32, ParallelOptions, Func<TLocal>, Func<Int32, ParallelLoopState, TLocal, TLocal>, Action<TLocal>)
занятная функция
http://msdn.microsoft.com/ru-ru/library/dd783586(v=vs.110).aspx
Лениво было в опции виртуалки лезть. Все там есть, и общие файлы, и общий клипборд. Просто виртуалка с семеркой свежеустановленная, совсем не настроенная.
> Parallel.For
Да здесь то понятно, что будет на разных тредах исполняться.
Батхерт у меня от того, что вы все тут утверждали (включая хабровчан), что продолжение async task'а исполняется на том же потоке, где и началось. А на деле оно исполнилось на тредпуле...
P.S. В принципе, я понимаю, почему продолжение async метода исполнилось на тредпуле, а не в первом треде. Но подожду ответа шарпеев :)
P.P.S. Хоть один шарпей понимает те инструменты, которые использует? Или для вас это всегда магия?
А не все ли равно с точки зрения основного потока?)
Да и держать поток не нужно в ожидании, новый на пуле выделил и холера его бей.
Я тут один шарпей. Ты что, ждешь что то умное от студента без опыта коммерческой разработки?)
Учись, студент. На самом деле я просто веду диалог в форме троллинга (в философии, емнип, есть такой способ ведения диалога, когда один участник опровергает и отрицает все, что произнес второй), чтобы вытянуть из оппонентов полезную инфу и самому разобраться в вопросе ;) Ну и заодно ты сам разберешься в своем инструменте.
> новый на пуле выделил и холера его бей
Куски метода исполняются в хуй пойми каких потоках. Об этом как минимум надо знать, чтобы не залететь на забавные ошибки.
> А не все ли равно с точки зрения основного потока?)
Да вот как бы не все равно. Например к ui или сокету лезть из других потоков неприлично.
ты собрался юзать уникальные свойства потока?)
>>Да вот как бы не все равно. Например к ui или сокету лезть из других потоков неприлично.
Сам вызов таска - уже другой поток. так что юзать все равно не кошерно. Хотя тут я могу ошибаться, и MS подзаморочились (непонятно зачем), но я очень в этом сомневаюсь. По этой же причине я считаю, что нельзя просто брать и вызывать события гуя из асинхронки. ибо здравый смысл
Это я понимаю. Поэтому таск стараются писать так, чтобы он, по возможности, никуда не лез.
> ты собрался юзать уникальные свойства потока?)
Я собрался передать в async метод некий объект (например что-то гуёвое), чтобы async метод асинхронно что-то сделал (например выполнил пару тасков), а потом сделал что-то с переданным ему объектом. Эксперимент показал, что куски async метода могут исполняться на каких-попало потоках, что может закончиться неприятностями, если тот объект не потокобезопасный.
> По этой же причине я считаю, что нельзя просто брать и вызывать события гуя из асинхронки. ибо здравый смысл
Но почему все статьи об async/await утверждают обратное? :)
Мое предположение:
- Тело async task'а продолжает исполняться на том треде, где начало, если внутри треда крутится цикл обработки сообщений (например gui тред и ему подобные). Именно так его юзают во всяких там статьях.
- Тело async task'а исполняется на рандомных тредах из пула, если тред запустивший его не имеет цикла обработки сообщений (и поэтому ему никак не могут намекнуть о продолжении async task'а). Это мы видим на приведенном тобой примере.
Но хотелось бы увидеть официальную доку от M$, которая расставит все точки над i в этом вопросе ;)
>>Эксперимент показал, что куски async метода могут исполняться на каких-попало потоках, что может закончиться неприятностями, если тот объект не потокобезопасный.
можно поставить барьер памяти, если сомневаешься в порядке инструкций.
приведи пример кода, или ссыль дай. только что пробовал вызвать - выдало ошибку - несоответствие потоков. через invoke работает.
Ну вот код. Все нормально работает, тело async'а исполняется именно в ui треде: http://pastebin.com/pD8DqZfP. Если тыкнуть в Sync во время работы Async, то видно как продолжение async task'а шедулится в ui тред.
А вот на этом примере http://pastebin.com/pp2PsagE мы видим, как наличие\отсутствие цикла обработки сообщений влияет на тот поток, на котором async task завершит свою работу.
P.S. Но эксперименты экспериментами, а мне хотелось бы спеку, в которой английским по белому написано, при каких условиях async task'и ведут себя так, а в каких сяк.
ссыль такая например
http://blogs.msdn.com/b/pfxteam/archive/2012/01/20/10259049.aspx
Спасибо! Вот такого ответа я и ждал :) Все просто и понятно.
> await сохраняет контекст
Скажем так, пытается сохранить контекст. И если не получилось (как в нашем консольном примере) - то не получилось, ничего не поделаешь.
> Поэтому можно вызывать прямо их ассинхронной задачи напрямую.
Но только если асинхронная задача была запущена из правильного синхроконтекста (например из обработчика нажатия какой-нибудь кнопы). Если ее запустить из жопы (например из таска, исполняющегося на тредпуле) - то нельзя, ибо получим корейский рандом.
> При создании потока контекст синхронизации изменяется
Ну неправда же ;) Вот Application.Run действительно изменяет контекст у текущего треда: устанавливает на входе и зануляет на выходе. А запуск нового треда, а уж тем более отправка таска в него, никак не повлияют на синхроконтекст текущего треда.
Даже спорить не буду - я с нашей вчерашней беседы еще не спал, поэтому мозг мне рисует картины дивной красоты, да и читал я основную часть с русского источника)
Спасибо за вопросы - сам бы я еще долго до этого не добрался)
И тебе спасибо за диалог. Все-таки разобрались до конца в магии этого async-await'а ;) Теперь я даже смогу его юзать, если, конечно, решусь засесть за шарп.
понравился сахарок?
Ссылка была годная?
Да, статья очень годная. Разжевали все вопросы шедулинга, даже показали как свой синхроконтекст для ко-ко-консолечки запилить, если захочется.
> понравился сахарок?
Вполне годно, с учетом сохранения контекста синхронизации. Без него не понравился бы.
Мне кажется я не прочувствовал всей сути это сахара)
Но оказалось, что эта наркомания уже написана: https://github.com/kilim/kilim
Мне кажется, что в спеке perl6 это всяко есть ;)
но
TMTOWTDI )
Кстати, очень печально, но зачастую даже программисты с опытом коммерческой разработки не понимают того, что происходит в их коде (чему как раз способствуют сложные сахарные языки и библиотеки с кучей магии) :) Так что ничего личного, не обижайся.
а разве должно было быть иначе?
в бусте с асио и стеклесс корутинами можно было играться в эти async-await reenter-yield-fork ещё в 2009 в с++03
Ну мне тут утверждали, что async-await в пару строчек решит все мои проблемы с асинхронностью и многопоточностью... А я, дурак, даже поверил им...
+1
>>"Не нужно переписывать кучу кода, достаточно пары вставок" - ложь, пиздежь и сплошная провокация
+1 (уже успел набить шишки)
Использование асинхронности может принести массу проблем, если не предпринять мер. Опасность в том, что прога не фильтрует сообщения главного потока - можно обращаться к объекту из цикла, и тут же вызвать деструктор объекта...
Дальше, нужно указывать как общаются параллельно выполняющиеся программы, они опять же могут либо обмениваться сообщениями, либо работать с общей памятью; у того и у другого подходов есть свои разновидности.
"Асинхронное выполнение" в стиле ноды характерно тем, что оно если и эффективно чем-то, так это тем, что заставляет писать в духе, когда коротенькие процедуры быстро возвращают управление (но это в свою очередь значит, что параллелизм типа "разные данные + разные функции" - и никакого серьезного профита от этого не ожидается за исключением поверхностных изменений (можно одновременно что-то делать и прогресс-бар нарисовать).
А вот переписывать синхронный код в асинхронный таким образом плохо. Как правило таким образом переведенные алгоритмы работают примерно так же, как звучит руководство по эксплуатации к китайскому электрочайнику "легко" переведенное на русский "простой" заменой нескольких слов.
А че? Охуенно.
Главное не скатиться до уровня перла.
Просто эти вещи приходят с опытом. А по-наивности можно случайно и конкретный тип указать, и вместо всяких @Data, @Setter, @Getter + 100500 строк икс-им-еля просто назначить значение полю класса.
мда, емакс не только бесполезен в проектах С++, но и даже с тупой жабой не совладал?
> xml
на моей памяти лезть руками в xml нужно было только для работы maven (мерзость, но даже в idea не полноценная поддержка)
Ant хуже. maven (по крайней мере, на типовых конфигурациях) декларативный и не такой уж и страшный - просто список модулей и зависимостей. А вот ant...
P.S. [оффтоп]Кто-нибудь описывал модули с JNI в maven'е? Сильно сложно?[/оффтоп]
ХЗ. Эмакс + кланг = нормальный автокомплит, даже в больших проектах, но я много не пользовался. Ява и Эмакс разошлись примерно сразу же после версии Явы 1.1. С Явой ассоциируется массовый приток в отрасль новичков, которые про Эмакс ничего не знали, и начали свой жизненный путь с клипса в виндовсе. А предыдущим пользователям Эмакса Ява вообще не уперлась. Так вот ее поддержкой никто и не занимался.
Я сейчас пользуюсь эклимом: безголовый эклипс используется для дополнения / поиска / импортов / управления проектами, но с нормальным интерфейсом. Работает стабильно, но медленно. Отладчик в консоли, но при сноровке, есть и свои плюсы, типа нормального поиска по сообщениям из логгера, история, отладчик физически находистя в одном окне с кодом, так что не нужно переключаться между программами, чтобы что-то отредактировать, доступны некоторые команды, которые не доступны из графической оболочки (восновном всякая статистика).
даже если речь идет про Кота Анатолия
ну а фреймворк - ну вот у нас спринг-мвц, и, так сказать, хибернейт (на самом деле там скорее спринговый JPA)
все делается аннотациями, в xml нужды нет
Чет мне сильно сомнительно, что ничего не отыщится.
К сожалению в ASP.NET дела обстоят ничуть не лучше. Вспоминаю те баттхерты, когда разрабы портанули одну из подсистем под фреймворк 4.0, а корень сайта по прежнему крутился под 2.0... Было очень весело. Я тогда узнал много нового о web.config'ах и их наследовании ;)
Кстати, а нет в конфиге возможности приказать IISу использовать его для всей папки, а не только для *.aspx?
Например, альтернативные страницы ошибок HTTP работают только для *.aspx; forms authentication закрывает только *.aspx. Хочется прописать в конфиге максимум информации, чтобы на сервере только добавить папку с сайтом и проделать минимум операций для его успешного запуска.
Как-то так, через StaticFileHandler? http://stackoverflow.com/questions/11973459/aspnet-static-file-access-with-authentication
Ну может быть *.* прокатит, если не заденет *.aspx? У меня сейчас, слава богу, нет под рукой сервера с asp.net.
Видел я примерно то окно в IISе - там был длиннющий список расширений. Но надежда есть.
> У меня сейчас, слава богу, нет под рукой сервера с asp.net.
Выходные ещё :) мне только IIS Express доступен.
Ну зачем же так.
Безголовый скорее всего headless. Т.е., видимо, чисто ядро эклипса, без гуя.
Это да. Причем аннотации сами по себе не делают ровным счетом ничего. И надо еще догадаться, считает ли ее какая-то либа в рантайме, обработает ли ее какой-нибудь процессор аннотаций, или вообще все положат на нее большой и толстый хуй...
> стремятся все написать на икс-им-ели
Слава богу, с выходом аннотаций, народ перекинулся с XML'я на них... Все-таки небольшая аннотация для тех же ORM'ов выглядит меньшим злом, чем то же самое в виде 10 нод XML...
> нужно всегда указывать интерфейс
И не забыть запилить фабрику билдеров для реализаций этого интерфейса ;) А вообще, интерфейсы это палка о двух концах. С одной стороны это Истинная Инкапсуляция, которая дает очень и очень неплохую развязку, вплоть до свободной замены одной реализации на другую. С другой стороны это Глубокая Задница, т.к. поменять интерфейс уже нереально (уберешь метод - сломаются юзеры, добавишь метод - сломаются реализации), и начинаются костыли в духе попыток каста этого интерфейса в другой...
>> переход на жабу он сделал с огромным воодушевлением
Вы ему хотя бы молочко за вредность не выделяете? :) Мне это напоминает симптомы фанатизма, без которого не получится приспособить моск под новое мышление.
программисту вообще тяжко без молочка
на самом деле прожекты у нас как раз веб, thin server architecture
после довлеющего пиздеца с aspnet/webforms в дотнетах, делать изначально правильно на жабе воодушевляет
Неправда, как обладатель люмии, я утверждаю, что windows phone не подходит ни для чего, кроме звонков, а iphone не подходит ни для чего вообще и это утверждение - результат наблюдений за знакомыми яблочниками.
Так же как подменили "жаба гораздо лучше с#"
на "Something на java гораздо лучше ASP.NET на C#"
Более того, телефоны с Android, Windows Phone (или как там ее сейчас правильно называют) и iOS для звонков менее удобны, чем их кнопочные предки ;) Просто с этим все смирились.
Расшифрую:
- Ухом можно скинуть трубку. На современных сотиках для этого приделали детектор уха. На многих старых сотиках с ведром 2.х их не было, и очень доставляли маты коллеги, у которого был как раз такой телефон ;)
- Очень сложно сбросить вызов, не доставая телефон из кармана. На кнопочных моторолке с380 и нокии n73 я делал это с первого раза, даже если телефон был во внутреннем кармане.
- Набирать чей-то номер зимой на ветру - сущий ад (если не покупать специальные токопроводящие варежки).
- Набирать цифры и искать людей в справочнике с этой 4" лопатой одной рукой не очень удобно. На кнопочниках такой проблемы не было.
сейчас все в погоне за видом гейфона и нет ни одного нормального смарта с кнопками.
Эх была же htc с шиндошс mobile с сенсорным экраном и нормальными кнопками, с помощью которых можно было не юзать тачскрин
Типа ты дохуя в перчатках по маленьким клавишам попадешь. Я всегда снимал перчатки.
>Набирать чей-то номер зимой на ветру - сущий ад
А почему просто не блочить ввод?
Попадал же, вполне так попадал ;) И даже джойстик на n73 умудрялся шатать.
> А почему просто не блочить ввод?
Это про детектор уха? Ну там и блочится ввод, если фотоэлемент почует, что его кто-то заслонил. А совсем блочить нельзя, как скидывать трубку то?
об стену, вестимо
[на правах рекламы]Хайскрин, сука, крепкий оказался. Пару раз ронял его почти с полутора метров (вешал куртку держа в руках телефон) - аккумулятор вылетал, но корпус целый, экран целый, все работает.[/на правах рекламы]
Так что способ вполне юзабельный ;)
хожу троллю айфоногнусмасоводов неделей работы без подзарядки на двух симках[/подкину нищебродства]
[не_реклама шиндовс_фон="говно"]Я демонстировал коллегам, насколько крепкий экран у люмии 920, роняя его на разные поверхности экраном вниз где-то с полутра метров. Люмия сдалась в пятом раунде линолеуму: потрескалось стекло, но дисплей и сенсор остались рабочими :)[/не_реклама]
Эту страну действительно не победить.
Стекло Гориллы? Так оно не царапается, но довольно хрупкое ;)
Потому что обычно он сначала ударяется корпусом (уголком или ребром), а потом уже стеклом, и корпус демпфирует удар. Я думаю хватит одного падения стеклом вниз на какой-нибудь бугорок ;)
Физик - кун)
>>Я думаю хватит одного падения стеклом вниз на какой-нибудь бугорок ;)
с 1,7-1,8м - вряд ли. нужна заостренная поверхность, бугорка мало
Чем разблокировать? Там из хардварных кнопок громкость да питание ;) Все остальные кнопы на ведрах - выпирающий вниз кусок экранного сенсора. Ну на айфунах, правда, кнопка home (или как там ее), не сенсорная.
Сбрасывать вызов в духе slide to unlock? Ну да, в этом что-то есть. Но датчик уха все-таки удобней.
Если вас собираются изнасиловать - просто расслабьтесь и получайте удовольствие.
http://ideone.com/AvtLrp
О, сколько нам открытий чудных...
http://gcc.gnu.org/onlinedocs/gcc/Dollar-Signs.html
Казалось, причем бы здесь jquery.
π подтвердит
распознавание образов, работа с HTTP, конфигами и ASP.NET, т.е. бот-минураст с авторегером и веб-интерфейсом.
Ну и плюс 2 см к члену, Анонимб, это прикинь, для тебя это в 2 раза, в целых 2 раза...
Сервер или клиент? Если клиент - хуле там делать, если сервер - чем оно лучше питона (на котором веб я тоже не знаю)?
Работа с сетью предполагает многопоточность. Слать/принимать запросы и извлекать инфу из заголовков я умею, а многопоточности не разумею. Таким образом, ты изучишь запросы, а я потоки. Улавливаешь мою мысль? Мы оба останемся в выйгрыше ;)
Как написать распределенную отказоустойчивую систему за 24 часа.
отъебитесь от меня, ничего не знаю я)