I think the problem might be that Arc doesn't support some of data types that you are getting from the json response. For example Arc does not support booleans true/false it only has 'nil' or not a nil value. That's why, in the past, I used Andrews library .
That said I haven't had a running install of arc in many years so I could be off base.
Looking through the Anarki logs I think I'm seeing signs of our first edit war. It's been very gradual so we haven't noticed until now.
Anarki used to use Andrew's library from http://awwx.ws/fromjson (perhaps an older version of your link, i4cu) I switched it out back in 2009 for a faster replacement (https://github.com/arclanguage/anarki/commit/dad4dc6662), not realizing that I was breaking the read side in this rather obvious manner. Since then a bunch of work has happened on emitting JSON, but apparently nobody tried parsing JSON until now.
We could retrofit these bugfixes, but I think it would just give up the speed gains to parse things character by character. May be worth just returning to Andrew's version.
But I'll try working with the existing version first, just in case it's still fast.
Just my two cents, but if I were using Arc today I'd consider doing what could be done to conform to the edn spec . It was born out of Clojure, but is not Clojure specific. Also, as I understand it json is actually a subset of edn thus the two would not collide. But for now I think just getting a json parser running would be a win.
But now that I look closer at the ac.scm history (now ac.rkt in Anarki), I realize I was mistaken to believe Arc treated #f as a different value than nil. Turns out Arc has always equated #f and 'nil with `is`, counted them both as falsy, etc. So this library was already returning nil, from Arc's perspective.
There are some things that slip through the cracks. It looks like (type #f) has always given an "unknown type" error, as opposed to returning 'sym as it does for 'nil and '().
So with that in mind, I think it's a bug if an Arc JSON library returns 'nil or #f for JSON false, unless it returns something other than '() for JSON . To avoid collision, we could represent JSON arrays using `annotate` values rather than plain Arc lists, but I think representing JSON false and null using Arc symbols like 'false and 'null is easier.
That documentation may be wrong. On the other hand, it may be correct in the context of someone who is only using Arc, not Racket.
There are a lot of ways to conceive of what Arc "is" outside of the Racket implementations, but I think Arc implementations like Rainbow, Jarc, Arcueid, and so on tend to be inspired first by the rather small set of operations showcased in the tutorial and in arc.arc. (As the tutorial says, "The definitions in arc.arc are also an experiment in another way. They are the language spec.") Since #f isn't part of those, it's not something that an Arc implementation would necessarily focus on supporting, so there's a practical sense in which it's not a part of Arc our Arc code can rely on.
(Not that any other part of Arc is stable either.)
> Really, #t and #f are not proper Arc booleans, so it makes sense that Arc can't tell what type they are.
Really, #t and #f are not proper Arc anything, but the language apparently handles them so IMHO Arc should also be able to know what type they are. Otherwise, I fear, this will become a Hodge Podge language that will lose appeal.
Personally I don't care if Arc supports booleans. I only care that it can translate booleans (when need be) to a meaningful Arc semantic. That said, if we're going to support booleans then let's not create partial support.
> This parameter determines the default Racket value that corresponds to a JSON “null”. By default, it is the 'null symbol. In some cases a different value may better fit your needs, therefore all functions in this library accept a #:null keyword argument for the value that is used to represent a JSON “null”, and this argument defaults to (json-null).
If you set the JSON null to nil before running your example, it works as you'd expect:
I think we should get rid of json.rkt and use the Racket built-in. It's way better documented, and we should use that one. (But I'm not going to delete json.rkt myself, particularly when I know someone is working with it.)
What's the thinking behind implementing captcha? I really, really hate ReCaptcha. For most sites the payoff to a spammer isn't really worth even the simplest robot test. A new site that throws ReCaptcha is an instant bounce.
>What's the thinking behind implementing captcha? I really, really hate ReCaptcha.
It might be useful if it only shows up on the login/signup page after failed attempts, but it might also be overkill. Personally, I prefer overt solutions to opaque ones like shadowbanning and throttling IPs. But mostly it seemed like a good way to figure out some basics (managing keys, how the app server manages the form loop, API responses and JSON.)
I could finish the test I have, push that and leave integration for later.
I agree with overt vs shadowbanning. My tendency is to just add tools for moderation. Let bots sign up and spam, but make it easy to take them down and ban them at that point. Arc is reasonably decent there.
Sorry, my comment was rather lazy. Let me try again.
I get the impression many of the people who want to start a HN like clone are considering using it as a content delivery platform. For example http://arclanguage.org/item?id=20452 notes a revenue sharing model for specialized content. Now, if that's the case these site owners will have both spammers and content scrapers to contend with. So my initial comment was also referring content scrapers too.
However there's another thing to consider: Session storage costs. About 6 months ago I went through a process to reduce the cost of data held in memory for session storage (redis in this case). The session data was continually analyzed for determining both who the bad users were and for knowing what value the good users are getting out of the app (feature planning etc). It was an interesting process, where just by reshaping the session data, thousands of dollars per month could be saved in db fees. Now I realize the someone starting a HN clone is probably not dealing with that, but I'd be willing to bet that part of the reason Captcha was implemented in HN proper was to reduce fees associated with the volume of requests, session costs and even network load. It's my feeling that, generically speaking, adding captcha functionality is a good Option to have.
> I'd be willing to bet that part of the reason Captcha was implemented in HN proper was to reduce fees associated with the volume of requests, session costs and even network load.
Let me add some info to that.... I'm not sure if anyone noticed, but HN has implemented new session management strategies. You can see this as your login is now maintained across multiple devices, where the arc code (that we have access to) logs you out upon logging in elsewhere. I also believe that when pg handed over the HN code significant changes occurred including how session data is stored and how that data is utilized to integrate with cloudflare. Obviously I'm making big guesses, because I don't have access to the code, but I'm willing to bet the changes HN has put in place would surprise everyone here.
Sadly everyone who sees HN today will come here and look for the source code not realizing what's available here is not modern nor comparable.
> For most sites the payoff to a spammer isn't really worth even the simplest robot test.
Maybe I am missing something.... Isn't captcha just a fairly simple robot test (and thus preventing spam)? Or are you suggesting something even simpler? Because I've run a few sites and had tried implementing very simple programmatic obstacles and it really didn't stop the spammers.
Maybe the better question is - what would you suggest?
This is probably going to sound super crazy, but I have to say it...
I know you (akkartik) have a google account, because I remember when you moved your blog over to google's services (I think they call it 'circles' or some such). I also remember you created a news aggregator application that scraped content. Yes, I know, it was a long time ago in a galaxy far, far away..., but still...
I'm thinking that google identified your scraping work and deemed you a risky robot type, but they also probably correlated your IP from the scraping to your IP from your google services login and tagged you that way. So now, even if your IP changed, they'll continue to have you in their cross-hairs for, like, ever.
Any takers? If you'd like I can also look into who killed JFK...
a) My cookie acceptance policies are non-standard. (I no longer even remember what they are anymore.)
b) I'm often behind a VPN for work.
c) I'm often on my phone, or tethering from my phone.
Complaints about ReCaptcha are fairly common if you look on HN and so on. You don't have to have run a scraper to hit it, I don't think. I think you may be a robot from the future for never having problems with the pictures of signs and cars :p
Final minor correction: I've played with Google+ in the past (I actually worked at Google on Circles for a year) but I never moved my blog there. I just linked to my blog posts from there.
> Complaints about ReCaptcha are fairly common if you look on HN and so on.
Yeah I'm aware of the complaints, but in my mind HN wouldn't be the best resource of information for such an assessment. By default HN members are non-standard in most ways that would matter to ReCaptcha.
It's an interesting dilemma and one that I'm coming up on soon as I plan to release a new app in a few months time. In my case the intended audience for the app is very widespread and not specific to a tech audience. It could be that the vast majority of my users (if I get any - lol) would never have a problem, because the vast majority of people using the net don't know what a VPN is or how to change a cookie setting (just as examples).
I'll have to give it some more thought, but in the mean time, are you aware of any resources on the matter that would be more reflective than HN?
edit: I often find info like this :
"Different studies conducted by Stanford University, Webnographer and
Animoto, showed that there is an approximately 15% abandonment rate when the
users are faced with CAPTCHA challenge."
But really I do expect to take some loss when using reCaptcha. The question really becomes is it worth it? After all spam can also cause users to leave and content scrapers can also de-value your product.
I think it's less important to have Recaptcha or not than it is to have a working POC for interaction with a remote JSON API, and for parsing JSON in general, since that opens up a lot of possibilities. Recaptcha itself is just the low-hanging fruit for that, since it's so simple.
As far as integration goes, we could just leave it up to whomever wants to do the work or make it easily configurable with the default being not to use it at all.
It's great to see a JSON API integrated in Arc. :)
I took a look and found fixes for the unit tests. Before I got into that debugging though, I noticed some problems with the JSON library that I'm not sure what to do with. It turns out those are unrelated to the test failures.
The JSON solution is a quick and dirty hack by a rank noob, and I'm sure something better will come along.
And in hindsight the problem with the (body) macro should probably have been obvious, considering HTML tables are built using (tab) and not (table). I'm starting to think everything other than (tag) should be done away with to avoid the issue in principle, but that would be a major undertaking and probably mostly just bikeshedding.
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.