Erlang по-русски. Форум: Последние 35 сообщений

Argo "таблицы с {local_content,true} в кластере"

Argo — Sat, 14 Jun 2008 09:19:23 +0000

Имеем кластер, код взят из rabbitmq_mnesia.
Некоторые таблицы имеют атрибут {local_content,true}.
Через какое-то время записи в таких таблицах пропадают.

<(main@root.home)17> io:format("~p~n", [mnesia:table_info(client, all)]).
[{access_mode,read_write},
{active_replicas,['main@root.home']},
{arity,11},
{attributes,[Список полей]},
{checkpoints,[]},
{commit_work,[{index,set,[{3,{ram,210}},{6,{ram,209}}]}]},
{cookie,{{1213,369727,190492},'main@root.home'}},
{cstruct,{cstruct,client,set,[],
['main2@root.home','main@root.home'],
[],0,read_write,
[6,3],
[],true,client,
[Список полей],
[],[],
{{1213,369727,190492},'main@root.home'},
{{2,7},{'main2@root.home',{1213,423604,61968}}}}},
{disc_copies,['main2@root.home','main@root.home']},
{disc_only_copies,[]},
{frag_properties,[]},
{index,[6,3]},
{load_by_force,false},
{load_node,'main@root.home'},
{load_order,0},
{load_reason,local_only},
{local_content,true},
{master_nodes,[]},
{memory,279},
{ram_copies,[]},
{record_name,client},
{record_validation,{client,11,set}},
{type,set},
{size,0},
{snmp,[]},
{storage_type,disc_copies},
{subscribers,[]},
{user_properties,[]},
{version,{{2,7},{'main2@root.home',{1213,423604,61968}}}},
{where_to_commit,[{'main@root.home',disc_copies}]},
{where_to_read,'main@root.home'},
{where_to_write,['main@root.home']},
{wild_pattern,{client,'_','_','_','_','_','_','_','_','_',
'_'}},
{{index,3},210},
{{index,6},209}]
ok>
---------------
Куда копать?

camui "unix timestamp"

camui — Tue, 03 Jun 2008 14:41:12 +0000

в общем вот, получилось. выкладываю код:

timestamp_to_datetime(T) ->
calendar:now_to_universal_time({T div 1000000,T rem 1000000,0}).

возвращает {{Y,M,D},{h,m,s}}

camui "unix timestamp"

camui — Thu, 29 May 2008 13:06:06 +0000

ну например у меня в базе хранится timestamp. как мне его перевести? эти функции я знаю, то это переводит текущее время. может быть можно timestamp перевести в формат который возвращает now()?
подскажи как руками перевести..

architect "unix timestamp"

architect — Wed, 28 May 2008 14:42:54 +0000

calendar:now_to_universal_time(now()).
есть ещё
calendar:now_to_local_time(now()).
Вообще мог бы и руками сам перевести ;)

camui "unix timestamp"

camui — Mon, 26 May 2008 12:36:06 +0000

Проблема вот возникла. Как найти unix timestamp я нашел в прицнипе:
timer:now_diff(now(), {0,0,0}) div 1000000.

а вот как получить из таймстэмпа удобочитаемые дату и время??? помогите плиз.

Natalya "Программист ERLANG 100 тыс."

Natalya — Mon, 28 Apr 2008 10:58:21 +0000

Город: Москва

О компании:
Фирма работает в сфере информационных технологий и является динамично развивающейся компанией обеспечивающей качественные научно-технические разработки в сети интернет. Компания располагается в деловом центре «Панорама» у Триумфальной площади.
Требования:

* Глубокие знания в области функционального и декларативного программирования.
* Опыт практического применения таких языков, как Erlang/OTP, Common Lisp,
* Prolog, Scheme, SQL.
* Хорошие знания систем Unix, в первую очередь Solaris, Linux и FreeBSD.
* Опыт создания web-приложений, знание соответствующих сетевых протоколов,
* протоколов приложений.
* Представление об особенностях работы СУБД Oracle и MySQL.
* Желание на практике реализовывать приемущества как новых технологий, так и
* новых подходов в области разработки ПО.

