Hmm, I have no experience with openshift, and I've never heard of a server needing to know its own IP address. Just goes to show how little I know of networking. Can you point us at the relevant openshift documentation?
If it is indeed the IP address, it sounds like you're most of the way there. Did you try changing the definition of open-socket that you found, adding a fourth argument with the right IP address?
"Did you try changing the definition of open-socket that you found, adding a fourth argument with the right IP address?"
I think that's exactly how to make this work (albeit hackishly). Here's the code for that, but note that I haven't actually tried this out:
(xdef open-socket
(lambda (num)
(tcp-listen num 50 #t (getenv "OPENSHIFT_DIY_IP"))))
I've done some OpenShift experiments using a Node.js cartridge; I'm not engrossed enough for a DIY cartridge yet. :) It's nice as a freemium host for long-running servers, so getting news.arc to run on it would be pretty exciting.
---
"...and I've never heard of a server needing to know its own IP address."
This isn't its own IP address; just looking at the way this needs to be used, it's the a IP address of a reverse proxy. I assume this is so the OpenShift cloud can easily hibernate and migrate these hosted servers while it does its own load balancing and maintenance.
Well, like I said before (http://arclanguage.org/item?id=17988), you're in the wrong place if you're looking for 'futureproof'. The point of arc and its variants isn't to provide any guarantees, but to teach you to fish. If you'd like to be able to build your own lisp while marooned on a deserted island :)
For this purpose, any of these dialects will do. I think I and others here tend to be more well-versed with anarki. Pauan isn't available here anymore, but still easy to contact separately.
Thanks for trying this! I'm very curious to see if you manage this, but I don't think anybody here has tried this before. You're probably most likely to find help in he racket list that you've been searching.
Again, do come back and tell us if you get this working and what it took.
This might be heresy, but I'd recommend also taking a look at http://lobste.rs. It looks like HN but is built on a different open-source platform. It supports email notifications out of the box, which is crucial in the early stages when your users haven't yet gotten into the habit of visiting your site.
All this is nothing arc+HN can't be modified to do, of course. But it doesn't right now.
Hmm, what are some examples of languages with design holes, or language mechanisms that help programmers manage design holes? Lower down you suggest that an error when adding a string to a non-string is a design hole. The creators of Java would disagree. Any language designer would say that at least some of his errors are 'designed in'. So what's the subset of error messages you're getting at?
Like I said privately, I disagree that exceptions are always discouraged. They're encouraged in python. It sounds like they're discouraged in javascript. But I'm not sure you can generalize to other languages, or to 'error mechanisms' in general. Javascript doesn't seem to have any problem throwing syntax errors on the console.
"Hmm, what are some examples of languages with design holes, or language mechanisms that help programmers manage design holes?"
Design holes are one part of a venn diagram: They're not a part of the program's design, and yet it's possible to encounter them in the program's behavior.
If a specification document says a behavior is unspecified--I think the C spec is notorious for this--then that's where you'll find a concrete example of a design hole. The design is concrete, and any implementation is concrete, so their difference is concrete.
Personally, I see design holes whenever I want to run my program without finishing it. The unfinished parts are gaping holes.
---
"Lower down you suggest that an error when adding a string to a non-string is a design hole."
It's an example of a design hole if the designer doesn't care what happens.
---
"Any language designer would say that at least some of his errors are 'designed in'."
I'd say if the language designer really wants people to avoid a certain design hole, they can put a little fence around it. The fence is part of the design, but on the other side, there's still a hole.
---
"Like I said privately, I disagree that exceptions are always discouraged."
Inasmuch as they're not discouraged, they don't count as an error mechanism. This a gray area.
I know this is a slippery response to give, but this is about the way I set up my terminology, rather than the purposes I have for talking this way.
To disable this, redefine abusive-ip to do nothing, or delete the call to it in srv.arc. Or if you're just trying to do benchmarking you can disable it for requests from localhost.
Sriram Krishnamurthy: "Racket has two different languages (for the purposes of this discussion), Racket and Typed Racket, and a program has to live in one or the other. Whereas Pyret takes a different, gradual philosophy to type annotations, so a program doesn't have to move between the two languages." https://news.ycombinator.com/item?id=6702563
