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]: Leaving directory `/opt/plt/builds/<current-rev>/trunk/src/build'
make: *** [install] Error 2

I assume that you [Kevin] can tell me what this means and how I can
fix it. {Note: "raco setup" completes fine on my machine so I'm not
even sure where to start to reproduce it.}

Jay

On Sat, Aug 14, 2010 at 11:16 AM,  <drdr< at >racket-lang.org> wrote:

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 ... '):' ( { checkIndentation() }? expr_1 ) ... ->
'(' id expr_0 ... expr_1 ...')'
    ;


Indentation rule for ':', checked by "checkIndentation()", is:
- Remember the column of the colon and indentation of the line it is on.
- exprs on the same line are included
- if there are no exprs on the same line, then include lines of the same
indentation for which that indentation is greater than the indentation
on the colon's line.
- if there is something on the same line as the colon, then include
lines of the same indentation for which that indentation is greater than
the colon's column.

The "no_ws()" check checks column of colon vs end column of id to make
sure there's no WS between them.  This could be done by a lexer
returning ID and ID_COLON tokens instead.

Note that the "{ code-that-returns-boolean }?" notation is a "semantic
predicate" in ANTLR. Also "->" is a tree rewrite in ANTLR too.

Reasoning:
- Use Shriram's idea of ':' to indicate structure (like if, let, etc.)
- Use Shriram's idea of {} around expr in application position
- Keep LL(1)
- Use indentation to replace parens when using ':'
- Make this a direct and obvious conversion to S-Expr to maintain
library and macro compatability (not just for students!)
- Allow an infix notation, which is very helpful for math and
comparison.  I use "(|" "|)" to maintain LL(1) parsing without stealing
{} from Shriram's use or '<' '>' which eliminates those chars in
operators, etc.
- Have function calls look like normal math, like f(a)
- Using [] is akin to saying "tuple", which is how it's often used in
let, for, etc. to pair id and value. So we can just parse them as normal
s-exprs
- Provide a way to write normal s-exprs if desired.  Making everything
use [] could work, but I gave "_(" ")" as an alternative to allow
varying things.
- Code should be visually structured very much like Racket is now.

Below shows some examples.
|#

let: loop :[acc 1]
           [acc2 2]
     set!(a 1)
     set!(b (|acc2 + 1|))
     loop((|acc + a|) b)
     
{lambda: [a] a}(1)

{f}(a)
f(a)
[f a]
_(f a)

{g}(a b)
g(a b)
[g a b]
_(g a b)
(|a g b|)

if: (|a > 0|)
    a
    b

;if no tokens on the rest of the line, indent > line_indent vs. indent >
colon_column
cond:
 [true
  doit()]
 [false
  dontDoIt()]
 [else
  "Hello World"]

match: thing
       ["a" display("Thing A")]
       ["b" display("Thing B")]
       [else display("Unknown")]

match:
  thing
  ["a" display("Thing A")]
  ["b" display("Thing B")]
  [else display("Unknown")]

;Blake's idea.  Allow params both in parens and after colon for better
structure formatting.
match (thing):
  ["a" display("Thing A")]
  ["b" display("Thing B")]
  [else display("Unknown")]

if((|a > 0|)):
  a
  b

;Can be abused too, but you'd never do that, right?
match (thing 
       ["a" display("Thing A")]):
  ["b" display("Thing B")]
  [else display("Unknown")]

  
let: :[a 1]
      [b 2]
      [c 3]
    _(+ a b c)


let:   :[a 1][b 2][c 3]
     [+ a b c]

let:
  :[a 1][b 2]
   [c 3]
  +(a b c)
  
define-syntax-rule: 
  test-term-equal(lhs rhs)
  test-equal(term(lhs) term(rhs))

[define-syntax-rule [test-term-equal lhs rhs]
  [test-equal [term lhs] [term rhs]]]

begin:
  doA()
  doB()
  void()


;Use of infix for non-math operations works too, of course.
(| range(1 100) map + |)

;The following is a Redex grammar (a piece of a grammar I'm using)
define-language(lang):
  e: v
     < at >(e)
     id
     setop([pattern in e] e)
     if(e e e)
     let( [[id e]] e)
     op(e ...)
  k: ret
     < at >(k)
     setop(pattern e k)
     if(e e k)
     pop(eta k)
     let(id e k)
     op( [v ...] [e ...] k)
  v: number
     true false
     error
     string
     [addr address]
     [const-set v ...]
     [const-tuple v ...]


Thanks,
-Everett Morse

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 could be made very
faster if it were possible for a do-sequence to turn over control to
another sequence that had already started. seqn-append would be helped
a little.

I think it's worth it for them to be there despite the problems you've
mentioned. I don't think they're like fold-files (which I agree has a
bad interface); they mimic the time honored list API.

Jay

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 one (either a new `fold-files' with a
  different interface, or a new name instead),
