Wraith Scheme 1.30 released (for Macintosh); does parallel processing
Jay Reynolds Freeman
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:
Main website: http://web.mac.com/jay_reynolds_freeman
Software page: http://web.mac.com/jay_reynolds_freeman/iWeb/My/Software.html
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 Freeman
---------------------
Jay_Reynol...@mac.com
http://web.mac.com/jay_reynolds_freeman (personal web site)
Jason
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?
-Jason
Jay Reynolds Freeman
> 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 Freeman
---------------------
Jason
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. :)
-Jason
Jay Reynolds Freeman
> 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
---------------------
Abdulaziz Ghuloum
> (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.
Main page: http://launchpad.net/ikarus
Bugs summary: http://bugs.launchpad.net/ikarus
Repository: http://code.launchpad.net/~aghuloum/ikarus/ikarus.dev
Milestones: http://launchpad.net/ikarus/+milestone/0.0.2
But again, it's your choice. Good luck.
Aziz,,,
Joel J. Adamson
> 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
Jay Reynolds Freeman
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...)
Did you have a particular question?
I hope my on-line help files are useful ...
-- Jay Freeman
Joel J. Adamson
> 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.
Jay Reynolds Freeman
> 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!)
-- Jay Reynolds Freeman
Jay_Reynol...@mac.com
http://web.mac.com/jay_reynolds_freeman
Jason
> http://web.mac.com/jay_reynolds_freeman
It's your baby, Jay. Don't feel compelled to do *anything* with the
source code that does not make you comfortable. Not everything needs
to be open sourced, you know... :P
-Jason
Joel J. Adamson
> 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 ...
I know what you mean. Well, I wish I knew better what you mean.
>> "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.
It's a tricky one that tripped me up at first: I read an essay in which
RMS said "we [FSF] do not support the Open Source movement." RMS
phrases it in terms of philosophy (of course): open source is a
development paradigm and free software is an ideology. It took me a
while to realize that this is practical, rather than a philosophical
difference. As with many of these distinctions, Eric S. Raymond states
things quite clearly in his books. Emacs (free software) is developed
very differently from Linux (open source), as I understand it.
I would like my own projects to be free software because (a) I value the
ethical position of free software, and (b) I find free software the most
useful. This is after years of using free software without knowing it,
then years of frustration using proprietary software and then explicity
discovering free software. I find it most useful because examining
source code is very useful to someone learning programming (like
myself). You however sound many years more experienced ;)
However, I agree that not everything should be open source or free
software. Matlab, for instance, should stay proprietary and expensive
in order to keep people from using it ;)
> 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.
Yes, I agree. It should be comprehensible, and you could potentially
waste a lot of time explaining things to people if you're not clear in
the first place.
Thanks for blathering, I enjoyed reading it.
Abdulaziz Ghuloum
I disagree. :-) If Jay wants to release his baby, I don't think
he should waste a lot of time documenting every little detail in
his code. That would be extremely boring and counter-productive.
Not everybody needs to understand every little detail in the code.
I do agree though that the code has to have some reasonable level
of organization. I would assume that he already has some level
of organization to manage his 30-40 KLOC, otherwise, he would've
been dead in the water long time ago. If the code is in a really
bad shape, then true, maybe he should be cleaning his act anyways
regardless of whether he's releasing the source or not. Picking
the right names for files, module, functions, and some variables
goes a long way. Making the code clear and readable is far better
than writing documentation about how the code is supposed to work.
Also, don't underestimate how smart people are.
Just my opinion.
Aziz,,,
Abdulaziz Ghuloum
> 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!)
I bet you're right. No one will send email. You know why?
It's up to *you* to take the initiative, not them. The way
it works is this:
- First you release it,
- then they look, peek, examine (e.g. make you nervous),
- then they get involved [*].
Oh well, maybe you should keep Wraith locked in its cage,
lest it mingles with the neighborhood cats :-)
Aziz,,,
[*] I know that sounded like a mating ritual.
Tony Garnock-Jones
> 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
I see it differently. In general,
Case 1: the binary is available.
Case 2: the binary is available. Poorly-organised, poorly documented
source is available.
Case 3: the binary is available. Well-organised, well-documented source
is available.
Case 3 is the most useful to the unhappy developer having to find and
solve some issue with the piece of software. Case 2 is less useful, but
still far, far more useful than case 1, because it doesn't force the
developer to disassemble, reconstructing variable names etc as he/she
goes, or simply to give up.
Providing source, no matter how poorly organised, is *always* valuable.
Regards,
Tony
(PS: This is a general point, and not specifically addressed at you,
although should you wish to buy in to the idea for Wraith, then so much
the better :-) )
(PPS: For an illustration of the value of the source, no matter how
awful, take a look at how much Reflector.NET is used by CLR developers
to decipher Microsoft's class libraries...)
Jay Reynolds Freeman
<you.can.find.me.thro...@google.easily> wrote:
> (PPS: For an illustration of the value of the source, no matter how
> awful, take a look at how much Reflector.NET is used by CLR developers
> to decipher Microsoft's class libraries...)
All the comments on this thread have been fascinating for me
to read, and are much appreciated. I guess I have been blindsided
by having the privilege of working with code that is generally
pretty good and/or source that is pretty poor. Even when using
code for which source and documentation were available, I have
rarely had to go into it, and when I have, I have rarely found
that I could learn anything useful in a reasonable time. (My
pet bad memory here is doing a calls tree of a big undocumented
Fortran-66 data-compression package by hand, from a listing,
back in what some people have the temerity to call "the good old
days".) (And if you don't know what Fortran-66 was like,
you are much the better for it, and probably also much saner.)
I will strive toward getting Wraith Scheme's internals into
good enough shape that I can release the source without
feeling embarrassed. I acknowledge the point that any source
is better than none, but I embarrass easily, particularly
about my own work. :-) I hope my standards will be adequate.
But the program is a moving target still, so don't hold your
breath. And I stand by my word to help anyone who is curious
understand anything he or she needs to know about how the
program works; the administrative load at present is low
enough that that is no problem.
Once again, love the advice! How nice to have smart people
telling me where to go ... :-)
Joel J. Adamson
> On Dec 7, 2:57 am, Tony Garnock-Jones
> <you.can.find.me.thro...@google.easily> wrote:
>
>> (PPS: For an illustration of the value of the source, no matter how
>> awful, take a look at how much Reflector.NET is used by CLR developers
>> to decipher Microsoft's class libraries...)
>
[...]
> But the program is a moving target still, so don't hold your
> breath.
[...]
The best software is made by people who acknowledge that this is true of
their software, and I consider it logical for *all* software (see "The
Cathedral and the Bazaar").