Page 1 of 1

package for arc 3.1

Posted: 18. Sep 2012, 23:52
by mimosa
Arc is a dialect of scheme written on top of racket:

https://sites.google.com/site/arclanguagewiki/home

http://racket-lang.org/learning.html

In this particular case I'm not sure whether it's worth packaging, because it's in such flux. But I'm curious as to the correct approach for such cases.

After downloading arc, you unpack the tarball and call the executable with mzscheme (which is part of racket) like this:

Code: Select all

mzscheme -f ./as.scm


as.scm is just one of the files in the tarball. But all are needed for it to work.

My specific question is where to put the contents of the tarball. /usr/bin should presumably contain a single wrapper script that calls the rest ...

like this:

Code: Select all

cat /usr/bin/arc
#! sh
cd /foo/bar/arc-3.1
mzscheme -f as.scm
[indeed, that won't quite do, because it leaves the user in the wrong directory if any files are to be loaded]

Just to make it a bit more complicated, for actual use (to provide a command line history in the REPL) it is recommended to call mzscheme with rlwrap:

Code: Select all

rlwrap mzscheme -f as.scm
rlwrap is available from slackbuilds.org. Supposing I wanted to do it like this, would I need to package rlwrap for Salix, too?

Re: package for arc 3.1

Posted: 19. Sep 2012, 00:47
by laprjns
mimosa wrote:rlwrap is available from slackbuilds.org. Supposing I wanted to do it like this, would I need to package rlwrap for Salix, too?
Yes.

Re: package for arc 3.1

Posted: 19. Sep 2012, 14:31
by gapan
laprjns wrote:
mimosa wrote:rlwrap is available from slackbuilds.org. Supposing I wanted to do it like this, would I need to package rlwrap for Salix, too?
Yes.
Unless the package does not go into our binary packages repos, but in our slkbuild repo instead. In that case, you don't need to package rlwrap.

Re: package for arc 3.1

Posted: 19. Sep 2012, 15:44
by mimosa
That is, if I were packaging arc for the slackbuild repo?

Regarding my main initial question, on reflection, this isn't really an installable application. That is, the developer intends you to just use it from inside the untarred directory, and hasn't done the work to take it beyond that. So if you did want to package it, you would need to:

1) write a better wrapper script
2) put the application files somewhere (/usr/share/foo ...?)
3) patch the executable file to look there for its ancillary files whatever the working directory

... and then you would have something installable.

In this case it hardly seems worth bothering - but I am working on a package for racket, which combines a nice IDE for LISP with a series of teaching languages and a book (HTDP):

http://www.ccs.neu.edu/home/matthias/HtDP2e/