gmane.lisp.scheme.plt.devel

Re: [racket-dev] Nit in Windows build files

Matthew Flatt — 2010-08-16T13:11:25

I changed the name in "libracket.vcproj".

At Mon, 16 Aug 2010 15:58:22 +1000, Paul Steckler wrote:

Re: [racket-dev] new release policy

Eli Barzilay — 2010-08-16T08:18:09

Side note: I read these as "seq n this, seq n that, ..." -- at least
to me, "seqn" works pretty badly as a shorthand for "sequence".

Re: [racket-dev] new release policy

Eli Barzilay — 2010-08-16T08:14:18

Yes to all of that, with an addition that IMO some 2x slower feature
is mostly something to improve, a 100x slowdown makes it a bug.


On Aug 13, Jay McCarthy wrote:

Obviously -- but getting there involves more work now.  (And until we
get there we have that buggy (IMO) code.)


On Aug 13, Jay McCarthy wrote:

I *did* make an alternative proposal (that didn't come with an
implementation).  And in fact that blog post was explicit about it
too.

Re: [racket-dev] new release policy

Eli Barzilay — 2010-08-16T07:58:00

I forgot the attachment.

[racket-dev] Nit in Windows build files

Paul Steckler — 2010-08-16T05:58:22

In last night's build, the Visual Studio solution file
src/worksp/racket/racket.sln contains the line:

  Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "libracket",
      "..\libracket\libracket.vcproj",  "{A6713577-7DFB-48F8-B8C1-7DB2D7C51F90}"