* Improving the interface in a desired way, while keeping things
  backward compatible.

The last one is almost always the best way to go, and I view keyword
arguments as an essential feature because it makes this option
practical.  In the `fold-files' case it is likely that problems could
be fixed by adding more keywords, and possible changing the default
behavior (which is more work but even that is reduced with keywords,
since existing call sites only need to be updated with a new keyword).
Without keywords, this would not be possible.

But dealwing with sequences is not something that can be deferred for
later with some keyword -- at least not as easily as with a function.
And in light of this I'd be much more careful about adding things that
might turn out to be more regrets.

As for the actual thing that I'm talking about -- sequences and making
them more list like -- I should have explained why I think this
addition is not something that is clearly desired in my view.

Yes, there is definitely a problem with sequences and lists -- the
first is way more complicated to deal with than the second, and Mark's
post did highlight this issue.  One solution is what Jay did -- do the
extra work of building the list-like sequence functions, and given
enough primitives, the rest would be easy to add if/when needed.  But
what about these issues:

** The addition is *slow*.  Very slow.  I wrote a test program to sum
   up the integers from 0 to 2000000 -- and I get these numbers (test
   code attached below):

   - Plain `for' loop:          cpu time: 9 real time: 10 gc time: 0
   - Using a sequence value:    cpu time: 222 real time: 222 gc time: 0
   - Using `seqn-cdr' on range: cpu time: 1142 real time: 1142 gc time: 211
   - `seqn-cdr' + value:        cpu time: 1141 real time: 1141 gc time: 210

   I view this as a real problem -- performance issues at the 100x
   slowdown are bugs at the library level, but at the core level
   they're *bad* bugs.

** At the conceptual level, there is a major problem with for
   sequences -- if you care about performance, they're second-class
   values.  As seen above, using a sequence value instead of the form
   directly in the for loop makes it 20x slower.  This is kind of ok
   as things currently stand (pre Jay's afdditions), since most people
   who deal with sequences are aware of the issue and propagate the
   same cost tradeoff (providing both a syntactic and a value
   variant).  Making sequence values be more list-like leads to
   emphasizing this problem, and this can lead to problems that end up
   in regretting something => overall reduced stability when there's
   some new interface.  And specifically in this case, a 100x slowdown
   is easily noticeable.

For the first of these (related) problems, you can say that it's a
performance problem that can be improved out later, with no interface
changes.  The question is how much it can improve.  (One way to make
it faster would be to provide macro versions of the whole set of
sequence operations, and this ends up in double the amount of code.)

Regardless, the second problem cannot be improved -- at least not
without some major redesign.  But obviously this means that the
problem is still there regardless of extensions -- and making sequence
values easier to handle will eventually happen anyway.  The question
is whether there is some other way to provide this functionality
(list-like sequences) -- and in this case Mark talks explicitly about
the Clojure feature that makes sequences very easy: lazy lists.  So,
I've tried to get a rough idea of the costs for this simple example of
a range, and I got:
  cpu time: 1581 real time: 1581 gc time: 868
This is still bad, but at the same neighborhood -- so maybe a better
direction for making sequences nicer is to try making them (the value
versions) into lazy lists?  It's true that this is close to the
100x-worse version of `seqn-rest', but if they're both close, then why
not explore making the lazy list version run faster?

But if I switch from `lazy' to plain thunks for the lazy list (which
is probably more appropriate here anyway), I get
  cpu time: 113 real time: 113 gc time: 19
and this is even better than the current (in-range ...) -- and this is
not even including tricks like Shriram mentioned of mixing laziness
and strictness (eg, a range could have a delayed thunk at only every
10th cdr).  So this *does* look like a better way to get this done:
speed up sequence values and make them easy to manage.  Why not try
that or at least *talk* about trying that before adding a chunk of
code that fights with the current windmills, making future
improvements even harder to do?

(And at this point I can see how people can think that such an
improvement can be done regardless of the current extensions -- but my
guess is that nobody will touch it, and things will stay as they are
now.  For now.)

(I'm obviously hoping that this guess will turn out wrong as a result
of writing about it.  But probably not.  I'll shut up now.)

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 around a group of
changes or when dragging a slider.
- Some other kind of double-buffering feature at least, so it isn't as
slow and as visible.


Or am I wrong about the cause (and thus solutions) of these GUI
problems?


Thanks,
-Everett