Если Вас заинтересовала вакансия, то пожалуйста присылайте свои резюме по ниже указанным реквизитам с пометкой «bet_erlang».
Также можете обратиться к нам и узнать, что за компания открыла эту позицию и задать любые вопросы, не отправляя при этом своё резюме.
Контакты - Червякова Наталия
E-Mail: n.chervyakova()ludiagency.ru
ICQ UIN: 485-701-834
Телефон: (495) 930 8997

Alexandr "Требуется программист Erlang"

Alexandr — Sun, 13 Apr 2008 19:08:22 +0000

Требования:
-Глубокие знания в области функционального и декларативного программирования.
-Опыт практического применения таких языков, как Erlang/OTP, Common Lisp, Prolog, Scheme, SQL.
-Хорошие знания систем Unix, в первую очередь Solaris, Linux и FreeBSD.
-Опыт создания web-приложений, знание соответствующих сетевых протоколов, протоколов приложений.
-Представление об особенностях работы СУБД Oracle и MySQL.
-Желание на практике реализовывать приемущества как новых технологий, так и новых подходов в области разработки ПО.
Условия:
-Оформление в соответствии с ТК, сменный график работы
-3/3, офис в центре Москвы.
Просьба резюме отправлять на мейл oraclevac@gmail.com

Cyberon "Литература"

Cyberon — Sun, 06 Apr 2008 10:31:38 +0000

Спасибо

architect "Стек вызовов функций"

architect — Mon, 31 Mar 2008 18:16:24 +0000

Перерыл документацию но так и не нашёл. Можно ли как-то увидеть стек вызова ф-ций?, т.е. историю вызовов: из какой функции вызвали ту, в которой находишься в данный момент. Хотя бы в отладочном режиме. Ведь в эмуляторе эта информация полюбому сохранена, он без неё не может работать.

architect "Как сделать ПРОСТОЙ запуск своего кода в windows?"

architect — Mon, 31 Mar 2008 18:10:31 +0000

Ситуация: я написал приложение и мне надо чтобы пользователь запускал его обычным для себя способом. Т.е. чтобы кликал на файл и запускалось моё erlang приложение.
У меня только 1 способ решения возник: написать свой exe, который тупо запускает erl.exe с необходимой командной строкой, после чего просто выходит.
И второй вопрос: что надо по минимуму залить у пользователью (окромя моих .beam файлов), чтобы у него заработало моё приложение? Оно пользуется некоторыми библиотеками (stdlib и kernel в том числе). И как все файлы должны быть раскиданы по директориям?

Ronin "Литература"

Ronin — Thu, 13 Mar 2008 13:53:07 +0000

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

yushi "Как обойтись без наследования?"

yushi — Tue, 22 Jan 2008 22:21:26 +0000

Действуя по подсказкам уважаемого architect, сделал на пробу два "класса": один хранит значение x и имеет "методы" set_x и get_x, другой является "потомком" первого, а кроме того, имеет "поле" y и, соответственно, методы set_y и get_y. Однако у меня остаётся подозрение, что я в ряде мест изобретаю велосипед...

Получилось вот что:

common.erl

-module(common). -export([rpc/2, loop/2]).


rpc(Pid, Query)->

    Pid ! {self(), Query},

    receive

        {Pid, Answer}->

            Answer

    after 1000->

        {error, "Timeout"}

    end.

loop(Fun, State)-> receive {Pid, Method}-> NewState = Fun(State, {Method, Pid}), loop(Fun, NewState) end.

parent.hrl

-record(parent, {x=0}).

child.hrl

