8000 Fix creating new ports in erlang example · Issue #3 · selectel/alberto · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fix creating new ports in erlang example #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
negativ opened this issue Mar 5, 2015 · 6 comments
Open

Fix creating new ports in erlang example #3

negativ opened this issue Mar 5, 2015 · 6 comments

Comments

@negativ
Copy link
Contributor
negativ commented Mar 5, 2015

Yours erlang example creates new port on every iteration. I think it's wrong and script should be fixed to the version like that:

#!/usr/bin/env escript
%%! -noshell -noinput
-mode(compile).
-define(ME, filename:basename(escript:script_name())).
-define(PRINT(STR, PARAMS), io:format("~s: " ++ STR ++ "~n", [?ME | PARAMS])).

loop(Port) ->
    port_command(Port, term_to_binary({"Hello world!", erlang:now()})),
    receive
        {_, {data, Data}} ->
            ?PRINT("~p", [binary_to_term(Data)]),
            loop(Port)
    end.

main([Bin]) ->
    Port = open_port({spawn, Bin},
                     [binary, {packet, 4}]),
    loop(Port);
main(_) ->
    io:format("~s", ["usage: echo.erl path/to/port"]).

There is no need to create hundreds of new ports.
@superbobry
Copy link
Collaborator

Thanks, one port is indeed enough. Mind submitting a PR?

@negativ
Copy link
Contributor Author
negativ commented Mar 5, 2015

Yeah, ok. But i need some time to rework my local branch and then PR.

@superbobry
Copy link
Collaborator

Sure, no problem.

I've noticed you're working on Async integration: is it possible to support Async without duplicating the parsing?

@negativ
Copy link
Contributor Author
negativ commented Mar 5, 2015

At first i thought to totally rewrite current Alberto module and make new one Alberto_async, but now i decided to create a functor Alberto_async.Make that wraps original functions in async-scheduler-friendly way. So there is no code duplication of term parsing (as i can see, original parsing functions cannot stuck the scheduler), but reading and writing from std i/o is totally rewriten. If you have some suggestions for this functionality just tell me and i'll refactor this part in alberto-way.

@negativ negativ mentioned this issue Mar 5, 2015
Merged
@superbobry
Copy link
Collaborator

Alberto I/O interface is fairly minimal. Most of the parsing code is isolated into pure functions. There's an example of Lwt integration in examples/, why don't we do the same for Async?

@negativ
Copy link
Contributor Author
negativ commented Mar 6, 2015

I use alberto not only as an erlang-port library, primary it would be layer for close interaction with erlang message routers over tcp and udp, so there is some application-specific needs such as lazy evaluation of terms etc., wrapping original functions in deferred's is common api-style convertion in a project (graph-like db).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@superbobry @negativ
0