|
The San Francisco Erlang Factory is this week I'm not sure if anyone else here is going. I'll be the bewildered Canadian.
|
# ? Mar 3, 2014 00:21 |
|
|
# ? May 11, 2024 09:13 |
|
more like dICK posted:The San Francisco Erlang Factory is this week I'm not sure if anyone else here is going. I'll be the bewildered Canadian. A bunch of my coworkers are going, and I believe MononcQc will also be a bewildered Canadian in attendance. (I'm going to Ruby on Ales instead )
|
# ? Mar 3, 2014 00:27 |
|
Yeah I'm definitely going to be there. I'll be presenting on Planning for Overload and I have a lightning talk lined up too on interval tree clocks.
|
# ? Mar 3, 2014 02:37 |
|
MononcQc posted:Yeah I'm definitely going to be there. I'll be presenting on Planning for Overload and I have a lightning talk lined up too on interval tree clocks. Well yeah, you going was a given. The lightning talks are for Thursday night, right?
|
# ? Mar 3, 2014 03:09 |
|
more like dICK posted:Well yeah, you going was a given. The lightning talks are for Thursday night, right? Yep. Usually anyone can join in and present a thing if there's enough time slots left. Ask early during the day and you should have a place I guess.
|
# ? Mar 3, 2014 04:25 |
|
Lol at this guy totally missing you.
|
# ? Mar 6, 2014 18:24 |
|
more like dICK posted:Lol at this guy totally missing you. Francesco's pretty cool. Old boss of mine and totally nice guy. He gave me a job (he created the position) after I asked for it on Twitter a few years ago. He can forget my name any day
|
# ? Mar 6, 2014 18:33 |
|
I didn't even realize that was Francesco. Everyone looks different from their twitter pictures. I gave your talk a smiley face, but I've given every talk a smiley face because public voting stresses me out.
|
# ? Mar 7, 2014 01:05 |
|
I won a book. My week is complete.
|
# ? Mar 8, 2014 03:16 |
|
more like dICK posted:I won a book. My week is complete. Who are you? http://instagram.com/p/lQ8C7oxiEm/
|
# ? Mar 8, 2014 07:54 |
|
The Basho people are really really loud when you get them all together.
|
# ? Mar 8, 2014 17:22 |
|
more like dICK posted:The Basho people are really really loud when you get them all together. Did they have a sponsored party again?
|
# ? Mar 9, 2014 05:09 |
|
Erlang 17.0 Has just been released: http://www.erlang.org/news/73
There's more. For maps, I've just added a chapter to LYSE to cover them: http://learnyousomeerlang.com/maps
|
# ? Apr 9, 2014 18:01 |
|
MononcQc posted:Erlang 17.0 Has just been released: http://www.erlang.org/news/73 Guess I won't be needing this anymore. code:
|
# ? Apr 9, 2014 20:54 |
|
Anyone (other than Monononononoqc) attending the Vancouver factory thing?
|
# ? Apr 28, 2014 21:44 |
|
Is kerl the best way to maintain an up-to-date Erlang VM on my machine? My distro is stuck on R15B1.
|
# ? Apr 30, 2014 21:42 |
|
Otto Skorzeny posted:Is kerl the best way to maintain an up-to-date Erlang VM on my machine? My distro is stuck on R15B1. Yes. I've tried Homebrew on the Mac and various Linux packages and run into too many headaches with missing crypto libs or not finding the exact version I want. Kerl has always worked perfectly the first time and lets me swap between multiple versions at will. (YMMV) If you want to keep trying it pre-packaged, though, try Erlang Solutions' packages: https://www.erlang-solutions.com/downloads/download-erlang-otp
|
# ? May 1, 2014 05:29 |
|
Hello again, Erlang thread. This may be a bit of a fool's errand, but I'm trying to get relx (and subsequently exrm) running on Windows. Relx provides instructions for building on Windows, but they're not working for me. When I run the bootstrap script, I get the following output. code:
code:
|
# ? Jun 21, 2014 01:53 |
|
Can you try a pre-compiled version and see if it's any better? See https://github.com/erlware/relx/releases and pick one. By default it will crash if it can't find a relx.config file in the directory you're trying it, so check for relx --version to see if it helps, or alternatively try to run it as escript.exe relx --version and see if it's different.
|
# ? Jun 21, 2014 03:32 |
|
I didn't even realize that github distributed binaries. Shows how out of touch I am. Anyways I totally ditched elixir for this project, so I don't need exrm anymore.
|
# ? Jun 26, 2014 02:07 |
|
howistart.org got released recently and I have a tutorial on there about how I usually get going with projects to write libraries and releases
|
# ? Jun 29, 2014 00:33 |
|
MononcQc posted:howistart.org got released recently and I have a tutorial on there about how I usually get going with projects to write libraries and releases That's the best example project I've ever seen.
|
# ? Jun 29, 2014 01:15 |
|
MononcQc, looks like the Japanese translation of your book is trending like crazy today under the hashtag #すごいE本.
|
# ? Jul 4, 2014 04:53 |
|
Mniot posted:Yes. I've tried Homebrew on the Mac and various Linux packages and run into too many headaches with missing crypto libs or not finding the exact version I want. Kerl has always worked perfectly the first time and lets me swap between multiple versions at will. (YMMV) This is months after your question was initially asked, but: The first thing i tried with regards to multiple release management, but coming from a python virtualenv (e: likely misunderstood and not well understood, honestly) type environment situation i found the talent deficit's erlenv to be really handy when trying to manage various erl versions while learning Erlang whenever I've had something complain about erlang version. Granted, I haven't ever put any erlang thing I've made into production and I don't know how that would work, and I'm also unfamiliar with the original ruby/rbenv environment; it's still worked 'good enough' for me with my stage in learning Erlang. I don't think I've tried kerl yet however, I will have to check it out. Also, I really like erlang/learning about erlang but I really can't explain 'why' I guess right now; it just seems to 'click' with me more so than other languages and remains a fun language to think in for me. Thanks, this thread and MononcQc (and LYSE) for helping me find it bobthenameless fucked around with this message at 13:28 on Jul 4, 2014 |
# ? Jul 4, 2014 12:11 |
|
Azazel posted:MononcQc, looks like the Japanese translation of your book is trending like crazy today under the hashtag #すごいE本. Ah nice, that's pretty cool. I'm eager to get a copy. I remember we've sold rights for a Chinese version and a Russian one also. The Chinese one I haven't heard from, but the Russian one is in its final phases right now too. bobthenameless posted:Also, I really like erlang/learning about erlang but I really can't explain 'why' I guess right now; it just seems to 'click' with me more so than other languages and remains a fun language to think in for me. Thanks, this thread and MononcQc (and LYSE) for helping me find it I've had the same effect on me. I think it has to do with the mental model I have to represent things and how I think about it. Something about Erlang's model meshes much better with how I mentally conceptualize things (bubbles and arrows on paper!) than a traditional OO structure. I feel pretty at home with Erlang.
|
# ? Jul 4, 2014 13:57 |
|
LYSE is awesome, thanks MononcQc! I first toyed with Erlang a couple years ago but never had a project to do anything serious with it. Now I've got a system with tons of crash-happy workers talking to clients and Erlang is making dealing with it and doing failover a breeze. Cannot imagine how painful it'd be to be doing this in C#. Question: In my program I have continuously running bots that all register themselves with a router, and then the router routes requests to bots that aren't busy. It's trivial to make the router handle a bot dying, but I'm unsure of what to do when a router dies. I've had a couple of meh ideas: When the router starts it could supervisor:which_children, query all the children and try to reconstruct its state. Bots erlang:monitor the router, and once they're in a state where they're both idle and the router is dead commit suicide. Upon restart they'll reconnect with the router. Bots erlang:monitor the router, and periodically check if the router has come back yet (not even sure how to do this). When it has re-register. What do you recommend? The middle seems the most Erlangy, but all my bots killing themselves and attempting reconnect (both to the router and an external system) at the exact same time is concerning. A random back-off time might help, but it seems like there's a better solution somewhere.
|
# ? Jul 7, 2014 04:26 |
|
A few counter-questions: - What happens when a router goes down? I'm guessing input stops coming in, and so does output, connections are lost, etc. Is there any state that is assumed to be there that will leave the program in an inconsistent state if the routers come back up without the bots having noticed? - How do the bots currently connect to the router? How does the router react when one of the bots crashes and comes back? - How often do you expect the router to go down, and for what reasons? - How do the routers know which bots are or aren't busy? - How many routers are there?
|
# ? Jul 7, 2014 13:10 |
|
MononcQc posted:A few counter-questions: Input stops coming in, however if a request got sent to a bot then that will keep running. Basically the architecture is requests come into the router, get sent to the bot, and then the bot handles all further communication. The only assumed state that would be a problem is that bots are connected to an outside service with a username and password. If I try to bring up a new bot with the same username and password while an old one is running they'll just disconnect each other and both be useless. quote:- How do the bots currently connect to the router? How does the router react when one of the bots crashes and comes back? The router is registered with {local, ?MODULE} (is this something people do?) and the bots do router:register(self()). Within the router's gen_server the router does an erlang:monitor and knows to remove the bot from the pool of live bots when it dies. quote:- How often do you expect the router to go down, and for what reasons? My main concern is I write lovely code, so I expect it to crash from being in untested states. This is a rare occurrence so far but puts my system in a really bad/silent state. quote:- How do the routers know which bots are or aren't busy? Right now only one router. When it assigns a request it assumes the bot has become busy, and then bots do a gen_server:cast to the router when they're done. It would be pretty trivial to shard requests and have multiple routers (each with their own bots), though I don't see that happening for a while. Seems like a solution here would be a solution there too.
|
# ? Jul 7, 2014 16:48 |
|
Okay so my understanding there at this point is that the router is required to get the request, but not to handle the response. That eliminates the simplest scheme, making a one_for_rest supervisor that watches the router and then the bots. When the router fails, this kills all bots and then restarts them, everything from a blank slate. This becomes undesirable because you now interrupt requests that didn't need to be. router:register(), I think, should always register on the behalf of the caller, return a '{ok,Ref}' that comes from a monitor when it work. The router can then send two possible responses as messages: {'DOWN', Ref, process, MonitorPid, Reason}, and {ok, Ref, YourRequest}. the ref can be set by a call to register a bit like: code:
Which basically solves your problem but adds some fancypants capability you haven't asked for. You can then listen for failures, etc. and make it all look like it's part of a regular interface, and make it subtle and stuff. I do prefer the blank slate where killing the router kills the workers given how safe and simple it is, but this one is far more flexible and has less of a visible impact on users I guess. You are losing the ability of having a process register someone else (router:register(OtherPidThanMine)), but I'm not sure if you had any dependency on that at this point.
|
# ? Jul 7, 2014 17:11 |
|
MononcQc posted:Okay so my understanding there at this point is that the router is required to get the request, but not to handle the response. Ah that's really nice, definitely makes more sense. So if I understand this right, every time you become available for a request you register yourself. This way, if the router is dead and you're busy then you don't notice until you're available and then you just loop until it comes back. Cool!
|
# ? Jul 7, 2014 19:25 |
|
THE PLATFORM MASTER posted:Ah that's really nice, definitely makes more sense. So if I understand this right, every time you become available for a request you register yourself. This way, if the router is dead and you're busy then you don't notice until you're available and then you just loop until it comes back. Cool! Yeah. The thing is that the monitor is required in case the router dies while you're not busy, just waiting for a request. So that way you can generally know if the router dies while waiting for a request, and would otherwise register naturally when you're ready to serve the next one.
|
# ? Jul 7, 2014 20:03 |
|
MononcQc posted:howistart.org got released recently and I have a tutorial on there about how I usually get going with projects to write libraries and releases This is a really great tutorial! Definitely a great way to show a "real" example, rather that something small and contrived. Jose Valim just added one for Elixir that isn't quite as in-depth, but covers some Elixir specific things like Mix, agents, and protocols. I'm still on the fence about Elixir, but at least it's neat to follow a very young language.
|
# ? Jul 9, 2014 03:00 |
|
So I'm about to release a short free [pdf] manual on managing Erlang systems in production, with less than 100 pages. It has gone through no real editing from real editors whatsoever. From the intro:quote:This book intends to be a little guide about how to be the Erlang medic in a time of war. It is first and foremost a collection of tips and tricks to help understand where failures come from, and a dictionary of different code snippets and practices that helped developers debug production systems that were built in Erlang. I'm looking for people to review the document and send me back criticism by e-mail and whatnot. I'm looking for anything from grammar to "this bit here is poo poo, remove it" and whatnot. Let me know if you're interested, I really need eyes on this.
|
# ? Aug 17, 2014 15:49 |
|
MononcQc posted:So I'm about to release a short free [pdf] manual on managing Erlang systems in production, with less than 100 pages. It has gone through no real editing from real editors whatsoever. From the intro: I'd be happy to review it. I don't have any production experience with erlang though; I've just used it for hobby projects for a while. PM me a link if you want my feedback.
|
# ? Aug 17, 2014 15:59 |
|
I have some limited production Erlang experience and would be be happy to look it over for you. MniotSA@gmail.com
|
# ? Aug 17, 2014 16:36 |
|
MononcQc posted:So I'm about to release a short free [pdf] manual on managing Erlang systems in production, with less than 100 pages. It has gone through no real editing from real editors whatsoever. From the intro: i'll review it. is it on github?
|
# ? Aug 17, 2014 22:19 |
|
the talent deficit posted:i'll review it. is it on github? Not yet (it's behind a private repo, but I can't give access without giving access to a shitload of other code). I have a PDF I link to.
|
# ? Aug 17, 2014 22:21 |
|
MononcQc posted:Let me know if you're interested, I really need eyes on this. I've got some time to read this, and could shop it around to coworkers if necessary.
|
# ? Aug 18, 2014 16:53 |
|
MononcQc posted:So I'm about to release a short free [pdf] manual on managing Erlang systems in production, with less than 100 pages. It has gone through no real editing from real editors whatsoever. From the intro: Me too
|
# ? Aug 18, 2014 18:58 |
|
|
# ? May 11, 2024 09:13 |
|
I know next to nothing about Erlang so would be interested to review this. I'm an architect an review and complain at documentation quite frequently.
|
# ? Aug 19, 2014 02:05 |