Erlang на дотнете
От: yumi  
Дата: 27.10.08 06:29
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Давайте покажем какой-нибудь фреймворк для мегапараллелизма а-ля Erlang, или более удобный аналог BLToolkit, или фреймворк для построения WPF приложений, или еще для чего-нибудь такого, чтобы мировая общественность поняла: вот он, свет новых знаний.


Вот сделать бы выделенное, было бы реально круто! Только боюсь поверх .net это нереально реализовать Только если .net сам не вырастет до такого уровня.

27.10.08 14:51: Ветка выделена из темы Почему C# не Немерле
Автор: AndrewVK
Дата: 26.10.08
— AndrewVK
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re: Erlang на дотнете
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.10.08 06:57
Оценка: +1 -1
Здравствуйте, yumi, Вы писали:
Y>Вот сделать бы выделенное, было бы реально круто! Только боюсь поверх .net это нереально реализовать Только если .net сам не вырастет до такого уровня.
Не вижу практически никаких проблем. Как только появилось LCG, то есть с второго фреймворка, никаких принципиальных причин не получить Erlang поверх CLR, афаик, нету.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Erlang на дотнете
От: cadet354 Россия
Дата: 27.10.08 09:33
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>Не вижу практически никаких проблем. Как только появилось LCG, то есть с второго фреймворка, никаких принципиальных причин не получить Erlang поверх CLR, афаик, нету.
а что хочется от Erlang на .net ?
Лично мне не хватает actor model, и ОТP+Mnesia, и совсем не понятно чем может помочь мне в этом LCG.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Erlang на дотнете
От: Didro Россия home~pages
Дата: 27.10.08 10:45
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Не вижу практически никаких проблем. Как только появилось LCG, то есть с второго фреймворка,

> никаких принципиальных причин не получить Erlang поверх CLR, афаик, нету.

Вот, Lazy Cjow Rhrr, в свое время высказался
Автор: Lazy Cjow Rhrr
Дата: 12.12.06
, почему он считает, что

"имплементация Erlang style concurrency под обычные VM очень проблематична (“очень проблематична” – это потому что я ненавижу слово “невозможно”)".


Мне тогда его аргуметы показались достаточно убительными, не думаю, что сейчас что-нибудь изменилось.
erlang clr
Re[3]: Erlang на дотнете
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.10.08 11:10
Оценка:
Здравствуйте, Didro, Вы писали:

D>Мне тогда его аргуметы показались достаточно убительными, не думаю, что сейчас что-нибудь изменилось.

Я так понял, что описанные проблемы всего лишь не позволят сделать систему с performance-характеристиками настоящего эрланга.
Тем не менее, вполне можно получить приемлемо прикольную систему, в которой поддерживается высокий уровень параллелизма.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Erlang на дотнете
От: Didro Россия home~pages
Дата: 27.10.08 11:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Я так понял, что описанные проблемы всего лишь не позволят сделать систему с performance-характеристиками настоящего эрланга.

S>Тем не менее, вполне можно получить приемлемо прикольную систему, в которой поддерживается высокий уровень параллелизма.

На мой взгляд все несколько "хуже"(подругому) — мы не сможем обеспечить прерывание (вытеснение) легковесного потока из любого MSIL-кода, а в Эрланге вытеснение (передача управления другому потоку) реализована на уровне VM. Соответственно в .NET легковесные потоки будут уже совсем другими нежели легковесные потоки Эрланга.
Re[5]: Erlang на дотнете
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.08 11:01
Оценка: +1
Здравствуйте, Didro, Вы писали:
D>На мой взгляд все несколько "хуже"(подругому) — мы не сможем обеспечить прерывание (вытеснение) легковесного потока из любого MSIL-кода, а в Эрланге вытеснение (передача управления другому потоку) реализована на уровне VM. Соответственно в .NET легковесные потоки будут уже совсем другими нежели легковесные потоки Эрланга.
Честно признаюсь, я в ерланге не великий гуру. И даже особенной потребности в нем на дотнете не испытываю. Я его привел только как пример того, куда можно было бы копнуть в рамках демонстрации мощи Nemerle по созданию фреймворков.

