Schematics

Noel Welsh wrote:

>My feeling is we can
>release SRFI updates more frequently than PLT Scheme
>updates come out, so there is still value in
>maintaining the Schematics collection.
>  
>

This reminds me. It would very useful to include the documentation
of the srfi in the helpdesk. I often find useful functions by searching
the helpdesk, and sometimes overlook srfi-functions.

I am however not quite sure, which document format is best for the
Helpdesk. Just including the html-pages from srfi.schemers.org wouldn't
be enough to make them searchable - or would it?

-- 
Jens Axel Søgaard

--- Jens_Axel_Søgaard <jensaxel@...> wrote:
> This reminds me. It would very useful to include the
> documentation of the srfi in the helpdesk.

Agreed.  I don't use SRFIs enough because the
documentation is missing.

> I am however not quite sure, which document format
> is best for the
> Helpdesk. Just including the html-pages from
> srfi.schemers.org wouldn't
> be enough to make them searchable - or would it?

Nope.  The two formats are HTML or text (doc.txt). 
For HTML you need to create an index and keywords
file.  The PLT guys use slatex and some custom macros
to do this.  We can probably get hold them - I did for
the SchemeUnit documentation but never got the OK to
include them in the Schematics CVS (I will try again).
 Alternatively we could use another docuementation
prep system (e.g. make SchemeDoc usable or build off
Mole/LAML etc.)  The doc.txt route is quicker - you
just to markup up the text the correct way but long
term I find HTML documentation nicer.

Cheers,
Noel

=====
Email: noelwelsh <at> yahoo <dot> com
Jabber: noelw <at> jabber <dot> org

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Neil W. Van Dyke wrote:

>=?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <jensaxel@...> writes at 14:56 04-Jun-2003 +0200:
>
>>I am however not quite sure, which document format is best for the
>>Helpdesk. Just including the html-pages from srfi.schemers.org wouldn't
>>be enough to make them searchable - or would it?
>>
>
>For a SRFI implementation I've been playing around with, seemed the
>easiest thing to do was to convert the SRFI HTML into a doc.txt file
>(see "plt/collects/help/doc.txt") using lynx/w3m/elinks and a little
>manual tweaking for the search feature.  Then added a note at the top
>saying that this is the SRFI standard doc adapted to be implementation
>docs, and prefixed each modified line (of implementation-specific notes)
>with "*** ".
>
That doesn't sound hard to do.

>A better but slightly harder way would be to convert the SRFI HTML to
>consistent least-common-denominator HTML (some SRFI authors get fancy
>with stylesheets and markup), make anchors for all the indexable
>keywords (perhaps with an "x-plt-index" attribute to say how to index
>it), and write a little program to generate Help Desk keyword index
>files from that.  Using HtmlPrag and Oleg's sxml-tree-trans or Kirill's
>stx-engine, you could probably automate the entire process for most all
>SRFIs.
>
And this even nicer.

>BTW, there's still ambiguity in the license, in which it's not clear you
>can adapt SRFI docs to be implementation docs.  IIRC, the legal question
>came down to: is documentation of the implementation necessary to
>implementing the SRFI.  I decided to not worry about it, but I can
>imagine corporate lawyers eyeing that suspiciously.
>
/The SRFI FAQ has the following:

   Doesn't the SRFI copyright notice contradict itself?/
    You're probably thinking of the sentence

        "However, this document itself may not be modified in any  way
        [...] except as needed for the purpose of developing SRFIs [...]"

    which might seem to contradict the answers to the previous
    questions. However, this sentence is only to prevent passing off a
    modified copy of the document as the document itself. So SRFI /x/ is
    an inviolable entity (and once finalized, very close to cast in
    amber). But you can excerpt from it at will, with attribution. (We
    have actually consulted with several lawyers on this; it is what we
intended, and it is what it means.)

So I think you are right not to worry too much. Marking alterations in e.g.
another color would probably be ok.

-- 
Jens Axel Søgaard

=?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <jensaxel@...> writes at 14:56 04-Jun-2003 +0200:
> I am however not quite sure, which document format is best for the
> Helpdesk. Just including the html-pages from srfi.schemers.org wouldn't
> be enough to make them searchable - or would it?

For a SRFI implementation I've been playing around with, seemed the
easiest thing to do was to convert the SRFI HTML into a doc.txt file
(see "plt/collects/help/doc.txt") using lynx/w3m/elinks and a little
manual tweaking for the search feature.  Then added a note at the top
saying that this is the SRFI standard doc adapted to be implementation
docs, and prefixed each modified line (of implementation-specific notes)
with "*** ".

