115 Members
Unofficial room for chatter about the Elixir language. This channel is publicly logged.10 Servers

Load older messages

Timestamp Message
30 Oct 2018
10:08:07@Phillipp:tchncs.dePhillipp the two problems are the relative suburl at owner.github.io/repo-name which breaks normal relative links. and the deployment into a gh-pages branch.
for the first problem, i can easily add a path_prefix option but then the local serve command wont work properly. that could be solved that the user creates an override config which is passed to the build command fryse build -o config-gh-pages.yml which is then merged with the default config and overrides the path_prefix.
the second problem can be solved that i dont delete the entire destination folder but just its content except for dotfiles. that way, the user can have a worktree or separate git repo in there.
12 Nov 2018
12:41:04@afv:matrix.orgAndré changed their display name from André Ventura to André.
15 Nov 2018
22:46:37@anders:andvision.se@anders:andvision.se left the room.
29 Nov 2018
07:24:14@Tristan_78:matrix.orgTristan_78 Hey, I have a GenServer (some database) which gets called by some process. The reply is delayed and should be returned later via GenServer.reply in a separate internal handle_cast. The thing is, that I must alter the state of the GenServer prior to replying the message, but I can't because the state gets updated when the cast function exits. I could spawn the reply() in an extra process, but I think it's not guearateed that the GenServer's state update happens before the replying.
Does anybody have a hint how to synchronize this racecondition?
07:28:47@wizardfrag:matrix.orgwizardfrag changed their profile picture.
07:28:54@wizardfrag:matrix.orgwizardfrag How are you casting? How are you altering the state?

GenServer.cast(server, {:alter_state, original_caller, some_reply, ...})

and then something like that

def handle_cast({:alter_state, original_caller, some_reply...}, state) do
  value = ...
  GenServer.reply(original_caller, some_reply)
  {:noreply, %State{state | important_value: value}}
07:35:14@wizardfrag:matrix.orgwizardfragIf you depend upon the state being modified before you reply, you should use call
07:35:24@Tristan_78:matrix.orgTristan_78 The racecondition is that the original_caller wants to access the server's important_value afterwards which has not been updated, because handle_cast has not finished yet (sometimes, it's a race)
07:38:03@Tristan_78:matrix.orgTristan_78I know, I initialially called with a delayed reply. Then there's some async stuff happening inside that internally casts the server with an update. Then the delayed reply should be executed.
07:39:27@Tristan_78:matrix.orgTristan_78 If I spawn the reply, there's no guarantee that it is delayed till the handle_call updated the state, right?
07:39:31@wizardfrag:matrix.orgwizardfragHmm. I guess you could have another handle_cast that replies, then cast in the original handle_cast, that way it’ll get picked up after the state update. But it really just feels wrong
07:40:02@Tristan_78:matrix.orgTristan_78yes, that would work
07:40:15@wizardfrag:matrix.orgwizardfragThe thing is. The reply should be fine where it is as long as you’re not directly accessing the state, which you shouldn’t be able to..
07:41:43@Tristan_78:matrix.orgTristan_78 really? the caller of the initial call directly calls on the state "getter" after it got a reply.
07:42:26@Tristan_78:matrix.orgTristan_78Hmm, if I think about it, you're right.
07:42:48@wizardfrag:matrix.orgwizardfragThe genserver can only handle 1 request at a time
07:42:50@Tristan_78:matrix.orgTristan_78The server is till in the cast and should block the call
07:43:30@Tristan_78:matrix.orgTristan_78hmm, maybe I'm on the wrong track and the error is somewhere else.
07:43:49@wizardfrag:matrix.orgwizardfrag Sounds like it yeah
07:43:56@Tristan_78:matrix.orgTristan_78thank you so far, I'll check my code again
07:44:01@wizardfrag:matrix.orgwizardfragI should really think before I reply early in the morning lol
07:45:38@wizardfrag:matrix.orgwizardfragJust. It’s obvious that the genserver can only handle 1 request at a time. I should’ve thought of that before replying
07:46:57@Tristan_78:matrix.orgTristan_78sometimes it's just too early
1 Dec 2018
20:42:54@nico:beerfactory.orgNico joined the room.
2 Dec 2018
07:20:21@asppsa:matrix.orgasp joined the room.
18:07:50@hokum:matrix.orghokum joined the room.
7 Dec 2018
04:13:34@nrdxw:matrix.orgnrdxw joined the room.

There are no newer messages yet.

Back to Room List