Ок, давайте забъем на эрланг, воспроизведем хотя бы рандеву из Comega. Или посмотрим на этот, как его, фреймворк параллелизации и асинхронного выполнения, который сейчас народ на втором вроде шарпе точит, и сделаем его с более человеческим лицом.
Чтобы я мог писать как бы синхронный код, а он превращался автоматически в асинхронный. То есть после окончания async operation продолжалось исполнение моего кода, так же как в случае blocking call, но его мог исполнять другой поток. Это бы позволило значительно хардкорнее оптимизировать работу с пулом потоков.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Erlang на дотнете
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.08 14:21
Оценка:
Здравствуйте, Didro, Вы писали:

D>На мой взгляд все несколько "хуже"(подругому) — мы не сможем обеспечить прерывание (вытеснение) легковесного потока из любого MSIL-кода, а в Эрланге вытеснение (передача управления другому потоку) реализована на уровне VM.


Насколько я в курсе — возможность реализации зеленых потоков заложена в CLR изначально, но самим МС не реализована. Но, при ее реализации (в виде плагина к CLR) внтури MSIL, зеленые потоки абсолютно неотличимы от нормальных. Т.е. никаких явных переключений контекста в MSIL не нужно делать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[6]: Erlang на дотнете
От: Klapaucius  
Дата: 14.11.08 12:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ок, давайте забъем на эрланг, воспроизведем хотя бы рандеву из Comega.


А макросы для параллелизма на join-calculus, как в Comega, в Nemerle есть. Я, правда, не знаю, насколько они пригодны для использования.

using Nemerle.IO;
using Nemerle.Concurrency;

namespace Test 
{
    class RendezVous
    {
        class Thunk
        {
            [ChordMember]
            public Reply (j : int) : void;

            public Wait () : int
            chord {
              | Reply => j
            }
        }
        
        public f (i : int) : int
        {
            def t = Thunk ();
            af (i, t);
            t.Wait ()
        }

        [ChordMember]
        private af (i : int, t : Thunk) : void;

        public g (j : int) : int
        chord {
          | af =>
            t.Reply (j);
            i
        }
    }

    module Main
    {
        Main () : void
        {
            def rv = RendezVous ();

            async 
            {
                def i = rv.f (3);
                assert (i == 13)
            }

            async
            {
                def i = rv.g (13);
                assert (i == 3)
            }
        }
    }
}
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[6]: Erlang на дотнете
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.08 00:56
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Didro, Вы писали:


D>>На мой взгляд все несколько "хуже"(подругому) — мы не сможем обеспечить прерывание (вытеснение) легковесного потока из любого MSIL-кода, а в Эрланге вытеснение (передача управления другому потоку) реализована на уровне VM.


AVK>Насколько я в курсе — возможность реализации зеленых потоков заложена в CLR изначально, но самим МС не реализована. Но, при ее реализации (в виде плагина к CLR) внтури MSIL, зеленые потоки абсолютно неотличимы от нормальных. Т.е. никаких явных переключений контекста в MSIL не нужно делать.


О, полгода назад я искал зеленые потоки, помня твои сообщения. Поверил тебе, пнимаешь. И где она, эта реализация? Да нет ее. Весь мир ее ждет, чтоб наконец зажить по человечески и перестать думать о тредпулах и явных конечных автоматах. Можно — почему никто не напишет? То что есть сейчас, и удалось найти — зеленые потоки делаются хаком и работают на файберах. Говно полное, простите. На С++ проще писать, там хотя бы файберы без проблем оборачиваются.

А раз этого нет, то какая yf ghfrnbrt разница, что там в теории заложено в CLR?
Re[6]: Erlang на дотнете
От: desco США http://v2matveev.blogspot.com
Дата: 26.11.08 17:06
Оценка: 53 (3)
Здравствуйте, Sinclair, Вы писали:

<skipped/>

S>Ок, давайте забъем на эрланг, воспроизведем хотя бы рандеву из Comega. Или посмотрим на этот, как его, фреймворк параллелизации и асинхронного выполнения, который сейчас народ на втором вроде шарпе точит, и сделаем его с более человеческим лицом.

