1 Jan 19:07 2012

### regexp-explode' etc + poll

I've implemented a new regexp-explode' function.  It accepts the same
arguments as regexp-match*' and regexp-split', but with two

* #:select-match

If this is #t (the default) then the result includes the lists of
results from the sub-matches.  It can also be #f to not include
them, and it can be a "selector function" that chooses a specific
one (eg, car' etc) or return a different list of matches (eg,
cdr').

* #:select-gap

This is just a boolean flag -- if it's #t (the default), the
strings between the matches are returned as well -- interleaved
with the (lists of) matches, otherwise they're omitted.

So by default, you get the information that regexp-split' returns,
interleaved with the full results of matching.  Examples:

-> (regexp-explode #rx"[^0-9]([^0-9])?" "0+1.*2")
'("0" ("+" #f) "1" (".*" "*") "2")
-> (regexp-explode #rx"[^0-9]([^0-9])?" "0+1.*2"
#:select-match car #:select-gap #f)
'("+" ".*")
-> (regexp-explode #rx"[^0-9]([^0-9])?" "0+1.*2"
'("0" #f "1" "*" "2")

2 Jan 07:34 2012

### Release for v5.2.1 is about to begin

The release process for v5.2.1 will begin in about a week.  If
you have any new features that you want in and are relatively close
to being done, now is a good time to do that.
--

--
Ryan Culpepper
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev

4 Jan 16:31 2012

### [scribble] Unicode in exact-chars elements

I've been writing a paper in scribble, dropping to LaTeX every so often to write in native math mode. I notice
that unicode characters don't show up. I've ripped off display-protected from latex-render.rkt,
removed the latex command syntax escaping (so I can have backslashes, underscores and carets) and every
time I have a new unicode character I want to use, I have to add to the big case expression. I then translate
all elements before putting them in the exact-chars element. I don't know how to wrap delayed and
part-relative elements, but I haven't needed to yet.

What's worse is that I have to do a 1 character look-ahead for composing characters such as \hat{#1} and
\tilde{#1} (\u0302 \u0303).
This is getting tiring, and from a short Googling I found that we could be using XeTeX as the backend instead
to get direct unicode support. Are there plans for a XeTeX backend? I'm not sure how much work that would be
as I don't know the subtle differences between it and LaTeX.

I'll keep doing my dispatching for now, I'm just curious.
Thanks,
-Ian
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev

4 Jan 17:08 2012

### Re: [scribble] Unicode in exact-chars elements

I think you could find out how far away we are from that by using
'scribble --latex' and then running xetex on the output file. You may
be lucky and we may be close....

Robby

On Wed, Jan 4, 2012 at 9:31 AM, J. Ian Johnson <ianj <at> ccs.neu.edu> wrote:
> I've been writing a paper in scribble, dropping to LaTeX every so often to write in native math mode. I
notice that unicode characters don't show up. I've ripped off display-protected from
latex-render.rkt, removed the latex command syntax escaping (so I can have backslashes, underscores
and carets) and every time I have a new unicode character I want to use, I have to add to the big case
expression. I then translate all elements before putting them in the exact-chars element. I don't know
how to wrap delayed and part-relative elements, but I haven't needed to yet.
>
> What's worse is that I have to do a 1 character look-ahead for composing characters such as \hat{#1} and
\tilde{#1} (\u0302 \u0303).
> This is getting tiring, and from a short Googling I found that we could be using XeTeX as the backend instead
to get direct unicode support. Are there plans for a XeTeX backend? I'm not sure how much work that would be
as I don't know the subtle differences between it and LaTeX.
>
> I'll keep doing my dispatching for now, I'm just curious.
> Thanks,
> -Ian
> _________________________
>  Racket Developers list:
>  http://lists.racket-lang.org/dev

_________________________
Racket Developers list:
http://lists.racket-lang.org/dev

5 Jan 03:55 2012

### PLAI - Manual management of closures

I've just pushed a new version of the GC language for PLAI that
requires students to manually manage their closures, rather than
treating them as "flat" values.

The code is tested (the entire normal GC test suite is ported) but I
have not yet pushed the documentation (to discourage early use and
confusion from students before we've figured out the best way to
present the issues.)

*** Why ***

In the first language, closures are treated as "flat" values, except
that they aren't really flat so students had to use the
'procedure-roots' function to discover any locations that the closure
held---i.e. its free identifiers. I have always found this really
cheap and I find that students are very confused by when they need to
use this function because it comes out of left field.

In this language, there are a few new functions the student must
implement:

gc:closure : code-ptr (vectorof location) -> location
gc:closure-code-ptr : location -> code-ptr
gc:closure-env-ref : location integer -> location
gc:closure? : location -> boolean

*** Implications ***

Closures represent a totally different kind of data structure for

5 Jan 04:05 2012

### Re: PLAI - Manual management of closures

I'm glad to see you doing this!

FWIW, I would have gone with 1. I would have explained it to the
students by saying that an earlier stage of the compiler must do this
and now primitives are a different kind of things than other
functions.

But not really have tried it, I agree 3 is the next best thing.

Robby

On Wed, Jan 4, 2012 at 8:55 PM, Jay McCarthy <jay.mccarthy <at> gmail.com> wrote:
>
> I've just pushed a new version of the GC language for PLAI that
> requires students to manually manage their closures, rather than
> treating them as "flat" values.
>
> The code is tested (the entire normal GC test suite is ported) but I
> have not yet pushed the documentation (to discourage early use and
> confusion from students before we've figured out the best way to
> present the issues.)
>
> *** Why ***
>
> In the first language, closures are treated as "flat" values, except
> that they aren't really flat so students had to use the
> 'procedure-roots' function to discover any locations that the closure
> held---i.e. its free identifiers. I have always found this really
> cheap and I find that students are very confused by when they need to
> use this function because it comes out of left field.

8 Jan 00:48 2012

### Icon issues resolved (almost)

I've pushed a change that removes DrRacket's dependence on
slideshow/pict' (via icons'), removes the icons' module, and adds a
new images' collection. Instead of precompiling SVGs, the new code
ray-traces floating-point ARGB+Z bitmaps; instead of composing icons
from picts, it composites floating-point renders.

Though the code itself no longer requires picts, I didn't update
meta/check-dists.rkt or meta/dist-specs.rkt. Doing so looked
*deceptively* simple, with comments marking the icons hack and
everything. Eli or Matthew, should I change those files, or let one of
you do it?

Neil T
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev

8 Jan 01:52 2012

### Re: Icon issues resolved (almost)

On 01/07/2012 04:48 PM, Neil Toronto wrote:
> I've pushed a change that removes DrRacket's dependence on
> slideshow/pict' (via icons'), removes the icons' module, and adds a
> new images' collection. Instead of precompiling SVGs, the new code
> ray-traces floating-point ARGB+Z bitmaps; instead of composing icons
> from picts, it composites floating-point renders.
>
> Though the code itself no longer requires picts, I didn't update
> meta/check-dists.rkt or meta/dist-specs.rkt. Doing so looked
> *deceptively* simple, with comments marking the icons hack and
> everything. Eli or Matthew, should I change those files, or let one of
> you do it?

I'll do it. The new collection also needs an entry added.

Ryan
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev

9 Jan 04:10 2012

### Re: Icon issues resolved (almost)

Yesterday, Neil Toronto wrote:
> I've pushed a change that removes DrRacket's dependence on
> slideshow/pict' (via icons'), removes the icons' module, and adds
> a new images' collection. Instead of precompiling SVGs, the new
> code ray-traces floating-point ARGB+Z bitmaps; instead of composing
> icons from picts, it composites floating-point renders.

So now there's no docs at all?

Also, an advantage of processing svg files would have been the ability
to use existing icons -- even if you've used some half-assed script to
translate them then it's probably better than nothing...  (Unless you
have some better way to do it.)

--

--
((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
http://barzilay.org/                   Maze is Life!
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev

9 Jan 06:03 2012

### Re: Icon issues resolved (almost)

On 01/08/2012 08:10 PM, Eli Barzilay wrote:
> Yesterday, Neil Toronto wrote:
>> I've pushed a change that removes DrRacket's dependence on
>> slideshow/pict' (via icons'), removes the icons' module, and adds
>> a new `images' collection. Instead of precompiling SVGs, the new
>> code ray-traces floating-point ARGB+Z bitmaps; instead of composing
>> icons from picts, it composites floating-point renders.
>
> So now there's no docs at all?

Correct, and there never will be. </sarcasm>

Truthfully, I just haven't ported the old ones yet. Perfection within a
reasonable epsilon will happen before the release. (You'll have to take
a limit to get actual perfection.)

> Also, an advantage of processing svg files would have been the ability
> to use existing icons -- even if you've used some half-assed script to
> translate them then it's probably better than nothing...  (Unless you
> have some better way to do it.)

The disadvantage is actually writing an SVG interpreter. When looking
into it, I discovered the reason there are so few, and why even those
are only partial. The committee of designers kitchen-sinked the file
spec, yielding a format that is easy to *write* but hard to *read*. It
would take me until next Christmas to write a partial implementation.

Now we know it's about 1/12 as hard to write a ray tracer for z maps
than an SVG interpreter. And knowing is half the battle.