A better but slightly harder way would be to convert the SRFI HTML to
consistent least-common-denominator HTML (some SRFI authors get fancy
with stylesheets and markup), make anchors for all the indexable
keywords (perhaps with an "x-plt-index" attribute to say how to index
it), and write a little program to generate Help Desk keyword index
files from that.  Using HtmlPrag and Oleg's sxml-tree-trans or Kirill's
stx-engine, you could probably automate the entire process for most all
SRFIs.

One overengineering way would be to convert all SRFIs to rich XML, and
have a DTD for describing SRFI implementations wrt the SRFI standard.

BTW, there's still ambiguity in the license, in which it's not clear you
can adapt SRFI docs to be implementation docs.  IIRC, the legal question
came down to: is documentation of the implementation necessary to
implementing the SRFI.  I decided to not worry about it, but I can
imagine corporate lawyers eyeing that suspiciously.

-- 
                                             http://www.neilvandyke.org/

On Wednesday, June 4, 2003, at 08:46  AM, Noel Welsh wrote:

> I'm now back from holiday.  I'm CCing the Schematics
> dev list as several others hack on Moshi (let me know
> if the formatting is messed up and I'll forward it).
> I want their ok before I commit this patch.  You might
> want to join the project and then you can hack to your
> heart's delight.

What does this involve?  Strange initiation rites, animal sacrifice, 
etc?

>> Also, have you considered removing the SRFI project
>> from schematics,
>> now that it's a part of the PLT distribution?
>
> Francisco is the man for this.  My feeling is we can
> release SRFI updates more frequently than PLT Scheme
> updates come out, so there is still value in
> maintaining the Schematics collection.

There's a synchronization issue there.  For instance (and perhaps I 
shouldn't have done this), I fixed a PR that we got (#6299) involving 
calls to check-arg that didn't have a symbol as their third argument.  
I committed and exp-tagged the change in the PLT tree, but that won't 
find its way into the schematics tree.

Also, is there a SRFI test suite that I should know about?

Also, I'm attaching the file moshimarkup.ss, because yes, line wrapping 
did mess up the diff something awful.  There are more robust versions 
of diff out there, aren't there?


john

--- John Clements <clements@...> wrote:
> What does this involve?  Strange initiation rites,
> animal sacrifice,  etc?

Well you can do that if you want, but generally we
stick getting a Sourceforge account and then letting
one of the admins know your username.

> There's a synchronization issue there.  For instance
> (and perhaps I shouldn't have done this), I fixed a 
> PR ...

Eeek!  I can't think of a good solution to this.

> Also, is there a SRFI test suite that I should know
> about?

There are test suites for individual SRFIs where the
author has created them.
 
> Also, I'm attaching the file moshimarkup.ss

Ta.  I'll apply it.

Noel

=====
Email: noelwelsh <at> yahoo <dot> com
Jabber: noelw <at> jabber <dot> org

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Noel Welsh <noelwelsh@...> writes:

>> There's a synchronization issue there.  For instance
>> (and perhaps I shouldn't have done this), I fixed a 
>> PR ...
>
> Eeek!  I can't think of a good solution to this.

No, there is no perfect solution I'm afraid.  I was trying to keep in
synch (manually) both trees, and most people here with write access to
both trees could do the same.  CVS however has found a way to break my
hard links, and so, every now and then I have to (almost) get rid of
one tree, make new hard links to the other, and then commit.

How nasty is that? :-{

I would vote to only maintain one of the two, the one in the PLT tree
sounds good to me.

--Francisco

Francisco Solsona <solsona@...> wrote:
> I would vote to only maintain one of the two, the one in the PLT tree
> sounds good to me.

Most people won't be able to check in their changes then, will they?
Can we persuade PLT to start using arch?  ;-)

MJ Ray wrote:
> Francisco Solsona <solsona@...> wrote:
> 
>>I would vote to only maintain one of the two, the one in the PLT tree
>>sounds good to me.
> 
> 
> Most people won't be able to check in their changes then, will they?
> Can we persuade PLT to start using arch?  ;-)

This is a bit off-topic but what revision control systems are other 
developers using? CVS is so infuriating that I'm willing to throw away 
our current build structure to incorporate a more modern RCS. The two 
I've heard most about are subversion and arch; pros and cons? Anything 
else to consider?

I know nothing about the pros&cons of SRFIs being bundled with PLT, but
a possibly relevant note:  The forthcoming PLaneT networked package
repository (or whatever it'll be called) might make unbundled packages a
lot more practical than they currently are.

-- 
                                             http://www.neilvandyke.org/

On 2003-06-05 00:09:22 +0100 Bruce Butterfield <bab@...> 
wrote:
> This is a bit off-topic but what revision control systems are other 
> developers using?

Here's my 10000m summary:

subversion - tries to be a "better cvs" AFAICT, which makes me 
suspicious.  When I tried it last year, the repository grew to be 
large and reports elsewhere made me think that was common, but an 
Apache developer since pointed me to docs about how to keep the size 
down.  Seemed to assume a "central repo" model, rather than multiple 
trees.

aegis - includes a test system, which can be a big win, but has some 
things that just make it too niggly over time for me to use: eg, 
nuking the working directory after each change is in the mainline; or 
rather weak support for network operation (but hey, cvs network 
operation was a bolt-on).  I'm told it can act as a local tool for 
managing cvs-based development, but I never really succeeded for any 
time.

prcs - more or less a better cvs again and easier than aegis when you 
don't want testing, but lots of bolt-ons available to do things like 
cool graphs, web frontends and nearly do networked operation properly 
(some kludging with rsync was needed).  Could be good next version.

meta-cvs - tries to abstract the filenames to remove some of the 
problems with CVS, but I think it's still not ACID.

arch - Tom Lord seems to have come up with the goods on this one.  
Seems a very good fit for the reality of free software development 
across the internet.  Based around a changeset format that is sort of 
"patch with knobs on" handling moves, binary files, etc.  Can 
interoperate a bit with CVS.  Reports of an XFree86 fork using this 
without too many problems.  Has at least two main forks (larch and 
ArX) and many smaller ones.  Other implementations slowly being 
written.  Mostly documented, but incompletely so.  Yes, I'm slowly 
trying to write a scheme implementation, in mzscheme at first.  I 
still need to use it more, though, as I thought I'd found the right 
answer before (see above).

Feel free to ask questions and I'll try to answer.

-- 
MJR/slef   My Opinion Only and possibly not of any group I know.
      http://mjr.towers.org.uk/   jabber://slef@...>
Creative copyleft computing services via http://www.ttllp.co.uk/
       Thought: "Changeset algebra is really difficult."

Has anyone looked at darcs ( http://abridgegame.org/darcs/ )? I think I
first saw it mentioned on the Lambda the Ultimate site, via sweetcode.org.

Even if you're not interested in trying yet another version control system,
its intro page is worth a read:
http://abridgegame.org/darcs/manual/node2.html

It's implemented in Haskell (!) and is based on a "theory of patches":
http://abridgegame.org/darcs/manual/node7.html

  "From the beginning of this theory, which originated as the result of a
series of email discussions with Tom Lord, I have looked at patches as being
analagous to the operators of quantum mechanics.  I include in this appendix
footnotes explaining the theory of patches in terms of the theory of quantum
mechanics."

This isn't as wacky as it might sound: the basics of the author's theory of
patches is pretty simple and sensible (and doesn't need any quantum
mechanics knowledge!)  The theory results in some interesting properties.
Quoting/summarizing some more:

* darcs' distribution system is strongly inspired by that of arch
* Every copy of your source code is a full repository
* Each copy of the source is a fully functional branch
* darcs patches have a set of properties, which make possible manipulations
that couldn't be done in other revision control systems:
   * Every patch is invertible.
   * Sequential patches (i.e. patches that are created in sequence, one
after the other) can be reordered, although this reordering can fail, which
means the second patch is dependent on the first.
   * Patches which are in parallel (i.e. both patches were created by
modifying identical trees) can be merged, and the result of a set of merges
is independent of the order in which the merges are performed. This last
property is critical to darcs' philosophy, as it means that a particular
version of a source tree is fully defined by the list of patches that are in
it. i.e. there is no issue regarding the order in which merges are
performed.

I haven't used darcs myself, but it certainly sounds interesting.  I have no
idea how stable or full-featured it is.

Anton

On 2003-06-05 02:21:53 +0100 Anton van Straaten 
<anton@...> wrote:

> Has anyone looked at darcs ( http://abridgegame.org/darcs/ )? I think 
> I
> first saw it mentioned on the Lambda the Ultimate site, via 
> sweetcode.org.

Yes.  It has some nice features (the email receiver, for example), but 
the decisions to not build on existing tools such as diff and patch 
and to offer "Token Replace" patches alienated me. I'm also 
unconvinced by his theory of patches, but I've not spent enough time 
analysing it to offer a proper rebuttal. One reason I'm reimplementing 
arch is to understand the set theory behind changeset creation. I 
think changesets are probably function applications and I'm trying to 
build a rigourous description of how that function is defined from the 
original sets.

There are a couple of large unanswered questions from the darcs docs: 
how are binary files handled (because hunk replacement may not be 
sensible) and how does it stop manual specification of dependencies 
causing unresolvable situations?

OK, while we're off up this sideline, does anyone here know of a tool 
to merge .rej files into a cvs-style file with conflict blocks?

-- 
MJR/slef   My Opinion Only and possibly not of any group I know.
      http://mjr.towers.org.uk/   jabber://slef@...>
Creative copyleft computing services via http://www.ttllp.co.uk/
       Thought: "Changeset algebra is really difficult."

Neil W. Van Dyke <neil@...> wrote:
> [...]  The forthcoming PLaneT networked package repository 

Do we know the current state of this?

I've been given R5RS code for a simple lexical module (ie no macro
exports across module boundaries) which would make a multi-implementation
networked package repository viable.  Would that be possible within
schematics, or would that be a new project in itself?

-- 
MJR/slef   My Opinion Only and possibly not of any group I know.
      http://mjr.towers.org.uk/   jabber://slef@...>
Creative copyleft computing services via http://www.ttllp.co.uk/
       Thought: "Changeset algebra is really difficult."

I've checked in some changes to schemerss.  This fixes the remove channel
bug I mentioned last week.  I've also moved the html rendering code out of
the rssparser module, into a new module named rsshtmlview.  Other than the
bugfix, the functionality of the application should be unchanged.

However, the rssparser module can now be used as a general purpose library
for reading rss channels, which I've documented very briefly (and without
following any doc conventions, yet) in doc.txt.

As an aside, this means that schemerss is no longer only an "app" - it's
also a library, so strictly speaking, at least part of it is now in the
wrong cvs directory :)  The library modules are rsscomm, rssconfig and
rssparser.  The app modules are rssservlet, addchannel, rsshtmlview.

A summary of the changes follows:

* rsscomm: moved url->filename to rssconfig, to support updated
get-channel-file-list
* rssconfig: modified get-channel-file-list to return filenames in same
order as urls appear in config file - fixes the "remove channel" bug.
* rssparser:
  * refactored html rendering code into rsshtmlview - included removing some
view-specific parameters from functions like process-channel, process-rss.
  * changed process-channel to return an rss-channel struct, instead of
calling display-channel, to support other uses.
  * renamed process-rss to sxml->rss-channel, since it now returns an
rss-channel struct, via process-channel.
  * implemented set of read-rss-channel functions to read an rss channel
from a port, file, url struct, or url string.
* rsshtmlview: changed rss->html to use read-rss-channel-from-file
* rssservlet: changed to require rsshtmlview instead of rssparser

Feel free to change anything, of course.

I haven't yet checked in my code to monitor an rss channel and send
notifications when new items are detected.  I originally tried to develop
this the lazy way, using a thread per channel being monitored, but I ran
into a bug in multithreaded use of MzScheme's tcp-connect, on Windows.
(I've posted a fix to PLT list.)  I now need to either add some
code to work around this bug until the MzScheme fix is integrated, or change
the logic to avoid threads.  I'll check something in next week.

Anton

Anton van Straaten wrote:
> I've checked in some changes to schemerss.  This fixes the remove channel
> bug I mentioned last week.  I've also moved the html rendering code out of
> the rssparser module, into a new module named rsshtmlview.  Other than the
> bugfix, the functionality of the application should be unchanged.
>
Terrific - thanks for your updates! I'm going to put a new release (0.2) 
out with just your changes. The only major functional addition I have 
been planning on in the near term is a "channel finder" using 
syndic8.com or something else. Combined with your channel monitoring 
code it should be worthy of a 1.0 release. Past that, I could see 
incorporating user-defined stylesheets for the rendering. Anything else 
that might make it more usable?

I agree that your refactoring really means that files need to move 
within the repository making it more obvious that there is reusable 
library functionality in there. Of course this is so easy with CVS...

--- MJ Ray <markj@...> wrote:
> Do we know the current state of this?

I believe someone is working on it over the summer. 
Posting to plt-scheme is the best way to get this
question answered.
 
> I've been given R5RS code for a simple lexical
> module (ie no macro
> exports across module boundaries) which would make a
> multi-implementation
> networked package repository viable.  Would that be
> possible within
> schematics, or would that be a new project in
> itself?

The portable syntax-case system has a module system
that works for some definition of works (for me,
meaning "doesn't work".  *cough* Tony? ;-)

Schematics is for whatever people do with it.  Go
wild.

Noel

=====
Email: noelwelsh <at> yahoo <dot> com
Jabber: noelw <at> jabber <dot> org

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Bruce Butterfield wrote:
> Terrific - thanks for your updates!

I appreciate having the code base to start with, and I'm glad to be able to
help!  If it weren't for schemerss, I'd probably be using... Perl
(*shudder*)

> I'm going to put a new release (0.2) out with just your changes.
> The only major functional addition I have been planning on in the
> near term is a "channel finder" using syndic8.com or something
> else. Combined with your channel monitoring code it should be
> worthy of a 1.0 release. Past that, I could see incorporating
> user-defined stylesheets for the rendering. Anything else that
> might make it more usable?

I added a point 6 to the list of notes in doc.txt, which I think is fairly
important for usability: "After an operation like reload or add is
performed, the URL in the browser is such that a refresh will repeat the
operation.  This should probably be fixed using an HTTP redirect to the main
page after an operation has been performed."  That should be fairly minor to
implement.

Dealing with points 4 & 5 in that list would also improve usability.

Re point 4, "No easy way to remove bad or broken RSS URLs from configuration
other than by hand editing rss-config", I think it could make sense to
continue in the direction I took to fix the Remove Channel issue: make the
code work more directly from the configured channel list, rather than
whatever files are available in the channel data directory.  When displaying
a channel for which the download fails, or the cached data is bad, a stub
header could be displayed with an error message and the usual Remove Channel
link.

I may tackle some of that as I move forward with the monitoring code, but
just let me know if you're planning to work on anything, and I'll leave it
alone.

To support my channel monitoring code, I'd like to have some way of
specifying per-channel parameters, such as a polling interval.  There's
already a global refresh time, but if a frequently changing channel is being
monitored, you might want to poll that channel more frequently than some
other channels allow.

The notification side will also need separate parameters, like email
configuration parameters, etc.  So far, I have most of that hardcoded - I'll
post more when I get to the point of parameterizing it.

> I agree that your refactoring really means that files need to move
> within the repository making it more obvious that there is reusable
> library functionality in there.

The only thing stopping from wanting to do this right now is that the config
code is still multi-purpose: it supports both the web view and the library
code.  The latter depends on some rssconfig functions related to caching
channel data, even though it doesn't need the list of channels to be
monitored.  My monitoring code will add additional requirements here.  So, I
plan to propose some config changes and refactoring, when I've figured out
what those should be...

> Of course this is so easy with CVS...

At least it's not so bad this early in the project.

Anton

Noel Welsh <noelwelsh@...> wrote:
> The portable syntax-case system has a module system
> that works for some definition of works (for me,
> meaning "doesn't work".  *cough* Tony? ;-)

Is this part of schematics cvs somewhere?

-- 
MJR/slef   My Opinion Only and possibly not of any group I know.
      http://mjr.towers.org.uk/   jabber://slef@...>
Creative copyleft computing services via http://www.ttllp.co.uk/
       Thought: "Changeset algebra is really difficult."

MJ Ray wrote:
> Noel Welsh <noelwelsh@...> wrote:
> > The portable syntax-case system has a module system
> > that works for some definition of works (for me,
> > meaning "doesn't work".  *cough* Tony? ;-)
>
> Is this part of schematics cvs somewhere?

I assume Noel's referring to this:
http://www.cs.indiana.edu/chezscheme/syntax-case/

One Scheme implementation that seems to successfully use modules via this
system is SISC, as described here:
http://sisc.sourceforge.net/manual/html/ch10.html

Documentation of the module system is here:
http://www.scheme.com/csug/syntax.html#g2187

I understand how this can be used to add syntax-rules+case macros and
modules to a Scheme implementation that doesn't already have them.  Can it
be used as a standalone module system, though, in a Scheme that already has
its own macros?  I don't know anything about it in that respect.

--- John Clements <clements@...> wrote:
> Also, I'm attaching the file moshimarkup.ss, because
> yes, line wrapping  did mess up the diff

I've commited this change now.  

> There are more robust versions 
> of diff out there, aren't there?

Dunno, not really my area.

Cheers,
Noel

=====
Email: noelwelsh <at> yahoo <dot> com
Jabber: noelw <at> jabber <dot> org

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com