b) Run the shell script, install it to the directory containing the arc2.master branch.
c) Run:
plt/bin/mzscheme --no-init-file --load as.scm
It seems to come up without errors and ffi.arc seems to be loading up.
(When you report errors it's usually much faster to tell people how to reproduce your error in this step by step manner. Then they can usually immediately look at the instructions and tell you what you're doing wrong without a lengthy back-and-forth.)
Can you try the steps I outlined and confirm that it works for you? Perhaps something's messed up about the version you're on. Once you have a working version we can go in and poke at the differences to see where the problem might be.
I can't share a copy of the repo, but I'm going about introducing FFI the opposite way: pick Arc 3.1 and add any files that are needed to get just FFI and mysql-ffi.
That's a good approach. Keep at it, I'm sure you'll figure it out.
One way to get help with it: describe simple step-by-step changes to the repo that cause errors. Download arc 3.1, add this file from here, type this in at the repl, etc. Don't forget the actual text of the error you see as well.
Just a suggestion, though I'm not sure what work it will involve: fwiw, why don't you let Arc/Nu be the pure Arc version and lite-nu be the extended version. The name Arc/Nu better reflects the closeness to Arc itself.
Great job on the two - I enjoyed testing and writing them up on Arc Lang Wiki. : )
Because "lite" implies a lacking of something. I'm not entirely against changing the names, but simply swapping them won't work. Anybody have any suggestions for a name for the more "full featured" version of Nu?
Thanks, Rocketnia. I had actually placed each pair on its own line with a carriage return, but the text editor kept removing it upon posting.
I came up with this list keeping Arc/Nu as the proposed name for the pure Arc implementation, and then was left with the '/Nu' slice as the only way to keep the product association. So that left only the Arc component to play with. My personal preference is ax/nu: a -> Arc and x -> extended. Ax/Nu also has the benefit of brevity, IMHO.
Nice touch. BTW, Googling for 'install arc lisp' gets the wiki to the top page or close. I'm hoping that eventually we can get just 'install arc' or 'arc lisp' to do the same. Just 'arc' looks like mission impossible. :) Adding more links to the wiki will help. So listen up, all Arc-fu exponents!
Well, I added links to Arcueid to the wiki as soon as I learned of it, and will be adding links the wiki in Arcueid within the README and wherever else it makes sense to do so.
I see Wikipedia's article on Arc links to the wiki as well, although perhaps it should be amended to be more prominent than a single footnote citation.
I'm not sure the article is directly applicable to arc (first/next mean something totally different in Lucid than say first/rest in clojure). But with such a small community I tend to share interesting links even if they aren't directly applicable.
You preempted my own similar reply, but I'll post it anyway. :-p
---
"Does offer up some options for car, cdr in Arc."
Whoa, really? Please share. ^_^
My reading of the article is colored by my thinking of "synchronous programming" as a programming model in which something stateful is considered to be a sequence of instantaneous values. This makes it sensible to formulate static properties of the program using a temporal logic that supports statements of the form "in the next instant it'll be true that X."
That particular benefit of synchronous programming doesn't make a whole lot of sense in Arc, where (I think) we don't often try to guarantee/inspect rich static properties of stateful models. So if you (or akkartik) see some immediate applicability to Arc, it's not obvious to me what in particular you see. ^_^
Here's the tiny little bit of work I've done with synchronous models. My goal was to find out how much this kind of model-checking technology could help when developing an interactive story, and it turned out to work very well on the toy problems I could come up with: https://github.com/rocketnia/nusmv-if
Hold on to the patch as it may still be useful. Who knows, something may come of a well coordinated movement by AF members to get the attention of pg and rtm. Even a 100 year language needs an active community. :)
I agree that the HN format isn't ideal for the Arc Forum. However, to make even the littlest change here would require one of the active members here to have admin authority. Perhaps a good first start would be for someone here to talk pg or rtm into extending that privilege. We could then update some of the pages here that obviously need updating (eg. the install instructions page!) and begin the process of exploring how to modify HN to better suit a support forum.
I figure that everyone here will prefer to use a hack of the HN format, ie. must be Arc-based, rather than some other commonly used forum application. ;)
I agree. As I said in the other thread, it is a good idea to have an Arc-powered Arc forum.
Before contacting pg or rtm, I think it is a good idea that we talk about what we want to change around here, so that we can give them a clear idea of what we want.
1) Grant admin access to arclanguage.org to a high karma ranking Arc Forum member to update that painfully outdated home page OR update the home page appropriately, with added links to other Arc focused sites such as https://sites.google.com/site/arclanguagewiki/
2) Regarding modifying the current HN based forum:
a. A built in search utility, of course
b. Add 'popular' and 'sticky' tabs to the existing new | threads | comments, etc tabs.
- The 'popular' tab could be a pure karma based collection of the heaviest threads (sum of plus votes, in descending order).
- The 'sticky' tab should be threads created or selected by the admin, usually a collection of how tos, work arounds and frequently sought help. Order should be admin settable, and there should be an area above each thread where the admin can clearly highlight the purpose of the thread.
- if possible, the sticky threads should remain commentable unlike normal threads that become uncommentable after a certain period. I'm not sure how this would affect the site from a performance standpoint as I understand HN currently uses this strategy to optimize performance.
If performance is not a factor, then I would suggest that all threads remain permanently open to commenting. That way an inactive thread could become active and show up under the 'comments' tab, and be of use long after the original contributors have left it.
Guys, these are all great comments, but there are no signs that PG has even visited this forum in a long time, let alone made any changes to it. I want to set expectations.
I know. Last time he posted was 470+ days ago.
He probably would've said it if he had made any change.
So we are left with the following choices, if we want to improve the arc forum : bug pg for changes by sending him emails, or deciding as a community to move discussion about Arc somewhere else.
What are the odds of getting pg's attention? We should do all we can to get it, and only if all else fails should we look into the option of moving elsewhere.
Should we file a petition with pg and rtm, and if we do, where would the best place be to present it? I figure something along these lines might be necessary.
I agree. The Arc community will be better served with more forum focused ways to highlight important/useful threads no matter how old. Dedicated threads with high visibility, including sticky posts within those threads, are used to great effect at many successful community sites.
And search is a huge missing feature on this forum. Googling Arc Forum helps, but not the same thing.
