[report] 7/26

[Ryan Schwers]

Hi all!

Today we fixed up the references to list-sort, which should have been
sort-list. The contract for sort-list is the same as srfi-32's, (sort
list <).
This also matches the code. There were also some small changes that
needed to be made to the edwin:mode interface.

Currently we're running into an issue while attempting to load our
edwin:fundamental structure (in order to get a mode working).
The code references char-set functions, such as CHAR-SET:GRAPHIC and
ASCII-RANGE->CHAR-SET, any thoughts?
Would this be something worth porting?

--
-- Ryan Schwers

[Duncan Mak]

On Mon, Jul 26, 2010 at 3:46 PM, Ryan Schwers <xerxs...@gmail.com> wrote:

Currently we're running into an issue while attempting to load our
edwin:fundamental structure (in order to get a mode working).
The code references char-set functions, such as CHAR-SET:GRAPHIC and
ASCII-RANGE->CHAR-SET, any thoughts?
Would this be something worth porting?

CHAR-SET:GRAPHIC is part of SRFI-14 - http://srfi.schemers.org/srfi-14/srfi-14.html#char-set:graphic

It might be possible to replace MIT Scheme procedure ASCII-RANGE->CHAR-SET procedure with UCS-RANGE->CHAR-SET from SRFI-14:

— procedure: ascii-range->char-set lower upper

Lower and upper must be exact non-negative integers representing ISO-8859-1 character codes, and lower must be less than or equal to upper. This procedure creates and returns a new character set consisting of the characters whose ISO-8859-1 codes are between lower (inclusive) and upper (exclusive).

For historical reasons, the name of this procedure refers to “ASCII” rather than “ISO-8859-1”.

ucs-range->char-set  lower upper [error? base-cs] -> char-set

ucs-range->char-set! lower upper error? base-cs -> char-set

Lower and upper are exact non-negative integers; lower <= upper.

Returns a character set containing every character whose ISO/IEC 10646 UCS-4 code lies in the half-open range [lower,upper).

• If the requested range includes unassigned UCS values, these are silently ignored (the current UCS specification has "holes" in the space of assigned codes).
• If the requested range includes "private" or "user space" codes, these are handled in an implementation-specific manner; however, a UCS- or Unicode-based Scheme implementation should pass them through transparently.
• If any code from the requested range specifies a valid, assigned UCS character that has no corresponding representative in the implementation's character type, then (1) an error is raised if error? is true, and (2) the code is ignored if error? is false (the default). This might happen, for example, if the implementation uses ASCII characters, and the requested range includes non-ASCII characters.

If character set base-cs is provided, the characters specified by the range are added to it. ucs-range->char-set! is allowed, but not required, to side-effect and reuse the storage in base-cs; ucs-range->char-set produces a fresh character set.

Note that ASCII codes are a subset of the Latin-1 codes, which are in turn a subset of the 16-bit Unicode codes, which are themselves a subset of the 32-bit UCS-4 codes. We commit to a specific encoding in this routine, regardless of the underlying representation of characters, so that client code using this library will be portable. I.e., a conformant Scheme implementation may use EBCDIC or SHIFT-JIS to encode characters; it must simply map the UCS characters from the given range into the native representation when possible, and report errors when not possible.

--
Duncan.

[Duncan Mak]

On Mon, Jul 26, 2010 at 3:46 PM, Ryan Schwers <xerxs...@gmail.com> wrote:

Hi all!

Today we fixed up the references to list-sort, which should have been
sort-list. The contract for sort-list is the same as srfi-32's, (sort
list <).

I'm trying to review and apply this patch series, but I'm missing files so they don't apply on top of my local tree. Could you cook up another patch series to bring me up to speed?

I don't understand this change from LIST-SORT to SORT-LIST - SRFI-32 is a withdrawn SRFI, so it's not really something that we need to follow. I tried opening the 'sorting' package and I can't find a definition of SORT-LIST either - where is it defined?

I looked at the R6RS specification, and they seem to have converged on (sort proc list/vec) so I think we should stay with that [1]. I just made a pass through the source tree and cleaned up all references to SORTs to have the same form as R6RS.

I'm attaching the patch, if that works out, it'd be best if you could have your upcoming patch series be rebased on top of this commit - that way, everything can be applied easily.

Thanks.

[1] http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-5.html#node_chap_4

--
Duncan.

[Duncan Mak]

On Tue, Jul 27, 2010 at 12:05 PM, Duncan Mak <dunc...@gmail.com> wrote:

I'm attaching the patch, if that works out, it'd be best if you could have your upcoming patch series be rebased on top of this commit - that way, everything can be applied easily.

Of course, I forgot to attach the patch, and GMail didn't warn me...

--
Duncan.

[Ryan Schwers]

We had originally gone with (sort-list list <) because it's from
srfi-32 and Professor Shivers suggested we look there. SORT-LIST is
provided by
the 'sort' package.

We can redo the patches and current work with the argument fix.

--
Ryan Schwers

[Ryan Schwers]

This should be a complete set of patches, we added the main git
repository from a-chinaman.com as a remote and did format-patch
against it.

Jim has edwin:button in progress and that should take care of those
missing variables from edwin:fundamental.
--
Ryan Schwers

[Duncan Mak]

I have applied and pushed your patch series - thank you much.

Here are some changes I made:

1. I squashed the two commits that changed the mode interface into one commit.
2. I removed the unnecessary references to the 'sort' module.
3. I rewrote the commits so the Crewbie name doesn't show up anymore. When committing on bigtv, please remember to specify --author.
4. I rewrote a commit message to fix a typo (char-set:numeric -> char-set:digit, not char-set:graphic)

In the future, repeating what Olin said on Saturday, please check your patches and minimize changes to whitespace. If you really got to do it, split it out into a separate commit. As an example, the mode commits were tricky to review - I had missed the one crucial line because it was "hidden" among all the (frivolous?) line-ending changes.

  

Thanks again,

--
Duncan.