When you load that solution into VS2005, that project shows up as
`libmzsch', which is
confusing (and breaks some code I'm working on).

I think you just need to rename the project.

Re: [racket-dev] Code review tool

Eli Barzilay — 2010-08-15T08:04:07

There are several ways to achieve this, gerrit is one tool that is
getting popular, another is manual integration by a human (as done in
git, and as effectively done in plt during releases), and yet another
is a tool that picks up patches sent to a mailing list and stores them
in a place that is convenient to later merge.

All of these will make developement much harder, more so given the
high percentage of git newbies which will need to face an even more
complicated workflow.

[racket-dev] Code review tool

Vincent St-Amour — 2010-08-15T02:07:55

Last week at PLT day, there was some discussion about code review, and
how to potentially integrate it with our workflow.

I found the following tool which may help:

http://code.google.com/p/gerrit/

If I understand correctly, commits that are pushed don't go directly
to the main repository; instead, they go to an intermediate repo,
where any authorized user can approve them and push them to the main
repo.

Vincent

Re: [racket-dev] [DrDr] R20864 (timeout 1) (unclean 776)(stderr776) (changes 796)

Matthew Flatt — 2010-08-14T19:54:26

Hopefully fixed, now.

The problem is related to a new scheduler hook that GRacket2 uses.

Re: [racket-dev] [DrDr] R20864 (timeout 1) (unclean 776) (stderr776) (changes 796)

Jay McCarthy — 2010-08-14T17:25:04

The root of this problem is that "make install" didn't finish. Here's the log:

http://drdr.racket-lang.org/20864/src/build/make-install

It says:

attempted to wait for suspend in nested atomic mode
match: no matching clause for (list (list (cc '(#<path:tests>
#<path:stress> #<path:racket>)
#<path:/opt/plt/builds/<current-rev>/trunk/collects/tests/stress/racket>
"tests/stress/racket" #<procedure:info>
#<path:/opt/plt/builds/<current-rev>/trunk/collects>
#<path:/opt/plt/builds/<current-rev>/trunk/colle...
 === context ===
/opt/plt/builds/<current-rev>/trunk/collects/racket/match/runtime.rkt:19:0:
match:error
/opt/plt/builds/<current-rev>/trunk/collects/setup/parallel-do.rkt:102:69
/opt/plt/builds/<current-rev>/trunk/collects/setup/setup-unit.rkt:601:17: thunk
/opt/plt/builds/<current-rev>/trunk/collects/setup/setup-go.rkt: [running body]
/opt/plt/builds/<current-rev>/trunk/collects/setup/main.rkt: [running body]
attempted to wait for suspend in nested atomic mode
make[1]: *** [install-3m] Error 1
make[1]: Le

Re: [racket-dev] a pretty funny home page

Neil Van Dyke — 2010-08-14T13:11:59

At some big get-together of Racket developers and users, there should be 
a group photo, with everyone wearing black duster jackets and serious 
expressions.  Then label it with a logo: "League of Extraordinary 
Racketeers"

[racket-dev] a pretty funny home page

Shriram Krishnamurthi — 2010-08-14T12:52:54

Go to

http://sites.google.com/site/viktorwinschel/

then click on "Languages".

Re: [racket-dev] Possible P4P or Honu ideas

Shriram Krishnamurthi — 2010-08-14T12:10:05

I had suggested to me that P4P should become a reader.  That seems
pretty reasonable to me.  I went with the parser because it was easy
to implement; when I asked people how easy it would be to convert from
parser to reader, various people made various vague, slightly
non-committal noises.  But I'm investigating.

Shriram

[racket-dev] Possible P4P or Honu ideas

Everett — 2010-08-13T20:08:08

Does anyone think this idea would work for P4P or Honu?

#lang alt-syntax
#|

Sets up a new reader that directly transforms the input into normal
S-Exprs, making this fully compatible with existing Racket (#lang
altsyntax would provide all of racket) and with macros.

Lexer Tokens
  ( ) [ ] { } (| |) _( : ): id string number char keyword etc...

Grammar
  expr
    : id
    | constant

    //Application with expr in app position
    | '{' expr '}' '(' expr_lst ... ')' -> '(' expr expr_lst ... ')'
    
    //Normal application f(a ...)
    | id '(' expr ... ')' -> '(' id expr ... ')'
    
    //Infix application
    | '(|' expr_0 expr_1 expr_2 '|)' -> '(' expr_1 expr_0 expr_2 ')'

    //Normal prefix s-exprs
    | '[' expr ... ']' -> '(' expr ... ')'
    | '_(' expr ... ')' -> '(' expr ... ')'

    //Rules that use colon to replace parens
    | id {no_ws()}? ':' ( { checkIndentation() }? expr ) ... -> '('
expr ... ')'
    | ':' ( { checkIndentation() }? expr ) ... -> '(' expr ... ')'
    | id '(' expr_0 ... ')

Re: [racket-dev] new release policy

Jay McCarthy — 2010-08-13T13:44:55

Even if they don't actually :)

On Fri, Aug 13, 2010 at 7:37 AM, Robby Findler
<robby< at >eecs.northwestern.edu> wrote:

Re: [racket-dev] new release policy

Robby Findler — 2010-08-13T13:37:35

And, on the other side of the coin, I'm sure Jay is willing to
entertain alternative proposals, esp. if they come with
implementations.

Robby

On Fri, Aug 13, 2010 at 8:20 AM, Jay McCarthy <jay.mccarthy< at >gmail.com> wrote:
_________________________________________________
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] new release policy

Jay McCarthy — 2010-08-13T13:20:17

Thanks for debugging me Noel.

Since the API I added merely promises some sequence, there's nothing
preventing us from having it always return a future lazy stream that
can be viewed as a sequence if that ends up being faster. If someday
we have such nice lazy streams, then I predict we'll certainly want
similar functions and we'll have another request for making the
sequence api more like the lazy stream api.

Jay

On Fri, Aug 13, 2010 at 3:55 AM, Noel Welsh <noelwelsh-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: [racket-dev] new release policy

Noel Welsh — 2010-08-13T09:55:13

I think this is incorrect. I read:

- When we provide APIs we lock ourselves into them
- The proposed sequence API is slow and can't be sped up without
significant effort (cf worldwide shortage of Matthew-Flatt-hours)
- We shouldn't lock ourselves into a slow API without considering
alternatives (cf performance of stream/lazy list abstraction)

N.

Re: [racket-dev] new release policy

Jay McCarthy — 2010-08-13T01:45:43

Since some of these features were already available in the unstable
collection, it's clear that useful functionality there is not visible
enough for beginners.


Perhaps his point was that the "ideal" to handle these additions would
be a well publicized and easy to install package.


I parse your comments like this:

- We can't do these sequence functions fast.
- When we didn't provide them, people complained that they were missing.
- When we provide them slowly, people will complain that Racket is slow.
- It is worse to be slow than featureless.

I think it is worse to be featureless. Of the additions I made, I
believe that only seqn-cons, seqn-rest, seqn-tail, seqn-append,
seqn-map, seqn-filter, and seqn-add-between will have the speed
problem. The other functions that produce values will be a little
slower than their equivalents rewritten directly in 'for's, but
sometimes it is nice to write: (seqn-andmap even? s) rather than:
(for/and ([e s]) (even? e)).

I wager that seqn-cons, seqn-rest, and seqn-tail

Re: [racket-dev] new release policy

Eli Barzilay — 2010-08-13T00:46:09

+1, in general.



(And here too.)


On Aug 12, Matthew Flatt wrote:

My point was completely unrelated to packaging.  (Jay added it to the
core racket language anyway.)


On Aug 12, Jay McCarthy wrote:

I should explain why I said the above.  (Yes, this will be verbose.
Why?  Because my short one-sentence version was taken as a baseless
whine, so I'll go through the details that I'd think through before
doing this.  Perhaps this is too much, but I'd like to think it isn't,
especially for code in racket/private.)

First, I completely agree with this specific mode of operation (and
have added several things in a similar way) -- but the thing that I'm
careful with is adding things that might be regretted later on.  One
place that I'm not too happy about is `fold-files', which I'll use as
an example.  IMO, such regretting can lead to one of these:
* Coming up with a better interface, but keeping the old one for
  compatibility (keeping `fold-files' as is, and keeping it working),
* Same, but removing the old o

Re: [racket-dev] GUI Refresh

Robby Findler — 2010-08-12T23:20:21

IMO, example 2 can be remedied inside redex (by pausing briefly before
actually triggering the updates), but the first one is probably
because of a more complex interaction of gui callbacks and probably
trickier to track down.

Robby

On Thu, Aug 12, 2010 at 6:12 PM, Everett <webj2< at >unoc.net> wrote:
_________________________________________________
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] GUI Refresh

Everett — 2010-08-12T23:12:08

Observation of DrRacket and PLT Redex leads me to believe that when
updating something displayed in the GUI each change is immediately
reflected (in a nice functional manner), even if a batch of changes is
being performed, thus wasting time drawing the GUI on intermediate
results.  The effect is a less usable GUI.

Example 1:
Have two tabs open in DrRacket.  Click the other one.  You can see the
scroll bar adjust first, showing the corresponding location in the
current file, then the contents adjust second showing the right file.

Example 2:
In PLT Redex traces graph, move the font-size slider.  The whole GUI
freezes up until it has redrawn, even though I wasn't done moving the
slider.  The result is that I have to move the slider one font size (or
few font sizes) at a time.

Possible solutions:
- For the slider: a timeout after user input stops before actually
changing the value.
- For the tabs: The ability to give a list of changes before updating
the GUI
- Functions to turn on/off updating and use them ar