-include_lib("parent.hrl"). -record(child, {parent=#parent{}, y=0}).

parent.erl

-module(parent). -include_lib("parent.hrl"). -export([init/0, do/2]).


do(State, {{set_x, NewX}, Pid})->

    NewState = State#parent{x=NewX},

    Pid ! {self(), {ok, NewX}},

    NewState;

do(State, {{get_x}, Pid})->

    Pid ! {self(), {ok, State#parent.x}},

    State;

do(State, {Any, Pid})->

    Pid ! {self(), {error, ["Unknown method", Any]}},

    State.

init()-> spawn(fun()-> common:loop(fun parent:do/2, #parent{}) end).

child.erl

-module(child). -include_lib("child.hrl"). -export([init/0, do/2]).


do(State, {{set_y, NewY}, Pid})->

    NewState = State#child{y=NewY},

    Pid ! {self(), {ok, NewY}},

    NewState;

do(State, {{get_y}, Pid})->

    Pid ! {self(), {ok, State#child.y}},

    State;

do(State, {Any, Pid}) ->

    NewParent = parent:do(State#child.parent, {Any, Pid}),

    NewState = State#child{parent=NewParent},

    NewState.

init()-> spawn(fun()-> common:loop(fun child:do/2, #child{}) end).

Поймите меня правильно: не то, чтобы я был таким уж фанатом ООП. Но, ИМХО, есть области (например, имитационное моделирование), где без ОО-решений действительно бывает тяжело.

sergesokolov "Как обойтись без наследования?"

sergesokolov — Sun, 13 Jan 2008 14:58:12 +0000

только не забывайте, что таким же образом - то есть совершенно правильно - Госплан считал, сколько Советскому Человеку надо туалетной бумаги.(и прочего)
В тему - лично меня Erlang имено тем и устроил, что нет нужды в запутанной иерархи классов, и проблему можно решать не надувая предварительно абстрактый базовый пузырь.

yushi "Как обойтись без наследования?"

yushi — Wed, 09 Jan 2008 13:39:11 +0000

Второй вариант просто великолепен, спасибо! Это, собственно, пример того подхода, ради которого я и изучаю Эрланг (и Scheme): лаконичный и выразительный результат достигается не за счёт синтаксического сахара, а за счёт продуманности и гибкости базовых конструкций языка (первый вариант мне не подошёл бы, так как часто аналог StateA --- это крокодил на двадцать с лишним полей, и передавать их явно было бы, мягко выражаясь, утомительно =)).

И, конечно, как всякое красивое решение, теперь оно кажется очевидным, да.

architect "Как обойтись без наследования?"

architect — Tue, 08 Jan 2008 13:58:26 +0000

Это я копипастом увлёкся. Вообще хотел так написать:
b(State, {do2, Num, Pid}) -> Pid ! {Return, Num * 2}, State; b(State, Any) -> a(State, Any).
Теперь касательно State. Сам если честно опыта не имею, всего пол года эрланг знаю и ещё ничего стоящего не написал. Поэтому опять ИМХО.
Безтиповость эрланга даёт полную абстракцию данных. Т.е. в переменной может быть любая структура, любой сложности, но ты видишь её всего лишь как 1 переменную. Это способ скрыть сложность. А скрыть сложность - цель лубого программирования на ЯВУ. В отличие от типизованых языков в эрланге есть возможность вызывать функцию сначала для одного типа, а потом ту же самую функцию вызвать для другого типа. И этим надо пользоваться.
"State ведь будет записью довольно сложной структуры" - да, во время выполнения будет. Но тебя не должно это волновать. Ты скроешь эту сложность в полях State. Вернёмся к нашим функциям a и b. Пусть a нужны данные data1 и data2. А b нужны data3 и data4. Если b знает что кушает a (и что возвращает a) и сама пользуется этими данными, то ещё State будет выглядеть как {data1, data2, data3, data4}, а при вызове функции a она будет передавать ей только поля {data1, data2}:
%Базовый процесс (объект) a({Data1, Data2} = State, {do1, Num, Pid}) -> Pid ! {retun, Num + 1}, State.

%производный процесс (объект) b({Data1, Data2, Data3, Data4} = State, {do1, Num, Pid}) -> Pid ! {Return, Num * 2}, State; b({Data1, Data2, Data3, Data4}, Any) -> {NewData1, NewData2} = a({Data1, Data2}, Any), {NewData1, NewData2, Data3, Data4}.
Если b не знает, что кушает a, то она будет передавать её просто переменную StateA, и State у функции b будет таким: {data3, data4, StateA}. Разве это похоже на сложные структуры?). Даже если функция a потом вызывает функцию c, то b об этом ничего не знает, и соответственно не видит сложность структуры StateA. Этот вариант предпочтительнее первого.
%Базовый процесс (объект) a({Data1, Data2} = State, {do1, Num, Pid}) -> Pid ! {retun, Num + 1}, State.

%производный процесс (объект) b({Data3, Data4, StateA} = State, {do1, Num, Pid}) -> Pid ! {Return, Num * 2}, State; b({Data1, Data2, StateA}, Any) -> NewStateA = a(StateA, Any), {Data3, Data4, NewStateA}.

yushi "Как обойтись без наследования?"

yushi — Mon, 07 Jan 2008 23:29:40 +0000

О, то что надо, спасибо (единственное что --- я не очень понимаю, зачем в функции b сопоставление с образцом State, {do1, Num, Pid} --- ведь в функции a уже есть обработка этого случая, и b вызовет её благодаря
b(State, Any) ->
a(State, Any),
правильно?

Вы, собственно, практически ответили на мой вопрос --- я, действительно, слишком увлёкся метафорой "процесс это объект" и не сообразил, что для вызова функции из другого модуля не обязательно запускать функцию разбора сообщений из этого модуля.

Единственный оставшийся вопрос --- в реальной ситуации State ведь будет записью довольно сложной структуры, правильно? Кроме того, функции модулей-"потомков" могут ожидать обнаружить в ней разный набор дополнительных полей. Как правильно поступить в этом случае? Завести одно нетипизированное поле, как предлагает gogabr (а в нём --- ещё одно, на случай дополнительного "наследования", и т.д.)? Или есть ещё какие-то решения?

"Вообще мыслить объектами (т.е. их методами) ИМХО неправильно" --- опять же, повторюсь: целью исходного поста и было выяснить, каков "Erlang way" в таких ситуациях, а не "как реализовать наследование на Эрланге". См, например, тему этого треда. =)

dmitriid "xmlrpc"

dmitriid — Mon, 07 Jan 2008 12:27:14 +0000

Однако :)

architect "Как обойтись без наследования?"

architect — Sun, 06 Jan 2008 19:58:18 +0000

Везде же написано, что аналог объекта в эрланге - это процесс. А что такое процесс? Это функция. Данные храним в переменных состояния, запросы/ответы получаем через механизм сообщений. Приведу пример.

start() -> A = new_proc(a, [[]]), %Создали "объект" А, B = new_proc(b, [[]]), %А теперь Б B ! {do1, 10, self()}. %вызвали "метод".


%Базовый процесс (объект)

a(State, {do1, Num, Pid}) ->

 Pid ! {retun, Num + 1},

 State.
%производный процесс (объект)

b(State, {do1, Num, Pid}) ->

  Pid ! {Return, Num * 2},

  State;

b(State, Any) ->

  a(State, Any).
loop(Fun, State) ->

 receive

  Data ->

   NewState = Fun(State, Data)

 loop(Fun, NewState).

new_proc(Fun, Arg) -> spawn(?MODULE, loop, [Fun, Arg]).

Но это одниночное наследование. А вот множественное:
%одно свойство объекта a(State, {do1, Num, Pid}) -> Pid ! {retun, Num + 1}, State.


%второе свойство объекта

b(State, {do2, Num, Pid}) ->

  Pid ! {Return, Num * 2},

  State.
start() ->

  A = create_proc( [a/2], []),

  B = create_proc( [b/2], []),

  AB = create_proc( [b/2, a/2], []),

  AB ! {do1, 10, self()}.      %вызвали "метод".
runner(Fun, Args) ->

  case catch Fun(Args) of

    {'EXIT', _} ->

      Args;

    NewState ->

      throw {ok, NewState}

    end.
poly_object(Components, State) ->   %Components - список функций,

                                    %объединённых в объекте

  case catch lists:foldl( runner/2, State, Componets ) of

    {'ERROR', _} ->

      poly_object(Components, State);

    {ok, NewState} ->

      poly_object(Components, NewState);

  end.

create_proc(Components, InitState) when is_list(Components) -> spawn(?MODULE, poly_object, [Components, InitState]).

Вообще играясь с высокоуровневыми ф-ями можно получить любой "объект" и собирать "объекты" прямо во время выполнения - своего рода самомодифицирующийся код.

PS. Вообще мыслить объектами (т.е. их методами) ИМХО неправильно, у эрлага все данные слишком абстрактны и работать надо с ними на высоком уровне. В конце концов можно вызвать ЛЮБУЮ функцию для ЛЮБЫХ данных, в ООП языках так низя, там есть типы, поэтому там и "назначают" функции типам - обединяют их в объект. В эрланге "назначают" задачи процессам...

architect "Как обойтись без наследования?"

architect — Sun, 06 Jan 2008 19:56:38 +0000

удалите плиз это сообщение, случайно 2 раза запостил

yushi "Как обойтись без наследования?"

yushi — Sun, 06 Jan 2008 15:00:32 +0000

Задача модели: запуститься с некоторыми характеристиками транзакционных издержек и проработать некоторое время. Затем вывести граф получившихся торговых связей. Соответственно, задача потребителя: оценить своё состояние, если испытывается потребность в ресурсе, найти его продавцов, оценить выгодность сделки с каждым из них, приобрести ресурс наиболее выгодным образом. Задача продавца: произвести ресурс, предложить его потребителям, если никто не покупает --- изменить характеристики предложения. Мне, в принципе, казалось, что это очевидно из моей предыдущей реплики. Ну, в любом случае теперь для обсуждения архитектуры, кажется, точно сказано достаточно.

"на С++ ... необязательно затевать иерархию" --- обязательно, если не хочется одноразового неподдерживаемого кода.

Что тут "с лёгкостью ложится на Эрланг", мучительно не понимаю. Попробую ещё раз, м.б., мне не удалось как следует объяснить: "функциональность экономики" выходит за рамки обсуждаемой темы. Я рассказывал о части задачи по имитационному моделированию, в которой есть агенты, умеющие определённый набор вещей. Но при этом одна часть этих агентов имеет один набор дополнительных умений и данных о своём состоянии, а другая --- другой.

Вопрос: как спроектировать систему на Эрланге для реализации этой модели? С помощью behaviours, как предлагает пользователь gogabr? А если, действительно, уровней в иерархии больше двух (экономические агенты делятся на потребителей и производителей, а производители на производителей пушек и производителей масла, например)? А как хранить характеристики агентов?

Tonal "Как обойтись без наследования?"

Tonal — Sat, 05 Jan 2008 18:21:14 +0000

Тут, даже на С++, на мой взгляд, необязательно затевать иерархию.
Вполне достаточно вынести обшюю функциональность в отдельный модуль.
Что с лёгкостью ложиться на Erlang - модуль процессов для продавцов, модуль процессов для покупателей и модуль с функциональностью экономики. :-)

Но, ты рассказал только устройство модели, в объектах и их функциональности. А задачи, ею решаемые не рассказал.

Соответственно, с позиций чистого ФП здесь решать пака нечего. :-)

P.S. Кстати, сам работаю на Qt + Python.
Жасль, что для Erlang-а (да и для Haskell) до сих пор нет биндинга к Qt.

yushi "Как обойтись без наследования?"

yushi — Sat, 05 Jan 2008 01:18:47 +0000

Как оно устроено "в ФП вообще", я примерно понимаю, благо, опыт написания всякой мелочи на Scheme имеется. Интересует именно Эрланг, который, во-первых, благодаря своим независимым процессам в каком-то смысле как раз ОО-язык, более того, "ОО-язык as it shall be" (я по работе много пишу на Qt и регулярно замечаю, как легко было бы многие подаваемые как killer feature возможности этой библиотеки реализовать на Эрланге), а во-вторых, в отличие от Scheme/Haskell/*ML, широко применяется на практике, благодаря чему уже должны были сложиться типовые решения типовых проблем. Шаблоны проектирования, ага.

Ладно, что-то разговор беспредметный получается. Приведу конкретный пример.

Предположим, что мы пишем программу имитационного моделирования. Модель описывает покупателей и продавцов. И продавцы, и покупатели умеют а)вносить деньги на свой расчётный счёт и тратить их, б)оценивать своё географическое положение, географическое положение партнёра и транзакционные издержки, зависящие от удалённости партнёра. Продавцы при этом умеют также производить единицы продукции; потребители умеют испытывать нужду в единицах продукции и покупать их у продавцов. В реальном коде на C++ был написан базовый класс "экономический агент", в котором были расписаны операции с банковским счётом и вычисление издержек; от него были унаследованы классы "продавец" и "покупатель", реализовывавшие свои специфические методы.

Как ту же самую модель следовало бы писать на Эрланге?

Tonal "Как обойтись без наследования?"

Tonal — Fri, 04 Jan 2008 23:33:35 +0000

Есть, но разбиение здесь совершенно другое.
В ООП разбиение идёт от сущьностей (объекты) и их иерархий, а в ФП разбиение идёт от действий, которые тебе нужно выполнить. :-)

yushi "Как обойтись без наследования?"

yushi — Fri, 04 Jan 2008 23:00:50 +0000

Ну да, так и есть. Собственно, в этом и заключался вопрос --- "есть ли в Эрланге типовое решение для проблем, которые в ООП решают с помощью наследования?", а не "как в Эрланге реализовать наследование?".

Плохо получилось сформулировать, к сожалению.

17dufa "xmlrpc"

17dufa — Fri, 04 Jan 2008 22:03:11 +0000

дело было в антивирусе, он блокировал работу.

17dufa "xmlrpc"

17dufa — Fri, 04 Jan 2008 20:09:59 +0000

Здраствуйте
взял либу для работы с xmlrpc, start_link отрабатывает, а вот call постоянно вылетает - {error,closed}. запустить пытаюсь стандартный пример на числа фибоначчи:
xmlrpc:start_link(4567,1000,100000,{fib_server,handler},undefined)
это отрабатывает, а вот это:
xmlrpc:call({127, 0, 0, 1}, 4567, "/", {call, fib, [0]}).
вылетает

gogabr "Как обойтись без наследования?"

gogabr — Fri, 04 Jan 2008 16:32:49 +0000

Я бы просто хранил поля родителя впрямую, а для детских имел бы в родительской структуре отдельное нетипизированное поле (вообще говоря, вся типизация ведь динамическая). В каких-то случаях только его можно передавать детским функциям.
Но, в общем, у меня уже складывается впечатление, что весь этот OO-разговор -- попытка описать эрланговские идиомы на несвойственном для них языке. Или, наоборот, найти привычные конструкции там, где их нет.

yushi "Как обойтись без наследования?"

yushi — Fri, 04 Jan 2008 15:13:59 +0000

Ага, спасибо. Примерно понял, буду смотреть.

А как при этом принято хранить состояние? Мне кажется правильным делать структуру state, у которой будут поля, скажем, parent и child, хранящие "поля" родителя и потомка соответственно. Но слегка смущает, что при этом получается, что state будет описываться несколько раз --- для родителя (как имеющая только поле child) и каждого из потомков (для каждого со своим типом в поле parent); позволяет ли такое Эрланг и если да, то как?

gogabr "Как обойтись без наследования?"

gogabr — Thu, 03 Jan 2008 08:23:24 +0000

Disclaimer: у меня у самого опыта негусто.
Насколько я понимаю, приблизательно для этого предначзнаены behaviours (хотя делают они меньше, чем ты хочешь).

Это более или менее похоже на твой третий вариант, с точностью до двух деталей:
1. В "родительском" модуле (собственно описании поведения) запоминаются не функции "потомка" (модуля, реализующего поведение), а просто его имя. Потом их можно звать через Mod:fun (Arg) (где Mod -- переменная). Язык-то, в общем, интерпретируемый и связывание позднее.
2. Есть некоторая языковая поддержка, которая позволяет компилятору проверить, все ли нужные "методы" в "потомке" определены (см. функцию behaviour_info).

В исходниках библиотек можно посмотреть, скажем, модули gen или gen_server, которые свои поведения реализуют.

Наследовать одно поведение от другого (то есть строить более чем двухуровневую иерархию) можно, но довольно неудобно.

yushi "Как обойтись без наследования?"

yushi — Thu, 03 Jan 2008 02:26:38 +0000

Доброго времени суток.

Никто не в курсе, существует ли в Эрланге готовый шаблон проектирования для ситуации, когда есть несколько в значительной степени пересекающихся наборов данных и вещей, которых можно с этими данными делать?

В ОО-языке я бы, понятно, создавал иерархию классов, запихивая общие поля и методы в базовый класс, а специфичные для конкретных случаев --- в классы-наследники.

Насколько я понимаю, в Эрланге на смену объекту ОО-языка приходит функция с хвостовой рекурсией, разбирающая сообщения с помощью конструкции receive и вызывающая сама себя с состоянием процесса в качестве аргумента. А существует ли при этом аналог наследования или способ обходиться без него?

На ум приходит несколько решений, и каждое из них чем-нибудь да кажется уродливым:
-в функции, запускающей процесс "потомка" (модуля, работающего со специфичными для конкретного случая данными), spawn-ить процесс "родителя" (модуля, работающего с общими данными), запоминать его PID и передавать ему все сообщения, которые "потомок" не смог распарсить сам;
-для хранения состояния процесса определять структуру (в смысле запись, record) с общими данными, для полей и методов "потомка" выделить 2 списка или ETS и в "конструкторе" (т.е. функции, вызываемой при старте процесса) заполнять этот список кортежами вида {имя_поля, значение} и {имя_метода, метод}; при разборе сообщений каждый раз искать поля и методы в этой структуре;
-состояние процесса (аргумент рекурсивной функции, содержащей конструкцию receive) сделать замыканием (closure), возвращающим функцию-диспетчер, возвращающую, в свою очередь, поля и методы "объекта"; в функциях-диспетчерах "потомков" предусмотреть обращение к функции-диспетчеру "предка".

(Если получилось мутно, могу проиллюстрировать каждую из идей небольшим примером.)

Подозреваю, что правильное решение вообще не предполагает рукосуйной имитации ООП --- но мой искалеченный C++ мозг его не находит. =)

qrilka "Как посылать сообщения?"

qrilka — Tue, 18 Dec 2007 14:20:32 +0000

Естественно оно выдаст undef - функция-то не экспортирована, поэтому spawn её не видит.

Cyberon "Как посылать сообщения?"

Cyberon — Fri, 14 Dec 2007 22:06:20 +0000

Отказался от идеи посылки сообщений о вычисленном хеше клиентам. Написал код сервера и набросок кода клиента. Сервер запускается без проблем, но клиент не может к нему подсоединиться - выдает ошибку.
Запуск сервера


erl -sname brute
Eshell V5.6  (abort with ^G)
(brute@warez)1> server:start_server([{[1,2],[\"abcde\",\"abjasf\",\"ds\",\"1234\",\"12345\"]}]).
User list = []
 Task list = [{[1,2],
               [\"ds\",\"1234\",\"12345\"],
               [{1,5,\"abcde\"},{1,6,\"abjasf\"}]}]
true
(brute@warez)2> 

Запуск клиента
erl -sname client
Eshell V5.6  (abort with ^G)
(client@warez)1> client:start_client(brute@warez).
 <0.37.0>

=ERROR REPORT==== 14-Dec-2007::22:01:36 ===
Error in process <0.37.0> on node 'client@warez' with exit value: {undef,[{client,client,['brute@warez']}]}

(client@warez)2> 

Код сервера
<%%% Процесс сервера службы отправки сообщений
%%% task[{[Hash],[RangeSymbol]}] 

-module(server).
-export([start_server/1, server/1, server/2, next/1, next2/1]).
-import(lists, [keymember/3, keysearch/3, keydelete/3, keyreplace/4, unzip/1,
  subtract/2, keyreplace/4, split/2, nth/2, map/2]).
-include(\"mess_interface.hrl\").

%%% Список пользователей имеет формат [{ClientPid1, Hashes1, String1, Task1},
%%% {ClientPid22, Hashes22, String22, Task22}, ...]
%%% Tasks = [ { [{I, L, Sym}], [Hash], ClientRange} ]
%%% Task = {[Hash], Prefix, Range}
%%% Result = [{Hash, Pass}]
server(User_List, [{Prefix, Hashes, ClientRange}|Task_List]) ->
  io:format(\"User list = ~p~n Task list = ~p~n\", [User_List,[{Prefix, Hashes, ClientRange}|Task_List]]),
  receive
  #logon{client_pid=From} ->
    case keymember(From, 1, User_List) of
      true ->
        server(User_List, Task_List);
      false ->
        String = makeString(Prefix),
        From!{Hashes, String, ClientRange},
        New_User_List=[{From, Hashes, String, ClientRange}|User_List],
        server(New_User_List, next([{Prefix, Hashes, ClientRange}|Task_List]))
    end;
  {'EXIT', From, _} ->
    {value, {_, Old_Hashes, String, Task} } = keysearch(From, 1, User_List),
    New_User_List=keydelete(From, 1, User_List),
    server(New_User_List, [makeTask(String, Old_Hashes, Task)|Task_List]);
  #notfound{client_pid=From} ->
    String = makeString(Prefix),
    New_User_List = keyreplace(From, 1, User_List, {From, Hashes, String, ClientRange}),
    From!{Hashes, String, ClientRange},
    server(New_User_List, next([{Prefix, Hashes, ClientRange}|Task_List]));
  #found{client_pid=From, result=Result} ->
    {Solved_Hashes,_} = unzip(Result),
    New_Hashes=subtract(Hashes,Solved_Hashes),
    String = makeString(Prefix),
    From!{New_Hashes, String, ClientRange},
    master!Result,
    New_User_List = keyreplace(From, 1, User_List, {From, Hashes, String, ClientRange}),
    server(New_User_List, next([{Prefix, New_Hashes, ClientRange}|Task_List]))
end;
server(_, []) ->
  exit(normal).

server(Task_List) ->
  process_flag(trap_exit, true),
  New_Task_List = makeTasks(Task_List),
  server([], New_Task_List).

%%% Запуск сервера

start_server(Task_List) ->
  register(bruteserver, spawn(?MODULE, server, [Task_List])).

makeTasks([{Hashes,Range}|Rest]) ->
  {ServerRange,ClientRange}=split(length(Range)-3, Range),
  [{Hashes, ClientRange, makeServerSide(ServerRange)}|makeTasks(Rest)];
makeTasks([]) -> [].

makeString([{I,_,Sym}|Rest]) -> [nth(I,Sym)|makeString(Rest)];
makeString([]) -> [].

makeTask(String, Old_Hashes, Task) ->
  {map(fun(x)->{1, 1, x} end, String), Old_Hashes, Task}.

makeServerSide([Sym|Rest]) -> [{1, length(Sym), Sym}|makeServerSide(Rest)];
makeServerSide([]) -> [].

next([{Prefix, _, _}|Rest]) ->
  {F,Pnext}=next2(Prefix),
  if
    F==1 -> [Pnext|Rest];
    true -> Rest
  end.

next2([])->	{0,[]};
next2([{I,L,Sym}|Rest])->
  if
    I<L->	{1,[{I+1,L,Sym}|Rest]};
    true->
      {Flag,R}=next2(Rest),
      {Flag,[{1,L,Sym}|R]}
  end.
>

Код клиента
<-module(client).
-export([start_client/1, passes/2, pass/1]).

client(Server_Node)->
{bruteserver, Server_Node}!{logon, self()},
receive
  A->io:format(\"client got ~p~n\",[A])
end.

start_client(Server_Node)->
spawn(client, client, [Server_Node]).

passes(Hashes,Range)->
  [P||P<-pass(Range), H<-Hashes, erlang:md5(P)==H].

pass([X|Xs])->
[[A|B] || A<-X, B<-pass(Xs)];
pass([])-> [[]].>

dmitriid "Литература"

dmitriid — Sun, 18 Nov 2007 11:42:15 +0000

Еще обширный ответ здесь: http://rsdn.ru/forum/message/2733230.aspx

dmitriid "Литература"

dmitriid — Sat, 17 Nov 2007 11:33:31 +0000

К сожалению, именно эту статью найти пока не смог. Есть вот такое:

Towards a Strongly Typed Functional Operating System (2003)
Arjen van Weelden, Rinus Plasmeijer

http://citeseer.ist.psu.edu/vanweelden03towards.html

Cyberon "Литература"

Cyberon — Fri, 16 Nov 2007 20:07:29 +0000

На сайте softcraft.ru нашел статью "Сильные стороны функционального программирования". В списке литературы в конце упоминалась книга P.Henderson. Purely Functional Operating Systems. 1982 Было бы интересно почитать что такое функциональная операционная система. Выложите, пожалуйста, ссылку.