Oh and needless to say, any comment on the code is greatly appreciated. Or if there something you don't understand, and want further explanations, let me know, too ;-)
I don't like to waste my time. There is a TODO list on the end of evsrv.arc, if you find an item has any interest, or if you have another idea, please tell me so, so that I can work on what people would like the most first. Actually, just that I work on it and not put this project in the "yet another useless thing" list, and move on.
Initially planned to release under GPL but it's too tiny to merit it, and after me being a moron, it would be too much.
Consider it is public domain. Use it for whatever you want.
Heck, let's be chauvinistic. Let's say it's officially under the WTFPL - DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE (http://sam.zoy.org/wtfpl/), which is basically public domain. Quoting the license link:
Isn’t this license basically public domain?
There is no such thing as “putting a work in the public domain”, you America-centered, Commonwealth-biased individual. Public domain varies with the jurisdictions, and it is in some places debatable whether someone who has not been dead for the last seventy years is entitled to put his own work in the public domain.
Edit: I had suggested the Creative Commons CC0 license, but the Creative Commons FAQ says:
Can I license software using CC licenses?
We do not recommend it. Creative Commons licenses should not be used for software. We strongly encourage you to use one of the very good software licenses which are already available. We recommend considering licenses made available by the Free Software Foundation or listed at the Open Source Initiative. Unlike our licenses, which do not make mention of source or object code, these existing licenses were designed specifically for use with software.
More seriously, thanks for the link, good to know.
But for evsrv, don't worry too much about the license. Use it if you find it useful and this is all. I promise I will not sue you about it :-D!
Also seriously, despite its name, the WTFPL is no BS. As said on the license link, it's actually used, although rarely, for "serious" software, the type you can find in your favourite Linux/*BSD repositories. And the FSF recognizes it as a valid FOSS license (but not the OSI, I think).
Rainbow is a great project, and like for Arc, the performance was/is an important issue (at least, not making people fall asleep waiting for the arc prompt to show is a minimum).
Lots, lots of people here complained/complain about this point, and it's good to see that at least you don't ignore them. Performance matters in the real world, Google made his empire based on this point.
Apparently, the optimization stuff here is real, and this is great. I mean, no offense, but gaining ~ 10% on 1 unique function ('in), and w/ actually making the operation incorrect (for the nil case), is what I'd called premature useless optimization. But this is real, useful optimization. Super!
this is a disadvantageous side-effect of using "java -server" - startup time is significantly longer. And I need to not run tests automatically on startup, that delays the prompt, too.
This was more about the official Arc on MzScheme than Rainbow here. Rainbow is a special case.
> not run tests automatically on startup
Yes, I remember I disabled them when I was using Rainbow for the last time.
Oh, and just FTR, there were a failed test, which I think was about a little problem in internationalization handling. There was a message about a decimal number not being OK, because my locale is fr_FR and the correct decimal separator in France is "," and not ".".
(but this is really not a big deal. Plus, i18n is terribly complex to get right. Plus, most of us (people not having English as their mother tongue) are so used to get fucked we don't even bother with this kind of things anymore.)
> hey, I like my 'in :))
Hihi, I see you've submitted a new "correct" version on the concerned thread, this is really cool.
Anyway, don't take me too seriously. I just expose my views quickly & in a direct manner, and I don't think they're (at least always ;-D) correct. I'm glad you defend yours, and I respect you a lot for that. But sorry, the "useless" here, at least, was too much.
And on the end I suppose we think the same here: (performance) improvements are a good thing to do. I was actually glad to see the "A faster 'in" thread, I prefer that 100x than seeing a thread which would argue Arc is perfect in its current form and people are morons not to think so.
> Sorry to be a pedant, but the paren-balancing is incomplete
This is not pedantry, this is bug reporting!
Yes, the check for '(', ')'s is really naive, and to be honest, I don't feel like coding a decent Lisp parser in Javascript for now :-)
> can't send, even if I click the button instead of hitting "enter"
This was actually not a bug, but a desired feature :-D But this was totally stupid, since the '(' check is incorrect in some cases.
Now, clicking the button will anyway send the content, no check done in JS. If your content is invalid, evsrv will tell you:
arc-online> ( ; then click on the button
Error: UNKNOWN::0: read: expected a `)' to close `('
> You might consider doing some line-wrapping of the output.
Yes, absolutely. This is now (partially) done. `sig' and the majority of cases will be correctly handled, but not everything. `(for i 0 1000 (pr i))', for instance, is still "broken".
The problem is, the results are inserted in <pre> blocks, and after some search, it's easy to make them break lines on whitespaces, but not otherwise (CSS property "white-space").
Plus, a small bug I just recently noticed has been fixed: evaluating "nil" or "()" or "#f" didn't work. It now does ;-) But:
arc-online> #f
nil
arc> #f
#f
But remember this is the eval server:
arc> (eval '#f)
nil
So this is actually quite normal ;-)
Oh, and I tried the site today with Safari, and it globally works but the layout is bad. I'll fix this ASAP.
Anyway, thanks a lot fallintothis for your feedback! Testing these edge cases was smart of you ;-)
May I present to you the evsrv (eval server), a multi-user, multi-tasks, shared time "Arc Machine"!
Once you've created an account, you're in front of our own Arc REPL, with your own environment (i.e: you can define stuff, and state is preserved between requests & logouts-logins).
It's all new, so expect bugs & problems. Plus, I'm not quite sure it can stand on the long term, even more on this small server (single core, 1gb memory, and already running, as you can see, http://dabuttonfactory.com).
Oh yes, and forgive me for the URL, I may buy a domain name for it, but I thought you might like to play with it even in its "alpha" stage ;-)
It runs on a modified version of Arc, that uses some extra MzScheme stuff, mainly namespaces & sandboxes. I may post the source, but like for the domain name, not now. Want to see if it works on the wild before.
Please don't spam it too much for now, I mean don't tell all your friends. But play with it for yourself as much as you want ;-)
Suggestions, ideas, bug reports are greatly appreciated.
Thanks for this, even though I haven't used it yet. I've been using the ArcLite online demo (http://jonathan.tang.name/files/arclite/index.html), but it hasn't been maintained; its creator, nostrademons, hasn't been very active; and it is so slow that the fizz-buzz problem fails to run on it.
Sorry I don't come back on the "want to see if it works on the wild before". I'll certainly show the source, even if it doesn't (work on the wild), but please wait.
Plus, hmmm, did you even bother trying it? You may have chosen another username, but:
arc> (user->repl* "rntz")
nil
If you have chosen another username, OK, no problem (but I can't guess). If you've not tried it, your choice, but then I'll parse your request as "Gosh palsecam is such a moron, an REPL on the browser has no future[1], performance/privacy issue, blahblahblah, but I'll be glad to steal his code for another more useful purpose that I'll not communicate about".
I am, at least I hope, certainly wrong on my analysis, but sorry, that's how I read your message.
And obviously, I don't like to be taken for a moron. And obviously, I don't like this kind of "stealing".
------
1: I'm sure some people think this. They might be right, but this kind of reasoning also lead to "GMail/... has no future", which was proved to be wrong.
I don't know if I'll seriously keep on working on the evsrv, but I can think of lots of good features that being web-based would enabled.
rntz, if you think this is a stupid idea, I have no problem with this, but then tell us about the (better) idea for which you'd like to use the code.
It's true I don't (well, didn't) have an account on the eval server. I didn't really feel the need to try it, not because I think it's crap, but because... well, it's a persistent REPL on the web. That's most of what I need to know, really, and if I ever need a persistent web-based REPL I'll know where to go - I trust it to be everything you say it is (and now that I've looked at it, it is; and it's swanky to boot). Just because I don't yet have a use for a thing doesn't mean I think it's crap. Hell, I don't yet have a "real" use for Arc itself beyond just playing with it as a sort of language sandbox - I haven't even tried firing up the webserver that comes with it! Does that mean I think arc or the arc webserver is crap? Hell no.
I have no intention of stealing your code. If you don't want to share your code, then don't; I tend to assume that Arc-related stuff will be open-source simply because it's common. And if you do share your code, I won't use it for some private purpose that "I'll not communicate about"; I'd share it back. That's how open source works.
The reason why I asked to see the source, despite you noting that you didn't intend to release it until testing it in the wild, was because I imagined (as CatDancer seems to have surmised) that the reason you didn't release it was because you weren't satisfied with its quality yet; hence the comment about "even if it has bugs or scalability issues or whatever".
The reason why I want to see your code is not, then, because I think you've done a bad job - how could I? As you noted, I hadn't even tried it when I made the post. Rather, I'd like to see it because in order to implement it, you have to have done some cool stuff (for example, AJAX, and some way of maintaining a persistent REPL) in arc that I would find instructive to read and possibly useful in the future. I don't ask with a purpose already in mind, but rather to learn; that's why I'm using Arc in the first place.
> Does that mean I think [...] the arc webserver is crap? Hell no
Actually, on some points it is (IMHO of course) ;-D
> I won't use it for some private purpose that "I'll not communicate about"; I'd share it back. That's how open source works.
Sadly everyone is not as honest as you :-/ I've met some people not understanding what FOSS is about, and being big bitches about it, so I'm now more suspicious than I used to be.
But this is no excuse, I was not right to emit judgements about you based on my past experiences.
> weren't satisfied with its quality yet
Yep, was/is the case, see last item on the TODO list (in evsrv.arc)
> some cool stuff (for example, AJAX
Actually, nothing cool or magic about Ajax. It's just sugar (here).
> some way of maintaining a persistent REPL)
More magic here :-) Although it is just because of MzScheme being a very good language, and having namespaces and sandboxes.
> I don't ask with a purpose already in mind, but rather to learn
The noblest of all purposes ;-)
Once again sorry for misinterpreted and being quite rude with you.
I think I may be able to clear up a bit of confusion here.
All (almost all?) of the code related to Arc so far has been released as open source by various authors, including rntz's extensive work with Anarki.
Thus when code hasn't been released, it's been because the author doesn't think it's good enough yet, instead of because the author wants to keep it proprietary.
So when one of us sees something cool, it's not uncommon for us to say, "oooh, we'd like to see the source to that!" Not as a request to give away something proprietary, but to say that if someone has code that they'll be making open source anyway, to encourage them to go ahead and release it, because it looks cool.
I'm pretty sure it was a statement of curiosity. I'd venture to say that that's the intention most of us would have in asking to see the source. (Hell, I'd be interested in seeing it.) You're probably reading too much into this.
(Plus, it's not really "stealing" if you willingly share the code.)
This is a major problem. I agree with you, and I don't see myself writing a lot of Arc scripts in the current situation.
Maybe a client/server would be a way to solve the problem. I may try something like that one of these days. I mean, launch Arc once as a daemon, then talk to it with a lightweight client, via FIFOs (named pipes) or something.
For the moment, you may want to comment the imported arc libraries you don't use (in libs.arc or as.scm), for instance all the HTTP/HTML stuff. Loading only arc.arc, my load time is reduced by 50%.
The trend to use small, energy-efficient computers is something I think really smart. Do more with less. And Arc on a SheevaPlug is a perfect example of it. This device rocks!