S>Чтобы я мог писать как бы синхронный код, а он превращался автоматически в асинхронный. То есть после окончания async operation продолжалось исполнение моего кода, так же как в случае blocking call, но его мог исполнять другой поток. Это бы позволило значительно хардкорнее оптимизировать работу с пулом потоков.

ну вот например как выглядят asynchronous workflows из F#
(пример из нижней ссылки)
let links_async (requestUriString:string) = 
  async {
          let request = WebRequest.Create(requestUriString)
          let! response = request.AsyncGetResponse()
          let reader = new StreamReader(response.GetResponseStream())
          let! html = reader.AsyncReadToEnd()
          let links = get_links html
          return requestUriString, links |> Seq.length 
        }


Особые умельцы смогли адаптировать библиотеки F# для использования из C#. Выглядит тоже неплохо:

Func<string, Async<Tuple<string, int>>> links_async = requestUriString =>
    from _ in AsyncExtensions.StartWorkflow
    let request = WebRequest.Create(requestUriString)
    from response in request.AsyncGetResponse()
    let reader = new StreamReader(response.GetResponseStream())
    from html in reader.AsyncReadToEnd()
    let links = get_links(html)
    select new Tuple<string, int>(requestUriString, links.Count());
... << RSDN@Home 1.2.0 alpha 4 rev. 1090>>
Re[7]: Erlang на дотнете
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.11.08 20:08
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>А раз этого нет, то какая yf ghfrnbrt разница, что там в теории заложено в CLR?


Э... согласен со всеми рассуждениями, но вопрос один воникает... Ты что на дотнет перешел ?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Erlang на дотнете
От: Gaperton http://gaperton.livejournal.com
Дата: 26.11.08 22:50
Оценка:
Здравствуйте, VladD2, Вы писали:

G>>А раз этого нет, то какая yf ghfrnbrt разница, что там в теории заложено в CLR?


VD>Э... согласен со всеми рассуждениями, но вопрос один воникает... Ты что на дотнет перешел ?


Влад, я наемный менеджер, и делаю то, что требуется конкретной организации . Мне просто нельзя иметь предрассудки . Скажать, что я перешел на .NET — не вполне корректно . Подробнее:

Выбирали платформу для прикладного скриптинга. Желательно, чтобы из скрипта был хороший интероп, скажем, с COM. И надо было, чтобы скрипты выполнялись для тысяч потоков. .NET с грин тредами бы вполне прокатил, как лучший вариант. Однако он отпал, потому, что как оказалось, никаких грин тредов там на самом деле нет. Осталось — поднимать скриптовые машины из файберов из С++, как и хотели изначально. Из машин — spidermonkey, и старый добрый windows scripting host.

Вообще же, .NET весьма хороший вариант для миграции с С++ под вендой. Потому, что у него хороший интероп на венде, потому, что снимает очень много гемора в сравнении с С++, скажем, при разработке гуя, и потому, что можно смешивать с уже написанным С++ и COM, не выбрасывая старого кода, а мигрируя постепенно.

И потому, что хорошего С++ программиста стало очень сложно найти. Все реже и реже хотят хорошие программисты ковыряться с С++. Да и начинающие предпочитают более свежий C#, потому что модно. Рожу кривят. А рынок руда сейчас сам знаешь какой. Ну, до кризиса был.

Так что жизнь заставляет.
Re[7]: Erlang на дотнете
От: cadet354 Россия
Дата: 27.11.08 06:43
Оценка:
Здравствуйте, desco, Вы писали:
спасибо за ссылку

D>Особые умельцы смогли адаптировать библиотеки F# для использования из C#. Выглядит тоже неплохо:

D>

D>Func<string, Async<Tuple<string, int>>> links_async = requestUriString =>
D>    from _ in AsyncExtensions.StartWorkflow
D>    let request = WebRequest.Create(requestUriString)
D>    from response in request.AsyncGetResponse()
D>    let reader = new StreamReader(response.GetResponseStream())
D>    from html in reader.AsyncReadToEnd()
D>    let links = get_links(html)
D>    select new Tuple<string, int>(requestUriString, links.Count()); 
D>

