<    April 2017    >
Su Mo Tu We Th Fr Sa  
                   1  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 29  
30
00:03 wpcarro joined
00:07 <asonge> anyone got any blog posts or hints on how to create typespecs in a macro/by hand?
00:16 bloosi joined
00:17 bloosi joined
00:22 wpcarro joined
00:25 havenwood joined
00:25 havenwood joined
00:28 havenwood joined
00:41 weaksauce joined
00:45 MotherFlojo joined
00:49 icecreamcohen_ joined
00:57 jhack joined
01:03 notdaniel joined
01:07 jleon joined
01:08 refriedchicken joined
01:19 wpcarro joined
01:24 milad joined
01:24 refriedchicken joined
01:28 jmcintosh joined
01:31 wpcarro joined
01:39 cdg joined
01:39 tomterl joined
01:45 wpcarro joined
01:57 mika__ joined
02:00 ZippoWeb3 joined
02:10 wpcarro joined
02:12 milad joined
02:18 wpcarro joined
02:24 MotherFlojo joined
02:28 wpcarro joined
02:34 zv joined
02:40 refriedchicken joined
02:56 bloosi joined
03:06 milad joined
03:10 CapNemo joined
03:28 jleon joined
03:35 craigger joined
04:00 jerel joined
04:07 akeating joined
04:24 elgenie joined
04:41 MotherFlojo joined
04:41 __charly__ joined
04:56 milad joined
05:23 TheGillies left
05:24 scrmpy joined
05:26 <scrmpy> anyone started up their ecto repos from their application supervisor (e.g. calling storage_up, and handing migration)? was there any problems with taking this approach?
05:31 <asonge> scrmpy: if you have application workers that query the db, it might be problematic.
05:32 <asonge> or do you mean attempting to run the migrations during boot?
05:32 <scrmpy> during boot
05:32 <asonge> i prefer not to do it that way, personally.
05:33 <scrmpy> what approach do you take?
05:33 <asonge> the way a lot of people do it is via a distillery custom command. there's some examples in the documentation on how to set that up
05:34 <scrmpy> ok thanks, I'll check it out
05:34 <asonge> it's nicer, from an operations perspective at least, to have them separate. imagine if you wanted to run 2 servers (whether that's redundancy or capacity), you don't want them both trying to migrate on startup
05:35 <asonge> it might be completely appropriate in another context. like if one had an embedded database or something.
05:35 <scrmpy> but it's problematic if you're distributing an application?
05:36 <asonge> that would be one reason
05:36 <scrmpy> https://github.com/bitwalker/distillery/blob/master/docs/Running%20Migrations.md this is the approach for distillery you were recommending?
05:37 <asonge> using the release task in distillery (if you're using a release...and you really should be using a release) allows the database upgrade (or downgrade if things don't migrate right) to be decided by the ops person.
05:37 <asonge> yes
05:37 <asonge> are you using a release right now?
05:38 <scrmpy> not at the moment since it's just in development. but when it's pushed to production it will be using release builds
05:38 <asonge> there you go, then.
05:40 icanhazbroccoli joined
05:49 gvaughn joined
05:54 zvrk joined
05:57 wsieroci joined
06:06 jleon joined
06:25 <Nicd-> NightMonkey: welcome to the Elixir community!
06:35 tuacker joined
06:35 jeffweiss joined
06:38 jleon joined
06:44 milad joined
06:49 JuanMiguel joined
06:50 jleon joined
07:02 jleon joined
07:03 Cohedrin joined
07:04 jeffweiss joined
07:14 jleon joined
07:18 Cohedrin joined
07:25 gvaughn joined
07:28 cfenollosa joined
07:36 asabil joined
07:41 nd___ joined
07:41 vmoravec joined
07:46 cemilowski joined
07:55 notdaniel joined
08:00 mounibec joined
08:18 MotherFlojo joined
08:20 gokr joined
08:24 jleon joined
08:24 marr joined
08:26 nighty- joined
08:30 m_m joined
08:35 yourname_ joined
08:38 akeating joined
08:44 gmcabrita joined
08:52 asabil joined
08:52 icanhazbroccoli joined
08:53 <josevalim> okeuday_bak: sorry, I pressed submit by accident too early, so i will be editing my last comment very quickly, one sec
08:54 <okeuday_bak> josevalim: np, which state machine do you mean?
08:55 <okeuday_bak> or checkpointing code I mean
08:56 <josevalim> okeuday_bak: comment updated
08:56 <josevalim> okeuday_bak: not sure i follow
08:57 <josevalim> what do you mean?
09:00 <okeuday_bak> josevalim: I don't know what you are referring to when you say "examples and source code above" as it relates to checkpointing, because the discussion has mainly about the race condition name registration aspect of things it seems
09:00 <josevalim> okeuday_bak: oh, sorry
09:00 Ioyrie joined
09:00 <josevalim> the gen_stage source code and the examples i posted
09:03 Nockenfell joined
09:03 <okeuday_bak> josevalim: the gen_stage source code doesn't appear to have check-pointing details, but instead name registration details
09:03 <josevalim> okeuday_bak: no
09:03 <josevalim> it is all about check pointing details
09:04 <josevalim> because a single gen_server call needs to invoke two callbacks
09:04 <josevalim> for example, handle_cancel and handle_subscribe
09:04 <josevalim> and then if handle_subscribe fails, the state the user returned in handle_cancel is lost when we call terminate
09:06 <josevalim> okeuday_bak: all of the gen stage examples was not about name registration but about the need to checkpoint state
09:07 <okeuday_bak> josevalim: by fail, do you mean an exception causes the terminate instead of a stop return result, and due to that, the state can not be used
09:07 <josevalim> yes
09:07 <josevalim> let's supposed there is an error in handle_subscribe (the later callback)
09:07 <okeuday_bak> josevalim: you should be able to wrap that in a try/catch to return the stop with the state data, right?
09:08 MotherFlojo joined
09:08 <josevalim> we cannot pass the stacktrace on stop though
09:09 <josevalim> so it means logs and crash reports won't have the stacktrace
09:09 <josevalim> the stacktrace of the actual failure
09:09 <okeuday_bak> josevalim: you could pass it through the stop reason if you wanted to
09:09 <josevalim> okeuday_bak: i could, it is still not going to be included in the correct place in logs/reports
09:09 <josevalim> we considered this option before :)
09:11 <okeuday_bak> josevalim: that should be the most dependable way of handling it, if necessary, feeding it through as a {shutdown, StackTraceAndOtherStuff} tuple would make it not handled as a failure, though it sounds like a failure
09:11 <josevalim> right
09:11 <josevalim> but that's my point
09:11 <josevalim> i know there are workarounds
09:11 <josevalim> i don't want a workaround
09:11 <josevalim> i want a proper solution
09:12 <josevalim> i want to keep the proper logs, crash reports, etc
09:12 <josevalim> i want to avoid race conditions
09:12 <josevalim> the whole point of the discussion is to solve the problem *correctly*
09:12 <okeuday_bak> josevalim: well, the concept of check-pointing would mean you would be abstracting the processing, making a state machine similar to the function calls within, and managing global state by it, or something like it, but catching the exception is easier and better, since it keeps the state local to the process
09:13 <josevalim> it is not a state machine
09:13 <josevalim> checkpointing is not about having multiple states
09:13 <josevalim> it is about telling the loop what is the last version it should have
09:13 <josevalim> please look at the examples linked and tell me how that is a state machine
09:13 gvaughn joined
09:14 <josevalim> okeuday_bak: https://github.com/elixir-lang/gen_stage/blob/d28f8c04a3cf7696e53b5af213142362da0257c6/lib/gen_stage.ex#L2433-L2444
09:14 <josevalim> it is just calling the same callback in a loop
09:14 <josevalim> i don't have multiple "states" like subscribing, cancelling, etc
09:14 <okeuday_bak> josevalim: it would be just adding complexity with no real gain, which is why you need to catch the exception to handle state locally
09:14 <josevalim> okeuday_bak: sorry, there is an obvious real gain here
09:15 <josevalim> maybe you think it is rare, and i can agree with that
09:15 <josevalim> but saying there is no real again is basically dismissing all of the arguments i gave without providing an actual answer
09:15 <okeuday_bak> josevalim: no real gain to making it into a state machine, due to the complexity
09:16 <josevalim> oh, ok :D
09:16 <josevalim> yes, exactly
09:16 <josevalim> try/catch is the most ok-ish solution
09:16 <josevalim> it is still subpart
09:16 <josevalim> *subpar
09:16 <okeuday_bak> josevalim: at least with my view of it, I am saying that catching the exception keeps stuff simple, I am not familiar with this source code though really
09:16 <josevalim> okeuday_bak: i agree with you, it is the best solution for what we have right now
09:17 <josevalim> the pull request would be better though because we would keep the proper error/crash reports though
09:17 <okeuday_bak> josevalim: to do otherwise would want global state, and that would attempt to fight the use of an Erlang process for state handling
09:17 <josevalim> okeuday_bak: in fact, i have another PR in the making that makes sure gen_server includes the stacktraces in the proper places, which is what gen_statem does
09:18 <josevalim> okeuday_bak: i am not sure how global state is involved?
09:18 <josevalim> (we are not talking about naming, to be clear)
09:18 <okeuday_bak> josevalim: because you would somehow need to convey the state information in some way, despite the exception, if you don't use a try/catch
09:19 <josevalim> right, and that's what the PR allows us to do
09:19 <josevalim> without global state
09:19 <okeuday_bak> josevalim: so you wanted to do it by messaging, but that is problematic due to the termination
09:19 <josevalim> okeuday_bak: everything is in a single process
09:19 <josevalim> i shuold not using messaging
09:19 <okeuday_bak> josevalim: the other path would be using the process dictionary, which isn't that great
09:20 <josevalim> process dictionary doesn't solve it either
09:20 <okeuday_bak> josevalim: the process dictionary could pass state to be used in the terminate function, though it isn't a good approach really
09:20 <josevalim> imagine you are implementing a custom behaviour that invokes call1 and call2 on the gen_server call. how do you guarantee that any state returned by call1 is not lost if call2 crashes?
09:21 <josevalim> the best option is using try/catch and make sure that call2 does not crash
09:21 <josevalim> but it has issues: we cannot pass the stacktrace down to the genserver and it may change the error reason as well (you may convert an error into an exit)
09:21 <okeuday_bak> josevalim: as long as you are using the return values for handle_call, it isn't a problem
09:22 <josevalim> how it is not a problem?
09:22 <josevalim> if call2 fails, the state returned by call1 is lost
09:22 <okeuday_bak> josevalim: it can still crash by returning the stop tuple
09:22 <josevalim> yes, then we never call call2
09:22 <josevalim> or if call2 returns that, the state will be there
09:23 <okeuday_bak> josevalim: you can provide a reply even if stop is returned, and after that attempts to call will give an exception like noproc, or a timeout, depending on the situation
09:24 <josevalim> okeuday_bak: it is not about the reply
09:24 <josevalim> it is about calling terminate with the proper state
09:24 <josevalim> remember we are calling user callbacks
09:24 <okeuday_bak> josevalim: I don't see that as a problem, as long as you catch exceptions
09:24 <josevalim> and if i invoke a user callback and they return some state, they expect terminate to be called with that state
09:24 <josevalim> okeuday_bak: we are going circular here
09:24 dimitarvp joined
09:25 <josevalim> catching exceptions will remove or change the stacktrace from log/crash reports
09:25 <josevalim> and it will change the exit type from error to exit
09:27 <josevalim> okeuday_bak: it would be a workaround really
09:27 <okeuday_bak> josevalim: not intentionally, and I don't see these as major problems, since it is a change in data, while keeping operation dependable
09:28 <josevalim> how is not having a proper stacktrace in your crash reports not an issue?
09:28 <okeuday_bak> josevalim: I don't see the difference, since you can get the stacktrace and pass it back from the catch
09:28 <josevalim> i cannot pass the stacktrace
09:29 <josevalim> passing it on stop is not the same
09:29 <josevalim> for example, i have my node configured to publish reports to a system. one of the things that reports include and is pushed to the system is the stacktrace
09:29 MotherFlojo joined
09:29 <josevalim> now you are telling me that I need to add code that will check if the stacktrace field looks weird (because it will look weird), then check the state and see if it has potentially a stacktrace in the reason?
09:30 <josevalim> (and by look weird it means it will point to gen_stage internals)
09:30 <josevalim> how is breaking crash reports an acceptable answer?
09:31 <okeuday_bak> josevalim: yes, it is likely you would need to use some tuple to wrap the stack trace that can be used to see it is a stacktrace later
09:31 mounibec joined
09:31 <okeuday_bak> josevalim: I don't see that as breaking crash reports, but I also don't understand the context really, just looking at it as a basic problem
09:32 elgenie joined
09:32 <josevalim> okeuday_bak: if half of your callbacks have a stacktrace field properly field and the other half does not
09:33 <josevalim> then it is surely breaking crash reports
09:33 <josevalim> alternatively we could never include the stacktrace for consistency but that's an even worse idea
09:34 <josevalim> *stacktrace field properly filled
09:35 <okeuday_bak> josevalim: I am not attempting to suggest that you shouldn't provide the stacktrace, just that it be part of the stop reason, and handled later (interpreted)
09:35 <josevalim> for half of the callbacks?
09:35 <josevalim> so now everyone that is consuming sasl reports needs to add a special case because of gen_stage?
09:36 <okeuday_bak> josevalim: any callbacks that cause a stop could be handled that way, if a stacktrace doesn't cause a stop, then that would be a separate path it seems, but either way, the main goal was to allow the return of the updated state
09:36 <josevalim> the main goal is to provide sane semantics
09:36 <josevalim> it means proper state, proper reports, and proper exits
09:37 <josevalim> all of the solutions so far require me to put big disclaimers in the GenStage documentation that will either say "we do not guarantee that the state returned by handle_cancel will be available on terminate" OR "we do not guarantee stacktraces in crash reports, they should be extracted out of reason"
09:38 <josevalim> or require me to rewrite the whole thing using an abstraction that is not correct (gen_statem) or reimplement more than half of a gen_server from scratch
09:39 <okeuday_bak> josevalim: it could be possible to delay the exception until terminate is done, by catching it and passing it for terminate to throw
09:39 <okeuday_bak> josevalim: that may be weird, but then the stack trace isn't the way it should be
09:39 <josevalim> okeuday_bak: ok, let me check
09:43 <josevalim> okeuday_bak: i would have to use pdict :(
09:43 <okeuday_bak> josevalim: otherwise, perhaps you want to spawn an extra process to handle terminate for you, it could just monitor the parent
09:44 <josevalim> actually no, it doesn't need a pdict
09:46 <josevalim> okeuday_bak: ok, I am almost sure that works. i just need to check the terminate semantics
09:46 <okeuday_bak> josevalim: its stacktrace will be different though, it won't point to the user's throw location, so that is bad, isn't it?
09:46 <josevalim> okeuday_bak: no, the stacktrace will be correct I think
09:47 gokr joined
09:47 <josevalim> so we call the user terminate
09:47 <okeuday_bak> josevalim: terminate doesn't get called normally when exceptions occur unless you are using trap_exit, and using that to call stop or whatever
09:47 <josevalim> and if the user terminate succeeds, we call erlang:raise(Kind, Reason, Stack)
09:47 sevenseacat joined
09:48 <josevalim> okeuday_bak: terminate is called on stop though
09:48 <josevalim> and on user errors
09:48 PaReeOhNos joined
09:48 <josevalim> it is not called on shutdown or links unless trapping
09:48 <okeuday_bak> josevalim: ah, didn't realize you could supply the stacktrace, that is good
09:49 <josevalim> okeuday_bak: ok, so that solution works, i think we keep all properties if not all
09:50 scrmpy joined
09:50 <josevalim> okeuday_bak: I will confirm with fishcakez and update the thread accordingly
09:50 <josevalim> thanks!
09:50 <okeuday_bak> josevalim: np
09:52 <scrmpy> I'm having the same problem someone else outlined on the forums (but no fix/only temporary solutions was mentioned :/): https://elixirforum.com/t/issue-with-dbconnection-ownership-proxy-checkout-and-genserver-process/4334 https://github.com/civilcode/db_proxy_issue
09:54 lexmag joined
09:58 <josevalim> scrmpy: replied to that case
09:58 cschneid_ joined
09:59 <scrmpy> I see, in my case my GenServer is named
10:00 squallstter joined
10:03 <scrmpy> josevalim: stopping the named genserver seems to work anyway, is that the correct approach until v1.5?
10:08 jleon joined
10:10 <scrmpy> ok nevermind didn't actually work, must've just managed to call the genserver on all tests prior to stopping it or something
10:14 wsieroci joined
10:23 cschneid_ joined
10:30 wsieroci joined
10:31 levicole joined
10:40 jushur joined
10:44 stephen_m joined
10:47 <josevalim> okeuday_bak: ok, james replied, and he said that's the approach he took here: https://github.com/fishcakez/connection
10:48 <josevalim> okeuday_bak: here is the code: https://github.com/fishcakez/connection/blob/master/lib/connection.ex#L572-L590
10:48 <josevalim> his feedback is that it gets really complex and you don't get consistent errors between otp versions
10:48 <josevalim> plus you lose sys:trace and log messages for the events
10:49 <josevalim> so sys:trace/debug is only going to be invoke for part of the callbacks
10:57 cschneid_ joined
11:00 meh` joined
11:02 gvaughn joined
11:15 <termos> "invalid CSRF (Cross Site Request Forgery) token, make sure all requests include a valid '_csrf_token' param or 'x-csrf-token' header" I keep getting this when testing my phoenix api with postman. I tried adding the value from Plug.CSRFProtection.get_csrf_token in my header as well as in my parameters, seems to not make a difference
11:15 <termos> also tried setting "credentials": "same-origin"
11:16 <ericmj> termos: how are you setting the csrf token in postman?
11:16 <termos> as _csrf_token in my body form-data
11:17 <termos> or as X-CSRF-Token key in my headers
11:19 <ericmj> does postman forward the session?
11:26 teepark joined
11:27 <termos> I "fixed" it by removing the protect_from_forgery plug for now
11:31 meh` joined
11:31 mounibec joined
11:40 rodolfojcj joined
11:47 meh` joined
11:51 josevalim joined
11:54 notdaniel joined
12:08 PaReeOhNos joined
12:11 m00dy joined
12:15 __charly__ joined
12:29 asabil joined
12:40 m00dy_ joined
12:40 m_m joined
12:48 meh` joined
12:49 squallstter joined
12:50 gvaughn joined
12:52 imack joined
12:56 MotherFlojo joined
13:12 wsieroci joined
13:14 <josevalim> MononcQc: please don't sit on the sidelines beacuse it has been pretty much a downhill battle so far :'(
13:15 <MononcQc> I meant that for me the big argument is which one to implement
13:15 <MononcQc> not whether to implement any
13:15 <josevalim> MononcQc: i am shocked that solutions like "use a process group instead of registry" are being proposed as alternatives
13:15 <MononcQc> yeah
13:15 <MononcQc> also holy shit how can someone who complained at Erlang for not having maps being too unfriendly can honestly suggest init_ack and enter loop as valid solutions without an ounce of sarcasm
13:17 <josevalim> and the contradiction of asking for use cases of things I am arguing are hard to use
13:17 <josevalim> MononcQc: there is a question i wanted to ask you though
13:17 <MononcQc> yeah. I mean I get what you're getting at.
13:17 <josevalim> MononcQc: take eredis, it only provides sync init
13:17 <josevalim> but your app may not require a redis connection to work
13:18 <josevalim> having async init would be useful here, no? I believe it already provides backoffs and reconnects, just not on init
13:18 <MononcQc> I usually have a 'reconnect' event yeah. ANd so that one can be called from anywhere any time
13:18 <MononcQc> the trick though is that a connection library is now so fucking easy to provide as a gen_statem
13:19 <MononcQc> use the state_timeout as a backoff mechanism and use the {disconnected, RetryCount} as a state
13:19 <MononcQc> an enter event on each state lets you set the timeout
13:19 <MononcQc> drop the timeout once connected
13:19 chrismccord joined
13:19 <josevalim> MononcQc: yup yup!
13:19 m_m joined
13:19 <josevalim> I linked to this there: github.com/fishcakez/connection
13:19 <josevalim> it is a bunch of code to handle all of those scenarios
13:20 <josevalim> it will likely be 100-200loc with gen_statem
13:20 <josevalim> or it may even become completely obselete
13:21 <MononcQc> https://gist.github.com/ferd/c86f6b407cf220812f9d893a659da3b8 yeah this was a toy sample I had
13:22 yourname_ joined
13:23 <josevalim> beautiful
13:23 <MononcQc> I'm abusing the complex states a bit much but yeah
13:23 <MononcQc> like for that stuff it was shitty to use gen_fsm, shitty to use gen_servers, but gen_statem makes sense
13:23 <MononcQc> it's just very complex in its face
13:25 milad joined
13:27 m_m joined
13:49 Or1on joined
13:50 stephen_m joined
13:53 jeznet3 joined
13:54 harfangk joined
14:02 <fishcakez> There is gen_connection under my github using gen_statem but i gave up because plain gen_statem was much nicer
14:02 <MononcQc> hah, so no need to handle it anymore?
14:02 elgenie joined
14:04 <fishcakez> Yeah but gen_statem is stable for otp 20+ isn't it? Wasnt there breaking change in 19.1?
14:05 <MononcQc> yeah they changed the callback mode return value from a single item to a list for enter events
14:05 <MononcQc> but they're deprecating gen_fsm in 20 so statem should be stabl
14:07 <josevalim> MononcQc: we want to send another PR to gen_event which is to make it respect errors and exits
14:07 <MononcQc> hm?
14:07 <josevalim> today a gen_server always halts with exit(Reason)
14:07 <josevalim> even if a callback failed with an error
14:07 <josevalim> and it does not include the stacktrace
14:08 <josevalim> i want to change it to use erlang:raise(Kind, Reason, Stack) as in gen_statem
14:08 <MononcQc> that is tricky since it changes legacy behaviour a bunch of shit may rely on, hrm
14:08 <josevalim> MononcQc: right. we are not changing what goes into terminate
14:09 <josevalim> but possible what a linked process gets as an exit?
14:09 <MononcQc> yeah. It could mess up with linked peers rather than supervised ones
14:09 PaReeOhNos joined
14:09 <MononcQc> I'm not sure how many there would be though
14:09 <josevalim> MononcQc: but it may not be the case though, check this out
14:10 <josevalim> Eshell V9.0 (abort with ^G)
14:10 <josevalim> 1> spawn_link(fun() -> error(oops) end).
14:10 <josevalim> =ERROR REPORT==== 29-Apr-2017::16:09:41 ===
14:10 <josevalim> Error in process <0.62.0> with exit value:
14:10 <josevalim> {oops,[{shell,apply_fun,3,[{file,"shell.erl"},{line,905}]}]}
14:10 <josevalim> so if we do erlang:raise(error, oops, Stack), erlang also wrapps it into {Reason, Stack}
14:10 <josevalim> so i think linked processes get the same reason?
14:10 <josevalim> the only thing that changes is what gets logged
14:10 <josevalim> and it will be better detailed now
14:11 <josevalim> because we will be able to distingish errors from exits
14:11 <MononcQc> ah. Then it's not too bad
14:12 <fishcakez> It doesn't change exit reason
14:12 <fishcakez> Only crash report info, so stack trace is real
14:12 <fishcakez> And reason is real reason instead on exit reason, in case of error
14:13 <fishcakez> Oh don't know about what's passed to terminate 2
14:13 PaReeOhNos joined
14:14 <fishcakez> Error logger gen server logs got backwards incompatible change so likely tune for slightly better logs is now
14:14 <fishcakez> Bbl
14:14 <MononcQc> yeah if it's backwards compat but clearer that's all good
14:25 <fishcakez> Bbl
14:25 fghjfghj joined
14:38 squallstter joined
14:39 gvaughn joined
14:46 lexmag joined
14:46 jerel joined
14:49 nomicflux joined
14:57 PaReeOhNos joined
15:15 m1dnight_ joined
15:15 nomicflux joined
15:19 jeznet3 joined
15:31 tuacker joined
15:34 gvaughn joined
15:36 asabil joined
15:41 bitmod joined
15:41 PaReeOhNos joined
15:47 refriedchicken joined
15:49 gvaughn_ joined
15:52 cdg joined
15:54 milad joined
15:54 milad joined
15:59 nomicflux joined
16:02 nForce joined
16:03 stephen_m joined
16:11 segmond left
16:13 meandi_2 joined
16:17 gazler joined
16:19 MotherFlojo joined
16:23 Or1on joined
16:34 stephen_m joined
16:39 cdg joined
16:48 <bitmod> what does this error mean (hex dep error): https://paste.ubuntu.com/24480184/
16:52 <bitmod> got it
16:52 stephen_m joined
16:53 jeznet3 joined
16:54 JuanMiguel joined
16:59 OtherAllan joined
17:01 __charly__ joined
17:04 mika__ joined
17:16 <ivan> I want to return something like Ecto.Query.where([hostname: "..."]) from a large number of projects that don't depend on ecto. should I do this in a defmacro? can I check if a macro is defined on a module before calling it? (I'm guessing not?)
17:20 <ivan> (can I just unquote something with involving macros?)
17:22 <ivan> oh, you can unquote in a defmodule context but not in the REPL
17:30 ultra|lazer joined
17:31 MotherFlojo joined
17:32 adityau joined
17:32 <adityau> Hi
17:34 <adityau> Can somebody help me with ericmj's mongodb driver? I am trying to connect to single read replica of a replicaset. (not setting up replica set), any find query is giving me slaveOk=false.
17:35 <adityau> 23:02 *** NAMES [0__0] [4ZM] _2easy __charly__ __vy aaronjensen abort_ acetoxy Acidic_ adam12 adamkittelson adgtl adityau adulteratedjedi aedigix ahf akraut al-maisan alakra alisdair alxndr ambrosia_ amitchellbullard amontalenti andersh andman Ankhers Antiarc antipax arekinath arpunk artmann_ asabil ashp askatasuna asonge aunwin AustinMatherne avdi averell avidal balo barttenbrinke baweaver bbhoss bcardarella bcavil
17:35 <adityau> eer beatpanic Benjojo benoitc benwilson512 besc betawaffle bikefighter billstclair bin7me[m] bind1 bitmod bitwalker blahdodo blambi` Blkt bokayio bphogan braidn_ BramD_ Brend bryanjos brycek bttf btyler bungoman_ burbas byte512 c-rack_ Camnora capin CapNemo CARAM__ carterparks caw celyr cfk chazlever chops chris__ chrisarc1nd chrismcg ciawal Cidan ckrailo clarkkampfe Cloudflare cmeik cmk_zzz cmn comboy Confiks Corni
17:35 <adityau> shPasty coryschmitt craigger craigp cryptomata cschneid CStorm Cthalupa ctp cxadams_ danmcclain danneu danolj darach DavidAntaramian dbarrett dch DDR ddrmanxbxfr DeadTrickster DeadZen der_graf Dev0n dignifiedquire dikaiosune dimitarvp dj_goku dmilith dmiller dnorris dongo dormiens dp[m] drewolson DTZUZU dvim dylan ec\_ edmz EduardoBautista ekmartin elasticdog elmcrest elskwid__ ephe_meral ephemeron epochwolf eproxus
17:35 <adityau> erickgnavar ericmj ernie esainane esmiurium_ evax exadeci Exagone313 fabjan fantomik fap[m] fastjames felideon Fenne fernandomm fhoffmann FifthWall filozof Fire-Dragon-DoL fishcakez flupke FMJaggy_ fnux fold4 folz franco fredsir Frost fry fxrs gamache gausby gazler gen_ale_drinker geotti Ghouli gjaldon__ glasz gmcabrita gmcintire gokr gremly guacamole guan Guest44772 gvaughn_ gyre007 hakunin_ HalcyonicStorm halluxc
17:35 <adityau> at hansihe harrow HashNuke haste havenwood Havvy Hawkheart Haydos hemulen_ heroiceric___ hexkey[m] hflw Hibame hmans hosh hq1 href icanhazbroccoli iFire ikanobori ikopico imack Ioyrie irclogger_com Isilkor ivan j0ni jadams|cloud Jam666 jamesdphillips_ jamick jamiie_ca javax jaydoane jdcauley jdqx Jellybob jer jerel jeznet2 jhulten Jikai jimt jlouis jlpeters jmiven JoelMcCracken johanw johnhamelink johnsonch jorendor
17:35 <adityau> ff josevalim joshdholtz jpinnix jpterry jrdnull juancate JuanMiguel juicegun junsuiji1 jushur kansi kennyp kham kiliankoe killtheliterate kiltzman klaus_trainer knight- krigare[m] kvbx kzemek l1x lagbox lancetw larshesel lattenwald lauromoura lbotos__ LBRapid leafybas- lehoff levicole Lex[m] lexmag Licenser likestoplay linduxed Liothen Liquid_X liru listrophy liveforeverx ljarvis loglaunc- logos[m] lopex lstor lumin
17:35 <adityau> arys Lykve Lyubo1 M-nickgal M-Quora M04n0[m] M107262[m] m1dnight_ m3tti[m] M_D_K maaarcocr machuga manveru marcadde1 marceldegraaf marten martin_langhoff masteinhauser MasterNayru mbwe mcspud meandi_2 meredith metalrain mhutter Miah_ michael_mbp micmus mika__ mindflayer[m] minus mitchellvanw miwa mkwiek mlitwiniuk mloy mmcclure modran mojinations MononcQc MotherFlojo mozzarella mroth MrSaints mrus mrx1 msantos msch
17:35 <adityau> mudphone mwbrown myers Na nerdystreetrat NeverDie nextloop nForce ngr_ niccs Nicd- nicholasruunu nicholaswyoung nickjj nicooga_ NightMonkey nighty- nighty-- nii Ninja3047 nolan_d nonninz nope3000 noplamodo Notimik notriddle nox np null__ nyaray Nycatelos OAK0[m] Obi_obi_____ okeuday_bak olinkl OliverMT oohnoitz oopsydanger Or1on orliesaurus OtherAllan owickstrom pankracy pantech PaReeOhNos pbogut pchittum peanutlove
17:35 <adityau> _ penthief Peregrin- piotrj_ pmarreck pmbauer pmonson pota povilas pragmatism pranz proteusguy qmm Quintasan_ racycle Radar raek raidiant ramblinpeck rawtaz Ray` raymorgan rbino rc1140 reem rekyuu_ returnthis rfv riddle robinsjdotcom robotmayo_ rodolfojcj rom1504 rpip rs` rvirding ryanwinchester s` sa1_ sasajuric saurik_ schaary schaary_ Scorchin Scramblejams scrogson seanclayton sebhoss seequ_ seggy sekjun9878 sepo
17:35 <adityau> w seungha_________ sgarciapdx Sgeo Shados shamanime shmibs shymega sickill Sigma00 Sionide22 SirFunk siruf sixstone Siyo skace slashrsm smeevil smeevil_ smferris smoak smt snuffi solatis SoreGums sorentwo SouvikB spawnthink[m] Speed spl squallstter srodeme steffkes stnly strixy strmpnk stuartb sulphur28 svishnevskiy_ swav Synecy^ t-richards Talltree targaf tazjin teacup-on-rc teadrop_ teamj technikhil[m] teepark ter
17:35 <adityau> injokes termos the_voice_ TheMoonMaster Theophane theskumar thijser Thinh thread thurloat[m] TinkerTyper tmjoen todder tomku tomterl tonytony1an tozz tristan__ tuacker tvaalen uhoreg ultra|lazer unga universa1 unrahul utkarsh vadviktor vans163 vcoinminer vhf vifino vikram__________ vili_ vnz voxxit w1gz wakatara wangbus watersoul_ weaksauce webnanners whatyouhide whharris Whipstickgostop whodidthis wilo[m] wpcarro w
17:35 <adityau> sieroci wsmoak wycats x0nic Xikeon xsmalbil yggdr- yolev_ Yonk__ yourname_ yrashk yt____ z1mvader Zarathu zeeshanlakhani zidoh zkat Zor zpconn__________ ZPH zv zvrk
17:36 <smeevil_> o.O
17:36 <ivan> adityau: don't do that
17:36 <shmibs> nice
17:36 <MononcQc> what a jerk
17:36 <adityau> sorry about that.
17:36 <shmibs> well, since we're all here
17:36 <smeevil_> hahaha
17:36 <zv> never
17:36 <TheMoonMaster> since we're all here, don't use mongo
17:36 <smeevil_> hugs for everyone :D
17:36 <shmibs> i have a question!
17:36 <kansi> lolz
17:36 <robinsjdotcom> haha
17:37 <fnux> highlight party o/
17:37 <dikaiosune> lol so much for lurking
17:37 <ryanwinchester> i have a question! how hard would it be to write an elixir script that mutes people?
17:37 <ivan> yes, why would you ever use a database that doesn't do transactions
17:37 <smeevil_> well, got to admit, its highly effective :)
17:37 <ryanwinchester> j/k
17:37 <shmibs> what's the simplest way to serve up a static website (no scripts, no databases) without using some kinda giant framework like phoenix that's made för people who've used "web frameworks" before
17:37 <kansi> TheMoonMaster: and js
17:37 <TheMoonMaster> kansi: js is fine
17:37 <TheMoonMaster> mongo is not
17:37 <shmibs> *who've not used
17:37 <ivan> shmibs: apt-get install nginx?
17:38 <TheMoonMaster> shmibs: middleman
17:38 <adityau> stuck with it. :(
17:38 <TheMoonMaster> you pinged the entire channel, your answer is don't use it
17:38 <iFire> adityau: yeah don't use mongo
17:38 <fnux> shmibs: what kind of website ? You may want to something like jekyll or pelican ? (ruby, python)
17:38 <fnux> use*
17:39 <ryanwinchester> friends don't friends use mongo
17:39 <ryanwinchester> or random strangers on the internet
17:39 <iFire> shmibs: I really liking bookdown
17:39 <fnux> ^ static website generator
17:39 <robinsjdotcom> adityau: Ask in the slack channel, the community is a lot more active there. You could also ask on elixirforum.com :)
17:39 <iFire> https://bookdown.org/yihui/bookdown/
17:39 <shmibs> just something that might change a little from page-load to page-load, purely on the backend
17:39 <adityau> this was supposed to be a helping community. I pinged entire group by mistake. didn't mean to do that.
17:39 <ryanwinchester> plug
17:39 <kansi> riak should do then :P
17:39 <TheMoonMaster> how do you accidentally ping an entire channel? honestly asking
17:39 The-Kid joined
17:40 <ryanwinchester> i hate when i do that
17:40 <adityau> gg Shift v p enter (was doing on another buffer)
17:40 <TheMoonMaster> sounds not likely
17:41 <adityau> well that happened. :(
17:41 m_m joined
17:41 <shmibs> ryanwinchester, well ok. thanks
17:41 <shmibs> will take a look; saw the term before but had no idea what it was at the time
17:42 <bitmod> why can i not access images using static_path? e.g. <img src="<%= static_path(@conn, "/assets/images/image.png") %>"> doesn't work
17:42 <bitmod> getting "no route found"
17:43 <ryanwinchester> does that path exist
17:43 <shmibs> :P
17:43 <bitmod> ryanwinchester: yeah
17:43 <vhf> urgh
17:44 <ryanwinchester> in /priv/static
17:44 <bitmod> ryanwinchester: don't i put it in web/static?
17:44 <bitmod> and then brunch moves it?
17:44 <ryanwinchester> yeah but then magic happens and it's moved
17:44 milad joined
17:45 <* ryanwinchester> hand waves
17:45 <* ryanwinchester> maaagic
17:45 <ryanwinchester> :D
17:46 <bitmod> ryanwinchester: it is appearing in priv/static, but i'm not putting it there manually
17:46 <bitmod> not sure what i'm doing wrong
17:46 <ryanwinchester> priv/static/assets/images/image.png?
17:47 <bitmod> ryanwinchester: bah i'm an idiot, it should've been (@conn, "images/..."), not (@conn, "/assets/images/...")
17:47 <bitmod> all good
17:47 <ryanwinchester> 👍
17:48 <josevalim> MononcQc: can i say that the reason you don't use enter_loop is exactly because books needs to choose some topics and enter_loop is too non obvious? and you would very likely cover the case if we supported something as in the PR?
17:48 <MononcQc> No I don't think it was the reason
17:49 <MononcQc> I see enter loop and init_ack more as building blocks that ideally don't need to be shown
17:49 <MononcQc> they should be hw you build behaviours, not a way to work around their problems. If so, that,s a leaky abstraction
17:49 bpmcd joined
17:49 <lagbox> what even makes someone think that is okay to list everyone in a channel like that?
17:49 <MononcQc> I'd have shown them in the case where I wanted to show how to make your own behaviour
17:49 <lagbox> needy much
17:50 Cohedrin joined
17:51 <MononcQc> so too non obvious might be right. Out of scope is another one
17:51 <lagbox> TheMoonMaster, it was done on purpose
17:52 <TheMoonMaster> lagbox: yeah, just trying to give benefit of the doubt and all that
17:52 <tristan__> why improve gen_server when you can write your own behaviour! ;)
17:53 <josevalim> MononcQc: ok, thank you
17:53 <bitmod> is there a way of preventing a hex package's styling from corrupting my apps? e.g. i've removed bootstrap from my app, but ExAdmin uses it, is it possible to limit ExAdmin's styling to the /admin route?
17:58 <josevalim> MononcQc: i am quoting you unless you would rather not have me do that
17:58 <josevalim> this: "they should be hw you build behaviours, not a way to work around their problems. If so, that,s a leaky abstraction"
18:02 <MononcQc> without the typos, but I can write later
18:03 squallstter joined
18:08 <josevalim> MononcQc: i kept the typos and shamed you for them
18:08 <josevalim> :P
18:08 <MononcQc> dangit
18:08 <MononcQc> aight!
18:11 <josevalim> just kidding, i fixed them, if i misquoted let me know, i am out!
18:11 <josevalim> MononcQc: and thanks again for all the discussion
18:14 <OliverMT> adityau: :<
18:17 <josevalim> adityau: i thought it was a bot :P how did you do that? :D
18:18 <adityau> was doing some copy pasting on another buffer. :(
18:20 milad joined
18:20 milad joined
18:22 <MononcQc> josevalim, no problem. I was hoping to extend gen_statem to other behaviours back a year ago in the old discussions
18:23 <josevalim> oh, I see
18:23 <josevalim> we were planning to roll our own GenServer in Elixir
18:23 <josevalim> but with the changes in optional callbacks and logging
18:23 <josevalim> we decided to see if those changes would be accepted upstream
18:23 <josevalim> hence the changes about logging
18:23 <josevalim> i also want to submit a PR to make print_event configurable but that should hopefully have little oposition
18:24 <MononcQc> print_event?
18:24 wsieroci_ joined
18:25 <josevalim> https://github.com/erlang/otp/blob/master/lib/stdlib/src/gen_server.erl#L393-L394
18:25 <josevalim> and the other 6 times it is used in OTP source
18:25 <MononcQc> ah ok
18:25 <josevalim> *other 5 times
18:25 <josevalim> *in gen_server source
18:25 <MononcQc> yeah could be extended in the configu tuples I guess
18:26 <josevalim> yes, it can be a start_link option
18:27 <mloy> adityau: evil-mode?
18:27 wsieroci joined
18:28 <adityau> yes
18:29 <mloy> nice
18:41 cdg joined
18:43 <OliverMT> has anyone tested if bin/foo stop in a release will execute terminate/1 on a genserver?
18:43 <OliverMT> to save me setting up a release and testing, I'm just doing some planning on a laptop without stuff installed :D
18:48 imack joined
18:48 imack joined
18:49 imack joined
18:49 hotpancakes joined
18:50 imack joined
18:51 imack joined
18:53 jimmyrcom joined
18:53 elgenie joined
18:59 cemilowski joined
19:01 nd___ joined
19:01 adityau joined
19:02 vmoravec joined
19:02 haste joined
19:03 elgenie joined
19:04 jerel joined
19:08 hotpancakes joined
19:08 hotpancakes joined
19:09 <ericmj> bitmod: what hex package styling? hex packages don't have any specific styling, they are just tarballs of applications
19:18 lexmag joined
19:22 chrismccord joined
19:29 hotpancakes joined
19:32 josevalim_ joined
19:35 <josevalim_> OliverMT: i think it calls :init.stop
19:35 <josevalim_> which asks the supervision trees to shutdown
19:35 <josevalim_> but terminate won't be called unless the process is trapping exits
19:36 <josevalim_> because supervisors shutdown processes by sending exit signals
19:53 <OliverMT> josevalim: so whats the solution then? trap exit in init or something else?
19:53 skrib joined
19:53 <josevalim> yes
19:53 <OliverMT> is that bad for some reason?
19:53 <OliverMT> as in performance or whatever
19:54 <OliverMT> my usecase is a genserver that I spin up hackney async events to
19:54 <OliverMT> as in I start eventstream listeners to a http endpoint and then the genserver keeps track of the ref and where each event should go
19:55 <OliverMT> on a rolling upgrade I need to let the consuming end know that I am shutting down the hackney references
19:55 <OliverMT> I figured terminate/1 would work for that, simply loop through active refs and notify that hey I'm going down
19:57 elgenie joined
20:00 <tristan__> that is what you want to do
20:00 MotherFlojo joined
20:01 rkazak joined
20:12 mytrile joined
20:13 Gasher joined
20:13 <benwilson512> ericmj: how is https://github.com/hexpm/specifications/blob/master/apiary.apib produced?
20:13 <benwilson512> automatically? by hand?
20:15 josevalim joined
20:15 <ericmj> benwilson512: it is created by hand. It follows API blueprint.
20:16 <ivan> I use MapSets a lot and wish they had syntax
20:17 cschneid_ joined
20:19 apotry joined
20:20 justelex joined
20:22 jkreeftmeijer joined
20:23 <benwilson512> ericmj: gotcha
20:25 jkreeftmeijer joined
20:26 jkreeftmeijer joined
20:26 jkreeftmeijer joined
20:27 jkreeftmeijer joined
20:28 jkreeftmeijer joined
20:29 jkreeftmeijer joined
20:29 cschneid_ joined
20:30 jkreeftmeijer joined
20:30 jkreeftmeijer joined
20:33 Cohedrin joined
20:45 <OliverMT> tristan__: allright thx
20:57 stephen_m joined
20:58 cdg joined
21:27 Gasher joined
21:31 jkreeftmeijer joined
21:41 asabil joined
21:46 cschneid_ joined
21:48 meredith joined
21:58 apotry joined
22:09 jkreeftmeijer joined
22:14 jkreeftmeijer joined
22:25 jkreeftmeijer joined
22:33 nomicflux joined
22:35 jkreeftmeijer joined
22:46 jkreeftmeijer joined
22:52 refriedchicken joined
22:56 jkreeftmeijer joined
22:59 fabjan joined
23:07 jkreeftmeijer joined
23:16 mozzarella joined
23:18 jkreeftmeijer joined
23:28 jkreeftmeijer joined
23:36 iamvery joined
23:37 wpcarro joined
23:38 jkreeftmeijer joined
23:39 iamvery joined
23:44 cschneid_ joined
23:49 jkreeftmeijer joined
23:52 gmcabrita joined
23:56 milad joined