However, using the code from the source file is not always possible as you may have typed it in from the repl, or that file may have changed.
Also, many people may not actually indent their code properly, and 'src presumably should provide some sort of standardization.
The only reason that I can think of for reading the text directly from the source file would be that you would get all of the comments as well, not just the docstrings.
So far the ppr function indents the code surprisingly well, and I've actually used it sometimes to figure out how I should be indenting my code ;)
No I haven't. I've been meaning to look into that, but so far I've just been using arc.el. If you know anything about getting arc to work with slime, and have any success in that area, I'd be interested.
I've been using a setup for running the arc server that allows me to connect to an already running arc service. I have a shell/mzscheme file that launch the arc server, and in a separate thread runs the repl parameterized to read and write on two pipes. Then I have another shell program that just reads from the one pipe, and writes to the other. Finally, I rlwrap that, and I'm connected to the arc repl just as if I had run it normally from the command line.
It's great for making a server that can be launched by cron or initd, and still be able to connect to it. You could alternatively use a socket based system, or disable the close-on-eof, and then you wouldn't have to worry about quitting your server when you disconnect. Though, odds are you aren't going to be worrying about that anyway, as you're only using it for an ide.
thanks. i'm on Windows though and slightly fascist and unreasonable in that i'm not particularly worried about the program working on another platform. i should have mentioned that though. (also i think if anyone needs a noob-oriented IDE, it's going to be Windows users)
The same system should work for windows. Windows does support named pipes, and you don't have to use unix shell code to launch the arc process, since you're writing another program anyway.
Yes, but anyone running Windows is much less likely to use emacs or vim over some gui ide. Linux users are much more likely to be willing to learn those two.
It does most of what you describe (connecting/disconnecting from a running Arc repl). I don't know if you can use it to save cron jobs, but that's not something I typically need to do.
Yes, I use screen very heavily, and I do use it to leave an arc process running, and connect to it again later.
But it can't connect to an arc repl that was executed by a non-interactive shell, such as via cron or initd. That's what I use the pipe system for, and a similar system could easily be used by an ide to communicate with arc and not create a visible shell window.
But yes, that is exactly the fix, and also why I wrote it that way. Unfortunately, I'm beginning to think that the order of the function arguments could have been planned a bit better. All of those numbers can be rather confusing.
Yes, that is correct. I'm sorry if I confused you. Maybe in the future the core of arc would handle packages to provide namespaces, but I meant more that since arc functions will be handling the use of the meta-data, it should be easy to turn that around and generate the meta-data from how you're using it, and a little more information about who you are and what you're trying to do.
As the syntax will not be lisp-like, it will not nearly as easy to write a translator as it would be otherwise, but lisps such as arc are still very concise languages, and macros give you a lot of power.
Which would you rather do? It will probably be challenging either way.
1) powerful macros
2) functional and imperative programing
3) strong tree handling functions
Disadvantages:
1) arc is somewhat slow.
2) arc has few libraries
There might be more, but lisp is just a programming language like everything else. It might be somewhat better, but odds are it won't be a "silver bullet".
I think that Lisp can support good quality syntax parsers. An example of this, although it's not a full fledged language, is CatDancer's JSON parser built on top of a general-purpose parser library: http://hacks.catdancer.ws/parser-combinator-approach-to-json... (it's a long article, the relevant parts are the ones about the parser-combinator approach).
Also, it seems as though your in-house language isn't completely specified yet. One area where Lisp excels is implementing unspecified things, and changing them with great flexibility on-the-fly.
Shader mentioned that Arc is slow, and this does seem to be the case. If you really want to use a Lisp, and Arc is too slow, it's probably worth looking at a few other Lisps before turning to Option A -- there are very fast implementations of both Common Lisp and Scheme.
Feel free to push it to anarki's master branch, which is for the moment still arc2-based. I haven't yet ported the extended make-br-fn form to arc3, so I'll have to do that before I can forward-port this to arc3.
Which branch should I be working on if I want to port things to arc3? So that we can eventually move Anarki's master branch over to arc3? is it arc3.master? arc3.extras? You seem to have a separate branch for the help stuff. Is that just temporary while you try and get it to work?
http://arclanguage.org/item?id=9777 explains the details. In brief, hacks should be made relative to the official branch, and then tagged appropriately and merged into arc3.master when they're finished.
The branch for help is not really temporary. I already have 'help, 'src, etc. working. It's there because it's a pretty large subsystem and it's useful to have a branch to track changes.
I'm not 100% sure what that means. I understood that I should co the origin/official branch, make the code I'm porting work with that, but I don't get what I'm supposed to do next. Make a commit, tag it, and merge it over? stash the changes, co arc3.master, apply the stash, make a commit and tag it?
As for the help branch, am I right in understanding that it's just for keeping track of the development of the help tools, and that master also contains all of the changes?
Checkout official (`git checkout official`). Now, switch to a temporary branch (`git checkout -b tmp`). Make your changes. Check that everything works. Commit the changes (`git add ...; git commit -m "..."`). Tag it (`git tag shader.ppr.0`). Then checkout arc3.master and merge in your tag (`git checkout arc3.master; git merge shader.ppr.0`). (At this point the temporary branch can be deleted.)
That's the simple way to do it, anyway. You can in fact make changes which are "relative to" official even if you actually do the work in a temporary branch derived from arc3.master, by using git rebase or git cherry-pick, and I'd highly recommend learning how to use these and other advanced git commands. Also, if you want or need other hacks, you can merge them in after switching to a temporary branch but before making your changes.
And yes, the arc3.master branch does contain all the changes in the arc3.help branch; whenever I change the help branch I merge it into the master branch as well. Note, however, that the reverse is not true - the help branch contains only the modifications needed to get the help system working, and not the other changes in the arc3.master branch.
Does git not check out tags unless they are requested? Otherwise wouldn't all of those changes stay on the official branch as well? Though I suppose the official branch won't be pushed to by most people, it would still clutter the local version, wouldn't it?
Lots of those sound like reasonable ideas. It sounds like many of those could actually be stand alone systems. Your examples system, for instance, is something I have been planning on adding to the auto-documentation features that arc currently has.
It sounds like these ideas, and similar ones, can be broken down into three sections:
1) Auto documentation and help; Comes with arc for all functions and libraries. (i.e. tools like 'help, 'src 'fns, etc.)
2) Library loading system. Library meta-data, etc. Handles individual libraries and their details.
3) Web service for easy publishing and locating of hacks. Handles finding a hack, and the relationships between hacks on a global scale.
Part 1 can be done separately; it is rather decentralized and can be iteratively improved as it is not required by the others, nor does it require them. The more we work on it, the better a documentation system arc has. It can be worked on independently by multiple people. I will probably be spending most of my time working on these functions ;)
Part 2 and 3 require more standardization, and so need to be done with community oversight, but are still independent from eachother. I envision a library loading system similar to CatDancer's 'lib, that can work standalone like always, loading the new meta-data about dependencies, related hacks, history, etc. from a spefic internet location. Git might be useful here for keeping track of dev history, etc.
Part 3 more specifically would be a web service like news.arc, except it would be psv.arc, hsv.arc, or something. It would create a directory system for storing hacks, and support several apis and web hooks to allow people with proper authorization to publish and download hacks. It could be included with Anarki, and anyone could run their own hack server with minimal effort. This will probably be built last, as it depends on part 2.
With this web service, the functions created for part 2 can be extended to support the service, and find packages by searching a list of known hack servers. There could of course be an 'official' Anarki hack server, but it is just as well if we allow more than one. A centralized Anarki is practically an oxymoron anyway.
So, #1 can be done in place now, and includes extended documentation facilities, examples, etc, #2 is the structure for the library meta-data and the functions used to load it, and can probably be done in a lib in anarki as well. It may require it's own folder or branch. #3 is the web service, and probably the most involved of the three, and will require a separate branch or even repo.
Are you saying that the label should include the version information? Or is that included in the "information about a hack"?
Let's suppose for a moment (very hypothetical ;) that I had written a new and improved version of ppr, and I had it in a file named ppr.arc. How would you recommend that I publish it?
If the version information is intended to convey meaningful information (such as major release vs. minor release, alpha vs. stable, etc.), then I'd put that in the information about the hack, instead of in the label.
The way git is normally used by other projects is that files don't contain version or release numbers, and when a release is made a package file is created (a zip or a tar or whatever), that contains the unique version or release number (foo-1.34.03.zip). So, in the same way, you could take a ppr.arc file that you have in git and publish it as shader.ppr0.arc, shader.ppr1.arc, etc.
