Ooh, interesting! We might want to figure out a long-term documentation system for Anarki; the existing arclanguage.github.io documentation is for Arc 3.1. And while that's great, it's suboptimal for cases like this, because it says "...there is no support for outgoing network connections." (https://arclanguage.github.io/ref/networking.html).
I appreciate the info. I was actually just looking at Mu since I cloned that code for review recently. Since the framework I'll be doing this in is a testing suite, Mu may be the best model for me to follow.
Since I'm focused on UDP, Looking at comments in ac.scm in Arc, I realized MzScheme might hold the answer - there are plenty of UDP functions in those libraries.
Let me poke around a but and I'll shoot you an email if I have something to pass by you for opinion.
My immediate interest is in "News". I was seeking a codebase to work from that would put me in a similar space as HN in look and function. I came across Anarki and was pleased to see it was related to Arc which I have recently been playing with.
My longterm interest is in shifting my mental focus to a more Lisp-oriented way of programming and thinking. I'm not a programmer by trade; I am a software tester and scripter, mostly. I use Python typically, but after working on an OS build I had to learn Guile and Emacs Lisp quickly. I fell in love with Lisp and Scheme due to this experience.
Arc interest came about after reading about it on Paul Graham's website. I'd worked through a portion of Practical Common Lisp by Seibel and decided to try out Arc. It felt right. Since I also happen to work in the Information Security space, I have ideas that for the most part feel like Lisp is the right language, but I will need to become more proficient. Anarki feels like a good place to start to get there from.
Side note: An an automation tester at UCLA working with SenseTalk via Eggplant, I came across Mu while researching alternatives to Eggplant in areas it fails to provide results, such as passing and receiving AIX system calls, or validating logs are being written to. Mu has caught my attention for the longterm, as well, so kudos for both Anarki and Mu.
Very interesting. Though the thought of NASA just using Python and a proprietary solution seems worrying. Maybe it's just for the test harness and other scaffolding, not code that will actually run in orbit.
I know lots of large organizations use Eggplant but this paper is a new one to me. Thanks - had to share this with my co-workers! Everyone seems enthused we share a testing tool with NASA ;-)
I work in Healthcare and we use Eggplant to test a large functional area of our Electronic Health Record (EHR). Like many automation tools, much of the success of the testing comes down to the testing team and how they develop the scripts.
I approach automated scripting design the way I approach programming an app, so I am pretty formal and diligent, I think. Hopefully I am taking lessons learned from Lisp and applying them to my work in automated testing to make the best tests I can.
It's kismet, perhaps, but I also worked on a project called Arc some 9 years ago before I found - well, Arc. It was a build tool chain written in Scheme, developed by Gregor Klinke. I was at the height of my interest in Lisp and Scheme back then, and I liked the idea of this project for potentially building a Software Configuration Management system oriented to Scheme and Lisp.
Looking back at this project with new eyes, perhaps swapping out Scheme for Arc, I wonder...
When I put the anarki folder in D:\, calling it worked fine.
However, when I put the folder in D:\Steve - D\Apps\, I got the following:
D:\Steve - D\Apps\anarki>arc.cmd
default-load-handler: cannot open module file
module path: #<path:D:\Steve>
system error: The system cannot find the file specified.; errid=2
I figure it has to do with spaces in the pathname, but unsure how to fix it.
musk_fan, your initial attempt inspired me to build on it :) Now that we can enumerate from a start number to an end, I hanker after something more comprehensive. Also, after reading malisper's description of iterate at http://malisper.me/loops-in-lisp-part-3-iterate, I thought I'd try to mimic its syntax, in hopes that it'll fit better with a Lisp and be extensible.
Wow, perhaps I should become an APL programmer. (My links below are probably familiar to everyone here, so forgive the shameless replugs. I'm mostly just working through commonalities for my own self.)
"[There is] a sharp contrast between Subordination of Detail and Abstraction as the term is commonly used in Computer Science. Iverson’s notion of subordination is the elimination of notational obligations through the use of generalization, systematic extension, and implicit guarantees. The usual notion of abstraction is the means by which 'API' barriers may be introduced to implement conceptual frameworks that suppress underlying implementation considerations in order to allow a black box reasoning at a different, non-native abstraction level."
I'm very partial to this point, but confusingly I've been calling Iverson's notion of subordination of detail "abstraction", and Iverson's notion of abstraction "service"  or "division of labor" . Though lately I try to avoid the term "abstraction" entirely. That seems on the right track.
Regardless of terminology, this is a critical distinction.
"Common practice encourages decomposing a problem into very small components, and most programming languages emphasize a clear picture of a small piece of code in isolation. APL emphasizes finding ways of expressing solutions around the macro-view of the problem."
Quoting Knuth: *"I also must confess to a strong bias against the fashion for reusable code. To me, re-editable code is much, much better than an untouchable black box or toolkit."
Compare me: "Watch out for the warm fuzzies triggered by the word 'reuse'. A world of reuse is a world of promiscuity, with pieces of code connecting up wantonly with each other. Division of labor is a relationship not to be gotten into lightly. It requires knowing what guarantees you need, and what guarantees the counterparty provides. And you can't know what guarantees you need from a subsystem you don't understand."
OMG, he's talking about "big picture" and "optimizing for the rewrite" I call the latter rewrite-friendliness at http://akkartik.name/about. And "big picture" is in the navbar on the right of my side.
Ok, that's enough replugging. The most tantalizing idea for me here is to try to get structure to do some of the heavy lifting that names do in more conventional languages.
Not a dumb question at all; there may well be something broken here.
It'll be a few hours before I can try running it, but one possibility: perhaps it will quit after serving one further request? Looking at the code (https://github.com/arclanguage/anarki/blob/3a07f946f9/lib/sr...) I think it's waiting on serve-socket before it gets around to checking quitsrv again. Can you try that if you haven't already?
Thank you for your help!! Could you help me understand what you'd like me to do?
I'm not sure what you think I should try.
After looking up the definition of the 'until' macro, the line of code referenced seems to tell me: if quitsrv* is not nil, then continue to serve-socket, which looks to me, at a noobie's glance, as returning the function "accept-request-with-deadline", opening up threads to serve the request?
i.e., quitsrv* now returns t. According to this definition, doesn't that mean that serve-socket should stop?
And incidentally, when I run more defop macro calls, it returns the 'procedure' but (asv) doesn't work; none of the new page on localhost show up (instead it is "Unknown"). I'll look more into it but not really sure how to proceed after glancing at (def asv).
I've copied down the definitions for while and whilet from arc.arc but they don't seem helpful at first glance. Will look further into them if you think it would be useful.
Not at all. I meant that if your server doesn't serve much traffic it'll spend much of its time inside serve-socket blocked on a new connection. It's only after serving a connection that it'll loop around to check quitsrv.
I just ran an experiment, and indeed the server stops after one more request:
ready to serve port 8080
arc> (= quitsrv* t)
; now browse to localhost:8080; page served
quit server ; printed by *serve*
; hit reload on localhost:8080; no response
I've recently discovered the Caddy server (https://caddyserver.com/), which makes SSL and application proxy deployments super easy. Like, 2 lines of config:
domain.com #uses the domain to automatically set up SSL with Let's Encrypt
proxy / localhost:8080 #redirect everything to Arc on 8080
I will say that Arc runs a bit resource intensive, and the slightly slow boot times mean you don't want it to have to re-launch because of infrequent requests. I don't know how well it would work on Heroku.
Also, some VPS services like vultr.com offer $5/mo nodes that have more resources than what you get from Heroku at $7/mo anyway.