но даже эти умельцы признают, что не все так хорошо:

For example, there are several things that cannot be done through LINQ expressions such as the following:

* if/then/else
* while loops
* try/catch/finally
* methods that return void

These above constructs don't have a 1 to 1 mapping with LINQ. As a result, our code may have to look significantly different than the F# code that we'd write.

P.S. Вот почему на "птичем" языке это возможно (я про F#), а в майнстриме C# нет,
какую-ту хрень типа dynamics добавляют.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Erlang на дотнете
От: Кондраций Россия  
Дата: 29.11.08 12:39
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Didro, Вы писали:


D>>На мой взгляд все несколько "хуже"(подругому) — мы не сможем обеспечить прерывание (вытеснение) легковесного потока из любого MSIL-кода, а в Эрланге вытеснение (передача управления другому потоку) реализована на уровне VM.


AVK>Насколько я в курсе — возможность реализации зеленых потоков заложена в CLR изначально, но самим МС не реализована. Но, при ее реализации (в виде плагина к CLR) внтури MSIL, зеленые потоки абсолютно неотличимы от нормальных. Т.е. никаких явных переключений контекста в MSIL не нужно делать.


Что такое "зелёные потоки"? Мне гугел в основном про катаклизмы пишет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Сообщение заговорено потомственным колдуном, целителем и магом в девятом поколении!
Модерирование или минусование сообщения ведет к половому бессилию, венерическим заболеваниям, венцу безбрачия и диарее!
Re[7]: Erlang на дотнете
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.11.08 00:07
Оценка: 2 (1)
Здравствуйте, Кондраций, Вы писали:

К>Что такое "зелёные потоки"? Мне гугел в основном про катаклизмы пишет.


Какой то не такой у тебя гугел
http://en.wikipedia.org/wiki/Green_threads
... << RSDN@Home 1.2.0 alpha 4 rev. 1115 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: Erlang на дотнете
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.11.08 00:07
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>О, полгода назад я искал зеленые потоки, помня твои сообщения. Поверил тебе, пнимаешь. И где она, эта реализация?


А я никогда готовой реализации и не обещал. Я всего лишь говорил о том, что возможность эта предусмотрена как со стороны CLR Host (создание потоков абстрагировано), так и со стороны FCL (класс Thread начиная с 1.1 не завязан на ID аппаратного потока).
... << RSDN@Home 1.2.0 alpha 4 rev. 1115 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re: Erlang Style Concurrency for .NET -- CCR
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.12.08 10:10
Оценка: 92 (2)
Erlang Style Concurrency for .NET Applications Part 1 &mdash; CCR

Erlang allows for massively scalable concurrency, often with millions of lightweight, thread-like components known as actors. Unfortunately, using Erlang requires rewriting all of your legacy code into a rather esoteric language. But there are other options, such as the little known CCR platform that was developed by .NET's robotics department.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Erlang Style Concurrency for .NET -- CCR
От: cadet354 Россия
Дата: 15.12.08 07:16
Оценка:
Здравствуйте, eao197, Вы писали:

E>Erlang Style Concurrency for .NET Applications Part 1 &mdash; CCR

E>

E>Erlang allows for massively scalable concurrency, often with millions of lightweight, thread-like components known as actors. Unfortunately, using Erlang requires rewriting all of your legacy code into a rather esoteric language. But there are other options, such as the little known CCR platform that was developed by .NET's robotics department.

может поможите с этим?
[CCR] Не понятна работа Choice
Автор: cadet354
Дата: 26.11.08
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Erlang Style Concurrency for .NET -- CCR
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.12.08 08:18
Оценка:
Здравствуйте, cadet354, Вы писали:

C>может поможите с этим?

C>[CCR] Не понятна работа Choice
Автор: cadet354
Дата: 26.11.08


Не смогу -- я не пользуюсь ни CCR, ни .NET. Просто мне эта ссылка в новостях попалась.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.