Thanks for looking at the question and It would be helpful and appreciated if you guys can solve my question. Now here's my question..
I created a gen server in erlang for banking purposes and I just made it for deposit and withdraw. It's working perfectly fine and what I need now is to add conditions to the withdraw. Such as, if the amount to be withdrawn is going to make the balance below 100, then the withdraw has to be aborted and a display message such as "Minimum balance is 100" has to be shown. I am self learning and this is for my curiosity in how the gen server works with conditions. here's the part where the withdraw is happening.
deallocate(Available,M) ->
New_state1 = Available - M,
io:format("Amount withdrawn : ~p~n",[M]),
io:format("Total Balance : ~p~n",[New_state1]),
Reply = withdrawn,
{New_state1,Reply}.
As you can see from the above lines, this is where the withdrawn is done. Now I am stuck here with where and how I can add conditions.
Any help is much appreciated and Thanks in advance even for trying. Good day!!
I'm gonna assume that you're calling this deallocate/2 function from within handle_call/3 and that the reply is given back to the caller, something like…
handle_call({deallocate, M}, _From, State) ->
{NewState, Reply} = deallocate(State, M),
{reply, Reply, NewState};
…
If that's the case, you just need to return an error message to the client instead of withdrawn…
deallocate(Available,M) ->
case Available - M of
NewState when NewState < 100 ->
{Available, {error, balance_under_minimum}};
NewState ->
io:format("Amount withdrawn : ~p~n",[M]),
io:format("Total Balance : ~p~n",[NewState]),
{NewState, withdrawn}
end.
Of course, on the client side you will have to understand the error message, so instead of…
deallocate(M) -> gen_server:call(the_bank, {deallocate, M}).
…you would do…
deallocate(M) ->
case gen_server:call(the_bank, {deallocate, M}) of
withdrawn -> withdrawn;
{error, balance_under_minimum} ->
io:format("Minimum balance is 100\n"),
not_withdrawn
end.
Related
As it's stated in the upgrade guide, Effects is being replaced by this new Applicative Functor-like thing Cmd. I don't see any trace of a clue as to where Effects.tick might be hiding, or how it could be reimplemented.
From the looks of things, Process.sleep might be the right answer, something like
Task.perform errorHandler (\x -> x) <| Process.sleep
<| 500 * Time.millisecond
would allow the process to wait 500 milliseconds before issuing the next message / action. I'm just not sure if this is what will replace Effects.tick in the long run though.
Effect.tick functionality is replaced by AnimationFrame.
You basically subscribe to a set of msg of either times or diffs. And react accordingly.
import Html exposing (..)
import Html.App as App
import AnimationFrame
import Time exposing (Time, second)
main =
App.program
{ init = Model 0 0 ! []
, update = \msg model -> update msg model ! []
, view = view
, subscriptions = \_ -> AnimationFrame.diffs identity}
type alias Model =
{ timeSinceLastIncrement : Time
, counter : Int }
incrementTime = 1*second
update diff {timeSinceLastIncrement, counter} =
if timeSinceLastIncrement > incrementTime then
Model 0 (counter+1)
else
Model (timeSinceLastIncrement+diff) counter
view {counter} =
div [] [text (toString counter)]
I've chosen to send the Time diffs directly as messages and to unpack the structure of the model in both update and view for easier access to components. In a more complex app you will probably have something like a Tick Time message.
I have a problem to close a program in Erlang. I use wxWidgets.
-module(g).
-compile(export_all).
-define(height, 500).
-define(width, 500).
-include_lib("wx/include/wx.hrl").
-define(EXIT,?wxID_EXIT).
init() ->
start().
start() ->
Wx = wx:new(),
Frame = wxFrame:new(Wx, -1, "Line", [{size, {?height, ?width}}]),
setup(Frame),
wxFrame:show(Frame),
loop(Frame).
setup(Frame) ->
menuBar(Frame),
wxFrame:connect(Frame, close_window).
menuBar(Frame) ->
MenuBar = wxMenuBar:new(),
File = wxMenu:new(),
wxMenuBar:append(MenuBar,File,"&Fichier"),
wxFrame:setMenuBar(Frame,MenuBar),
Quit = wxMenuItem:new ([{id,400},{text, "&Quit"}]),
wxMenu:append (File, Quit).
loop(Frame) ->
receive
#wx{event=#wxCommand{type=close_window}} ->
io:format("quit icon"),
wxWindow:close(Frame,[]);
#wx{id=?EXIT, event=#wxCommand{type=command_menu_selected}} ->
io:format("quit file menu"),
wxWindow:close(Frame,[])
end.
But the program doesn't close; neither the quit icon or Quit from the menu do anything.
You're almost there, but there's a few mistakes.
First, there's never any event being generated for your quit selection on your mention, you need to use connect again, like this:
Quit = wxMenuItem:new ([{id,400},{text, "&Quit"}]),
wxFrame:connect(Frame, command_menu_selected),
Now you have an event for each of the quit methods, but neither of them is working still.
The event for your quit icon isn't matching because you have the wrong event type in your pattern match, and the event for the menu quit selection isn't matching because you're looking for an ID of ?EXIT, which is defined as ?wxID_EDIT, which is defined as.. well clearly not 400, the ID you used when you created your quit menu item. So your receive clause needs to be changed to something like this:
receive
#wx{event=#wxClose{type=close_window}} ->
io:format("quit icon"),
wxFrame:destroy(Frame);
#wx{id=400, event=#wxCommand{type=command_menu_selected}} ->
io:format("quit file menu"),
wxFrame:destroy(Frame)
end.
In addition to Michael's answer regarding using connect/3 to listen for menu commands, nearly any frame will require a few standard event connections to behave the way you expect them to on closing in addition to whatever specific things you have going on. Note that this is connecting to the close_window event and using the option {skip, true}. This is so the signal doesn't stop propagating before it hits the part of Wx that will handle it the way you expect (one click to close) instead of requiring two clicks to close the frame on some platforms.
The basic skeleton often looks like this:
init(Args) ->
Wx = wx:new(),
Frame = wxFrame:new(Wx, ?wxID_ANY, ""),
% Generate whatever state the process represents
State = some_state_initializer(Args),
% Go through the steps to create your widget layout, etc.
WidgetReferences = make_ui(Frame),
% The standardish connects nearly any frame will need.
ok = wxFrame:connect(Frame, close_window, [{skip, true}]),
ok = wxFrame:connect(Frame, command_button_clicked),
ok = wxFrame:connect(Frame, command_menu_selected),
% Add more connects here depending on what you need.
% Adjust the frame size and location, if necessary
Pos = initial_position(Args),
Size = initial_size(Args),
ok = wxFrame:move(Frame, Pos),
ok = wxFrame:setSize(Frame, Size),
wxFrame:show(Frame),
% Optional step to add this frame to a UI state manager if you're
% writing a multi-window application.
ok = gui_manager:add_live(self()),
% Required return for wx_object behavior
{Frame, State}.
Digressing a bit from the original, but strongly related...
Many wxWidgets application have something very similar to this, customized as necessary not by writing all that out again, but by defining your own callback module and passing it in as an argument:
init({Mod, Args}) ->
% ...
PartialState = blank_state([{mod, Mod}, {frame, Frame}, {wx, Wx}]),
State = Mod:finalize(PartialState, Args),
Where blank_state/1 accepts a proplist and returns whatever the actual data structure will be later (usually a record at this level, that looks something like #s{mod, frame, wx, widgets, data}), and Mod:finalize/2 takes the incomplete state and the initial args and returns a completed GUI frame plus whatever program state it is supposed to manage -- in particular the widgets data structure that carries references to any GUI elements you will need to listen for, match on, or manipulate later.
Later on you have some very basic generic handlers all frames might need to deal with, and pass any other messages through to the specific Mod:
handle_call(Message, From, State = #s{mod = Mod}) ->
Mod:handle_call(Message, From, State).
handle_cast(blit, State) ->
{ok, NewState} = do_blit(State),
{noreply, NewState};
handle_cast(show, State) ->
ok = do_show(State),
{noreply, State};
handle_cast(Message, State = #s{mod = Mod}) ->
Mod:handle_cast(Message, State).
In this case do_blit/1 winds up calling Mod:blit/1 in the callback module which rebuilds and refreshes the GUI, rebuilding it from zero by calling a function that does that within wx:batch/1 to make it appear instant to the user:
blit(State) ->
wx:batch(fun() -> freshen_ui(State) end).
If you have a lot of elements to change in the GUI at once, blitting is far smoother and faster from the user's perspective than incrementally shuffling things around or hiding/showing elements as you go -- and is much more certain to feel the same across platforms and various computer speeds and userland loads (some Wx backends give a lot of flicker or intermediate display weirdness otherwise).
The do_show/1 function usually looks something like
do_show(#s{frame = Frame}) ->
ok = wxFrame:raise(Frame),
wxFrame:requestUserAttention(Frame).
(I have been meaning to write a basic "here is one way to structure a multi-window wxErlang application" tutorial/example but just haven't gotten around to it, so a lot of details are missing here but you'll stumble on them on your own after writing a couple of programs.)
When test open source project 'gproc' function,
I found list_to_pid is ok for local pid, and not ok for remote pid. My erlang runtime is R15B.
(dist_test_n2#yus-iMac.local)29> D = list_to_pid("<0.239.0>").
<0.239.0>
(dist_test_n2#yus-iMac.local)30> D == self(). %% equal here
true
(dist_test_n2#yus-iMac.local)31> f(E).
ok
(dist_test_n2#yus-iMac.local)32> E = gproc:where(Name).
<8969.239.0>
(dist_test_n2#yus-iMac.local)33> F = list_to_pid("<8969.239.0>").
<8969.239.0>
(dist_test_n2#yus-iMac.local)34> F == E. %% not equal here
false
From user guide about this function, there is no such restriction. Is it bug?
as you can confirm here it's not possible to use list_to_pid/1 with external pids.
If you check on google I think you can also find the original thread started by Ulf Wiger.
Hope this helps!
We have a fairly large USSD application that uses Erlang's gen_fsm module to manage the menu options.
The current version has a single menus_fsm.erl file that contains 5000+ lines gen_fsm related code. Our next version gives us an opportunity to split menus_fsm.erl into separate files to make it more maintainable in the future.
In the old version, to display the help menu we do the following (help_menu/1 gets called from code not shown that displays the main menu):
-module(menus_fsm).
% Snipped some irrelvant code
help_menu(StateData) ->
% Display the first menu
send_menu(StateData, "Please Select:\n1. Option 1\n2. Option 2"),
{next_state, waitHelpMenuChoice, StateData, ?MENU_TOUT};
waitHelpMenuChoice(Params, StateData) ->
io:format("Got Help menu response: ~p", [Params]),
doTerminate(ok,"Help Menu", StateData).
I've left out a lot of code that shows the entry point into the FSM and so on.
In the new version, we'd want to move help_menu/1 and waitHelpMenuChoice/2 to a new module help_menu, which gets called from menus_fsm, like so:
-module( help_menu ).
% Snipped some irrelevant code
help_menu(StateData) ->
menus_fsm:send_menu(StateData, "Please Select:\n1. Option 1\n2. Option 2"),
{next_state, waitHelpMenuChoice, StateData, ?MENU_TOUT};
waitHelpMenuChoice(Params, StateData) ->
io:format("Got Help menu response: ~p", [Params]),
menus_fsm:doTerminate(ok,"Help Menu", StateData).
The problem is with the line {next_state, waitHelpMenuChoice, StateData, ?MENU_TOUT};: gen_fsm expects the waitHelpMenuChoice to be in the module menus_fsm which takes me back to where we started.
I've tried to replace the problematic line with
{next_state, fun help_menu:waitHelpMenuChoice/2, StateData, ?MENU_TOUT};
but that just leas to an error like the following:
{badarg,[{erlang,apply,[conv_fsm,#Fun<help_menu.waitHelpMenuChoice.2>,[]]}
Does anyone have any suggestions of how to get around this?
Maybe you could use http://www.erlang.org/doc/man/gen_fsm.html#enter_loop-6 to do that? Not sure if it would work to call it inside of another fsm, but it might be worth a try.
I managed to find a solution to my own question. If this seems obvious, it could be because I'm a bit new to Erlang.
I added a new function wait_for_menu_response/2 to module menus_fsm that handles state transitions on behalf of the other modules.
-module(menus_fsm),
-export([wait_for_menu_response/2]).
% ...snip...
wait_for_menu_response(Params, {Function, StateData}) ->
Function(Params, StateData).
Then the help_menu module was changed as follows:
-module( help_menu ).
% ...snip...
help_menu(StateData) ->
menus_fsm:send_menu(StateData, "Please Select:\n1. Option 1\n2. Option 2"),
{next_state, wait_for_menu_response, {fun waitHelpMenuChoice/2, StateData}, ?MENU_TOUT}.
waitHelpMenuChoice(Params, StateData) ->
io:format("Got Help menu response: ~p", [Params]),
menus_fsm:doTerminate(ok,"Help Menu", StateData).
so gen_fsm stays within the menus_fsm module when it invokes wait_for_menu_response, but wait_for_menu_response is now free to invoke help_menu:waitHelpMenuChoice/2. help_menu:waitHelpMenuChoice/2 did not need to be modified in any way.
Actually, in my final version, the menus_fsm:send_menu function was modified to accept the fun waitHelpMenuChoice/2 as its third parameter, so that the help_menu function simply becomes:
help_menu(StateData) ->
menus_fsm:send_menu(StateData, "Please Select:\n1. Option 1\n2. Option 2",
fun waitHelpMenuChoice/2).
but I think my explanation above illustrates the idea better.
I'm writing a program where the user must enter a 'yes' or 'no' value. The following is the code that will be executed when the message {createPatient,PatientName} is received.
{createPatient, PatientName} ->
Pid = spawn(patient,newPatient,[PatientName]),
register(PatientName,Pid),
io:format("*--- New Patient with name - ~w~n", [PatientName]),
Result = io:read("Yes/No> "),
{_,Input} = Result,
if(Input==yes) ->
io:format("OK")
end,
loop(PatientRecords, DoctorPatientLinks, DoctorsOnline, CurrentPatientRequests, WaitingOfflineDoctorRequests);
When executed ,the line "New Patient with name..." is displayed however the line Yes/No is not displayed and the program sort of crashes because if another message is sent, then the execution of that message will not occur. Is there a different way to solve this problem please?
There are a number of points I would like to make here:
The io:read/1 function reads a term, not just a line, so you have to terminate input with a '.' (like in the shell).
io:read/1 returns {ok,Term} or {error,Reason} or eof so you code should check for these values, for example with a case.
As #AlexeyRomanov mentioned, io:get_line/1 might be a better choice for input.
The if expression must handle all cases even the ones in which you don't want to do anything, otherwise you will get an error. This can be combined with the case testing the read value.
You spawn the function patient:newPatient/1 before you ask if the name is a new patient, this seems a little strange. What does the newpatient function do? Is it in anyway also doing io to the user which might be interfering with functions here?
The main problem seems to be work out what is being done where, and when.
This is very artificial problem. In erlang any communication is usually inter-process and exchanging strings wouldn't make any sense - you ask question in context of process A and you would like to post answer in context of process B (shell probably).
Anyways, consider asking question and waiting in receive block in order to get an answer.
When question pops out in shell, call a function which will send the answer to 'asking' process with your answer.
So:
io:format("*--- New Patient with name - ~w~n", [PatientName]),
receive
{answer, yes} -> do_something();
{answer, no} -> do_something()
end
The 'answering' function would look like that:
answer(PatientName, Answer) ->
PatientName ! {answer, Answer}.
And shell action:
$> *--- New Patient with name - User1036032
$> somemodule:answer('User1036032', yes).
It is possible to create some dialog with shell (even unix shell), but to be honest it is used so rare that I do not remember those I/O tricks with read and write. http://trapexit.com/ used to have cookbook with this stuff.
Use io:get_line("Yes/No> ") instead.