Today I released version 1.30 of Wraith Scheme, which is a full R5 Scheme implementation for the Apple Macintosh. The new version has enhancements for parallel processing, by which I mean multiple copies of the Wraith Scheme application (separate Unix processes) all running at once, sharing Scheme main memory. For details, and to download a copy, visit the software page of my website:
The software page includes a link to a web-browsable copy of the Wraith Scheme Help file, and more specific link to the part of that file that discusses parallel processing.
<Jay_Reynolds_Free...@mac.com> wrote: > Today I released version 1.30 of Wraith Scheme, which is a full R5 > Scheme implementation for the Apple Macintosh. The new version has > enhancements for parallel processing, by which I mean multiple copies > of the Wraith Scheme application (separate Unix processes) all running > at once, sharing Scheme main memory. For details, and to download a > copy, visit the software page of my website:
> The software page includes a link to a web-browsable copy of the > Wraith Scheme Help file, and more specific link to the part of that > file that discusses parallel processing.
That looks seriously cool. I'll definitely give that a try this weekend!
Aside from R5RS support, and multi-process support via shared memory, does Wraith have any onboard facilities for extension, aside the hacking the underlying implementation code directly?
> Aside from R5RS support, and multi-process support via shared memory, > does Wraith have any onboard facilities for extension, aside the > hacking the underlying implementation code directly?
Well ...
(1) I haven't released source code for the program. (I have been thinking about open-sourcing it, but it's kind of like letting someone into your kitchen to watch you cook, and I'm kind of nervous.)
(2) Lisp is pretty self-extensible in its own right; for example, I am sure you could implement a class-definition and - instantiation mechanism in any decent Scheme or in any other decent Lisp.
(3) Wraith Scheme has some built-in capabilities (as extensions, not part of R5) to assist in inspection of its objects and data- structures at low level, to assist in debugging, and to help with building up communication and synchronization mechanisms for the parallel part of the implementation (which provides only very low-level primitives, but does so publicly, so users can build on them).
(4) One of Wraith Scheme's extensions is access to the C++ "system" call -- you provide string X to Wraith Scheme and Wraith Scheme will pass it to "system" as
system( X ) &
"System" is awkward, and fussy to work with, but this extension definitely gets Wraith Scheme out of its playpen.
(5) Along the development path that I personally plan for Wraith Scheme are a number of other primitives for extension. I am probably tempting fate by mentioning them. They include means to communicate with devices on the Mac's USB bus (and if I do that I would probably try to include means for Wraith Scheme to be interrupt-driven by things happening on the bus), support for logic programming as in Friedman, Byrd and Kiselyov's "Reasoned Schemer" (I would be careful to respect their copyright and other intellectual property, of course). I would love to do a foreign-function interface to C++ but that's a huge project.
If there is something specific you have in mind or are interested in, talk to me, either here or by EMail.
<Jay_Reynolds_Free...@mac.com> wrote: > > Aside from R5RS support, and multi-process support via shared memory, > > does Wraith have any onboard facilities for extension, aside the > > hacking the underlying implementation code directly?
> Well ...
> (1) I haven't released source code for the program. (I have been > thinking about open-sourcing it, but it's kind of like letting > someone into your kitchen to watch you cook, and I'm kind of > nervous.)
> (2) Lisp is pretty self-extensible in its own right; for example, > I am sure you could implement a class-definition and - > instantiation > mechanism in any decent Scheme or in any other decent Lisp.
> (3) Wraith Scheme has some built-in capabilities (as extensions, not > part of R5) to assist in inspection of its objects and data- > structures > at low level, to assist in debugging, and to help with building > up > communication and synchronization mechanisms for the parallel > part > of the implementation (which provides only very low-level > primitives, > but does so publicly, so users can build on them).
> (4) One of Wraith Scheme's extensions is access to the C++ "system" > call -- you provide string X to Wraith Scheme and Wraith Scheme > will > pass it to "system" as
> system( X ) &
> "System" is awkward, and fussy to work with, but this extension > definitely gets Wraith Scheme out of its playpen.
> (5) Along the development path that I personally plan for Wraith > Scheme > are a number of other primitives for extension. I am probably > tempting fate by mentioning them. They include means to > communicate > with devices on the Mac's USB bus (and if I do that I would > probably > try to include means for Wraith Scheme to be interrupt-driven by > things happening on the bus), support for logic programming as > in > Friedman, Byrd and Kiselyov's "Reasoned Schemer" (I would be > careful > to respect their copyright and other intellectual property, of > course). I would love to do a foreign-function interface to C++ > but that's a huge project.
> If there is something specific you have in mind or are interested > in, > talk to me, either here or by EMail.
I was actually thinking of the FFI you mentioned in item 5. That would be a huge asset.
The system() call is a nice touch though. Aside from somethng like system("kill -s SIGHUP my-pid") are there any facilities in place to communicate with apps spawned via system()?
Once I've had a chance to download the app and play with it, I'll give you more feedback. :)
> I was actually thinking of the FFI you mentioned in item 5. That would > be a huge asset.
And a whole lot of work, I fear. Apple's XCode development environment is sort of the default for Mac coding, so one could put an FFI in place with reasonable confidence about the development environment users would want it to interact with, but ... a whole lot of work, and a nightmare to maintain.
> The system() call is a nice touch though. Aside from somethng like > system("kill -s SIGHUP my-pid") are there any facilities in place to > communicate with apps spawned via system()?
BTW, for the sake of pedantry, I erred in my description of what Wraith Scheme's "system" interface does; if you provide string X, Wraith Scheme just calls "system( X )", so it is you who get to decide whether there is an '&' in the call.
At present, there are no facilities to talk to processes so spawned. I hadn't thought about it much, to tell the truth. Let me see, I could put stuff in Wraith Scheme to set up and use sockets on the Wraith Scheme end, so that you could talk to something you had set up that had matching sockets. Access to the process's standard input and output would be more traditional, but my rather limited knowledge of what "system" can and cannot do suggests that there are pitfalls in that approach. And there is always AppleScript (though I think you can get at that via "system" with the present mechanism).
Advice, or an expression of preference, would be much appreciated.
Any such mechanism is sort of a coarse-grained poor-man's FFI, of course.
> Once I've had a chance to download the app and play with it, I'll give > you more feedback. :)
That would be wonderful!
There is a lot of documentation on what Wraith Scheme does and doesn't do in the on-line files, accessed from the Help Menu, BTW.
[Incidentally, you don't have to do system("kill -s SIGHUP my-pid") to crash the program; I needed an easy way to do regression-testing of Wraith Scheme's fatal error messages, so I built in an extension that does nothing but cause a fatal error:
(c::down-in-flames!!!)
:-) (Less perverse minds can just use the "Quit" command, of course ...) ]
Jay Reynolds Freeman wrote: > (1) I haven't released source code for the program. (I have been > thinking about open-sourcing it, but it's kind of like letting > someone into your kitchen to watch you cook, and I'm kind of > nervous.)
It is like letting someone into your kitchen. If you enjoy cooking, you'll have good time. You'll chat about food. They may suggest some spices. They will taste your food while it's cooking and you can tell if they puke. ;) Far more satisfying than cooking by yourself and putting the food on the table.
If you decide to take the plunge, I wholeheartedly recommend hosting your project on launchpad.net. They give you space to host your code and excellent bug tracker. You don't have to do any busy-work administrative tasks (my trac is down, my disk is full, forgot to pay my isp, ...). And it's free of charge for free software.
You can look at the Ikarus page on launchpad to get a feel for how it's like.
Abdulaziz Ghuloum <aghul...@cee.ess.dot.indiana.dot.edu> writes: > Jay Reynolds Freeman wrote:
>> (1) I haven't released source code for the program. (I have been >> thinking about open-sourcing it, but it's kind of like letting >> someone into your kitchen to watch you cook, and I'm kind of >> nervous.)
> It is like letting someone into your kitchen. If you enjoy cooking, > you'll have good time. You'll chat about food. They may suggest some > spices. They will taste your food while it's cooking and you can tell > if they puke. ;) Far more satisfying than cooking by yourself and > putting the food on the table.
@JRF: I'll add that my initial reaction to your above sentiment was "...then what good is it?" Although I agree with your sentiment, since I'm working on my own projects that I want to take pretty far before releasing; however, you could be turning off a lot of people that might be able to really help you out.
No source code access really limits my ability to track down the key information I need to understand what's going on with any piece of software. This is one of the reasons I love Unix: if I'm confused about something, it's usually a shell-script that I can look directly at, or the source code is available online.
You're also putting all the responsibility for dealing with bug reports on yourself ;) But of course, let's see how I feel after I put myself in your shoes :P
Joel
-- Joel J. Adamson Biostatistician Pediatric Psychopharmacology Research Unit Massachusetts General Hospital Boston, MA 02114 (617) 643-1432 (303) 880-3109
Being open doesn't make it readable! Even having written it doesn't always make it readable ... It will take a lot of work, mostly by me, I suspect, before 30000 or 40000 lines of Scheme interpreter is well enough organized and has enough documentation about its internals for a stranger to it to find out something about how it works in a reasonable amount of time.
Meanwhile, I think it is my responsibility to provide documentation (several tens of thousands of words in the help files), field bug reports, and support those users that I have. (Not very many...)
Jay Reynolds Freeman <Jay_Reynolds_Free...@mac.com> writes:
> Being open doesn't make it readable!
No, but could it help make it readable? Perhaps others are better able to spot the difficult parts.
[...]
> Meanwhile, I think it is my responsibility to provide documentation > (several tens of thousands of words in the help files), field bug > reports, and support those users that I have. (Not very many...)
Sure, it's your responsibility, but if there's someone out there who's willing to help you, then that leaves you as an administrator while they're coding, and that delegation may be helpful so you can do more coding on other things.
> Did you have a particular question?
No, I just wanted to tell you my gut reaction when I saw that the source code wasn't available. If I wanted software without available source code, I would know where to go.
"Open source" and Free Software are two different things: making the source code available doesn't necessarily make it Open Source, i.e. mean that you have to be open to suggestions or accept changes by other people.
Joel -- Joel J. Adamson Biostatistician Pediatric Psychopharmacology Research Unit Massachusetts General Hospital Boston, MA 02114 (617) 643-1432 (303) 880-3109
On Dec 4, 6:32 am, jadam...@partners.org (Joel J. Adamson) wrote:
> No, but could it help make it readable? Perhaps others are better able > to spot the difficult parts.
I haven't run out of difficult parts that I can find all by myself ...
> Sure, it's your responsibility, but if there's someone out there who's > willing to help you, then that leaves you as an administrator while > they're coding, and that delegation may be helpful so you can do more > coding on other things.
Admin is no problem at present, not enough users, and (terrible secret) I rather enjoy documenting the code I have written. Besides, that helps *me* remember what it does.
> "Open source" and Free Software are two different things: making the > source code available doesn't necessarily make it Open Source, i.e. mean > that you have to be open to suggestions or accept changes by other > people.
Interesting distinction, well stated; I hadn't thought of it that way. But in either case, I suspect the source has to be at a reasonable level of organization and documentation before it is useful to provide it, and Wraith Scheme isn't there yet.
BTW, the reason why not is basically historical. Wraith Scheme is a direct descendent of Pixie Scheme, which I wrote on a Mac II in the late 1980s, for Macs. The open-source momement was in its infancy then, and I couldn't have gone open easily if it had been, for I had no Internet access at home where my computer was. But the real thing driving the organization was that Pixie Scheme was nearly as big as Wraith Scheme, and a full compile on a Mac II took a LONG time. So I developed the program as scores of small files and used Apple's "make" lookalike to build only the ones newly touched. (Nowadays I habitually rebuild the whole thing all at once, which takes under a minute on my Macbook.) Lots of small files is a bewildering organization to step into as a newcomer to the code (I have been there), kind of like the mazes in "Colossal Cave" aka "Adventure". Also, although the code is designed in what I believe I can describe as good object-oriented style, it was not written in an OO language -- Apple's C++ was not out yet -- it was written in pre-ANSI-standard C. (Since ported to C++, and most of the port was tightening up the code so that it compiled with no errors or warnings even when the compiler was set to show all possible warnings. Ah, self-discipline... ) (Much of the new stuff that I have added as enhancements to Wraith Scheme is class-based, and the Mac GUI stuff is in Objective C, which is a decent OO language although I have some objections to it on technical grounds.)
Furthermore, much of the code is written using an internal macro language that I developed. The heart of the Wraith Scheme interpreter is a virtual machine based on Henderson's SECD machine stuff (reference in the Wraith Scheme documentation). I implemented that in C for Pixie Scheme, then wrote the Scheme primitives in what looks like assembler for the virtual machine. That code looks like this:
MOVE( something, R ) ;; R is the VM's accumulator PUSH MOVE( something else, R ) ADD CONTINUE
(That was rudimentary code for an add.) When I compile, the C preprocessor expands that stuff into calls to C routines that manipulate data structures (like the SECD VM stack) that are not directly visible in the "assembler". So to document the code, I would have to document the details of the VM, and of the language, and any reader would have to learn them. I intend to do that, but what with the recent parallel enhancement, the VM is still somewhat a moving target.
Excuse my blathering, it is fun to talk about this stuff.
And anyone still reading is probably a likely victim \\\\\\ candidate to be involved in open-sourcing Wraith Scheme if and when I do so, so send me EMail and I will put your name on a little list ... (I am betting no one will send EMail!)
