Eli Barzilay | 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
additional keyword arguments:

  * #: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"
                     #:select-match cadr)
  '("0" #f "1" "*" "2")

(Continue reading)

Ryan Culpepper | 2 Jan 07:34 2012
Picon

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

J. Ian Johnson | 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

Robby Findler | 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
(Continue reading)

Jay McCarthy | 5 Jan 03:55 2012
Picon

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
(Continue reading)

Robby Findler | 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.
(Continue reading)

Neil Toronto | 8 Jan 00:48 2012
Picon

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

Ryan Culpepper | 8 Jan 01:52 2012
Picon

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

Eli Barzilay | 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

Neil Toronto | 9 Jan 06:03 2012
Picon

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.

(Continue reading)


Gmane