Arc Forumnew | comments | leaders | submit | byronsalty's commentslogin
2 points by byronsalty 5873 days ago | link | parent | on: Where are we going?

I don't think option #2 is feasible given the licensing of Arc. I think all forks are currently in violation of the Arc license. Which sucks.

-----


Any chance we can get the next version of arc (from PG/RM) released with a less restrictive license?

I also don't see any reason to use the same license for the purely community based libs. We should choose a less restrictive license for these.

-----

3 points by byronsalty 5887 days ago | link | parent | on: Trifecta

Nice I didn't realize there were Arc lectures out there!

-----

1 point by byronsalty 6079 days ago | link | parent | on: Problem displaying images

Within Anarki all the file serving was done out of the special docroot directory (at least it was a month ago). I'm not sure if disallowing "../" is what we want or if it what we really want is to ensure that all file serving comes from that dir.

Thoughts?

-----

3 points by almkglor 6079 days ago | link

Disallowing .. is the easiest solution. Of course, the current solution simply rejects on any ".." including /foo..html and /subdirectory/../foo.html

Hmm probably do something with the Anarki-specific qualified-path instead...

Edit: done and on the git. Assuming you have a directory foo/ on your public_html, you can access favicon.ico by /foo/../favicon.ico

Edit: soft links would probably break though. Edit2: they don't, at least on mzscheme 360 and ubuntu

-----

2 points by byronsalty 6111 days ago | link | parent | on: Anarki Stable

This why the whole "network of trust" concept as it relates to massive distributed software projects is important. I'm sure if Arc will do well then PG will need to establish people whom he trusts to aggregate packages and give him only the good ones in order to cut down his personal time investment. Some guys on this forum are definitely knowledgeable enough and motivated.

-----


Somebody is reading my mind.

-----


Consistency in the builtins would be ideal - I don't care as much what standard is decided.

-----


This what is broken in Arc right now - essentially we can't fix anything of this scale (or arguably anything non-trivial). If we do there will be merge nightmares when PG releases the next official version (and every subsequent release). All we can do is mention problems on the forum and hope he notices and changes things in the next official release.

I believe this would be solved if we shared a repository system (git) with PG in which we could sumbit patches which he would hopefully approve and merge in. Or not approve. Or delegate the sifting out the good patches to someone who knows what they're doing / shares the proper vision of arc.

Honestly this is very disheartening.

-----

5 points by cchooper 6115 days ago | link

I don't think that would fix it, as PG would probably refuse most of the patches anyway. It's not like this forum has a lot of traffic. Patches are unlikely to get lost in the flood (12 articles in the last 24 hours, and PG last commented 18 hours ago).

The two ways to get changes into Arc, as far as I can see, are to find a bug or write some real-world code that proves your suggestion is a good one. With so little real-world code around, that means very few changes will make it.

On the other hand, the last release was all about merging News.YC so there's no surprise that it lacks new features. Who knows, perhaps the next one will incorporate half the stuff from Anarki? We have very few data points from which to draw a conclusion.

-----

3 points by projectileboy 6114 days ago | link

Don't be disheartened, brother. It seems to me Mr. Graham gave us all a first cut to get exactly this kind of feedback, but the core language isn't yet fully baked, and so we should acknowledge that we're at the very beginning of a long journey. I'd be surprised if Linus Torvalds was merging in kernel patches from anyone besides himself in 1992.

-----

1 point by byronsalty 6115 days ago | link | parent | on: Discussion on ranking algorithms

This approach seems like it would work but it would probably be odd because scores would be ever increasing. Eventually the scores for the site would get extremely high.

-----

1 point by byronsalty 6115 days ago | link | parent | on: Suggestion: constructors

In practice I imagine one would just use a known symbol like 'removed mid list/tree instead of blindly using a nil. But this is much less fun.

-----

2 points by kennytilton 6113 days ago | link

Puzzled. Do you mean the nils would arise because non-nil entries would be changed to nil as they were (somehow) processed? Just delete the cons:

   (= (cdr prior-kill-me) (cdr kill-me))
instead of:

   (= (car kill-me) nil)
Otherwise you are forever iterating over the now irrelevant cons,

-----

More