Re: [racket-dev] racket/gui performance problem when using lots of items in table-panels

2012-07-20 Thread Marijn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19-07-12 17:08, Doug Williams wrote:
 I think the problem is the time it takes to create 600 buttons in
 this case, not the time needed to switch between the tabs. I'm not
 sure why you are recreating them each refresh. Am I missing
 something?

This is a cutdown slightly changed testcase for a performance problem
I'm having in a real program. I'm using some tabs that recreate their
contents in my program, because their contents depend on values input
by the user from another tab. In the testcase, imagine that the first
tab is not blank but lets you specify the number of rows and columns
of the table of buttons on tab 2.

Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAJCm0ACgkQp/VmCx0OL2y6yQCfYPX0yMMNNSUdk5J3FoCeHYg9
Ia4AnRbCOVgH13ZyQN/HbrJXkbTC37a4
=Shso
-END PGP SIGNATURE-
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Official PLaneT account?

2012-07-20 Thread Sam Tobin-Hochstadt
On Fri, Jul 20, 2012 at 12:24 AM, Asumu Takikawa as...@ccs.neu.edu wrote:
 I heard rumours that there was once an official PLT PLaneT account
 intended for packages maintained by the dev team. Does anyone know if it
 exists and how to go about getting access to it?

I think Carl is the right person to ask here.  (Hopefully he doesn't
say the same about me.)

 I was thinking that it'd be more appropriate to put the
 'parser-combinator' and 'tex2page' packages under such an account rather
 than under mine.

Note that it's probably easier for people who need these packages to
use them from GitHub with 'raco link', since then they wouldn't need
to change any `require` lines.
-- 
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Official PLaneT account?

2012-07-20 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 07/20/2012 07:23 AM:

I was thinking that it'd be more appropriate to put the
'parser-combinator' and 'tex2page' packages under such an account rather
than under mine.
 

Note that it's probably easier for people who need these packages to
use them from GitHub with 'raco link', since then they wouldn't need
to change any `require` lines.
   


Shouldn't everyone try to eat PLaneT brand dog food?  (Not subsist off 
of Git brand dog treats.)


Neil V.

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


Re: [racket-dev] Official PLaneT account?

2012-07-20 Thread Sam Tobin-Hochstadt
On Fri, Jul 20, 2012 at 7:36 AM, Neil Van Dyke n...@neilvandyke.org wrote:
 Sam Tobin-Hochstadt wrote at 07/20/2012 07:23 AM:

 I was thinking that it'd be more appropriate to put the
 'parser-combinator' and 'tex2page' packages under such an account rather
 than under mine.


 Note that it's probably easier for people who need these packages to
 use them from GitHub with 'raco link', since then they wouldn't need
 to change any `require` lines.

 Shouldn't everyone try to eat PLaneT brand dog food?  (Not subsist off of
 Git brand dog treats.)

Whether or not that's the case in general, in 5.2.1 you can do:

   (require combinator-parser)

which can't be replicated with a PLaneT package, but can be replicated
with a library set up with `raco link`, so this may be more useful for
existing users of this now-deprecated code.

-- 
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Official PLaneT account?

2012-07-20 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 07/20/2012 07:44 AM:

On Fri, Jul 20, 2012 at 7:36 AM, Neil Van Dyken...@neilvandyke.org  wrote:
   

Shouldn't everyone try to eat PLaneT brand dog food?  (Not subsist off of
Git brand dog treats.)
 

Whether or not that's the case in general, in 5.2.1 you can do:

(require combinator-parser)

which can't be replicated with a PLaneT package, but can be replicated
with a library set up with `raco link`, so this may be more useful for
existing users of this now-deprecated code.
   


In the August release, should collection links support PLaneT versions 
(whether coming from PLaneT server or PLaneT dev links)?  (I don't know 
the answer; I don't know the philosophy of how these links are supposed 
to fit with PLaneT.)


Regarding the case in general, occasionally it seems to me like there is 
a dogfood issue there.  Which is why I jump on any additional precedent 
for using Git instead of PLaneT -- jump like an alpha Shih Tzu.


Neil

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


Re: [racket-dev] Official PLaneT account?

2012-07-20 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 07/20/2012 07:44 AM:

Shouldn't everyone try to eat PLaneT brand dog food?  (Not subsist off of
Git brand dog treats.)
 

Whether or not that's the case in general, in 5.2.1 you can do:

(require combinator-parser)

which can't be replicated with a PLaneT package, but can be replicated
with a library set up with `raco link`, so this may be more useful for
existing users of this now-deprecated code.
   


In the August release, should collection links support PLaneT versions 
(whether coming from PLaneT server or PLaneT dev links)?  (I don't know 
the answer; I don't know the philosophy of how these links are supposed 
to fit with PLaneT.)


Regarding the case in general, occasionally it seems to me like there is 
a dogfood issue there.  Which is why I jump on any additional precedent 
for using Git instead of PLaneT -- jump like a bloodthirsty Shih Tzu.


Neil

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


Re: [racket-dev] Official PLaneT account?

2012-07-20 Thread Sam Tobin-Hochstadt
On Fri, Jul 20, 2012 at 8:21 AM, Neil Van Dyke n...@neilvandyke.org wrote:
 Sam Tobin-Hochstadt wrote at 07/20/2012 07:44 AM:

 Shouldn't everyone try to eat PLaneT brand dog food?  (Not subsist off of
 Git brand dog treats.)


 Whether or not that's the case in general, in 5.2.1 you can do:

 (require combinator-parser)

 which can't be replicated with a PLaneT package, but can be replicated
 with a library set up with `raco link`, so this may be more useful for
 existing users of this now-deprecated code.



 In the August release, should collection links support PLaneT versions
 (whether coming from PLaneT server or PLaneT dev links)?  (I don't know the
 answer; I don't know the philosophy of how these links are supposed to fit
 with PLaneT.)

Collection links operate like any other collection (from the `require`
perspective; how they're found is different).  So I'm not sure what it
would mean to support PLaneT versions.
-- 
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] props script

2012-07-20 Thread Robby Findler
Just to clarify: the props script is now useless to as a mechanism for
actually setting properties, since the output is always the below, no
matter of the arguments.

And I think that deleting my DrRacket.app and .DS_Store files is
probably not the way to go to get a working props script.

Robby

On Thu, Jul 19, 2012 at 7:16 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Does anyone know what this means from the props script?

 [robby@yanpu] ~/git/plt/collects/meta$ ./props
 Root: /Users/robby/git/plt/...
   .DS_Store: no responsible
   DrRacket.app: no responsible
   GRacket.app: no responsible
   PLT Games.app: no responsible
   Racket Documentation.app: no responsible
   Search Magic.app: no responsible
   Set Fonts.app: no responsible
   SirMail.app: no responsible
   Slideshow.app: no responsible
   Stopwatch.app: no responsible
   Webcam.app: no responsible
   collects/.DS_Store: no responsible
   collects/combinator-parser: no responsible
   collects/guibuilder: no responsible
   collects/srpersist: no responsible
   collects/tex2page: no responsible
   collects/waterworld: no responsible
   collects/tests/aligned-pasteboard: no responsible
   collects/tests/plot: no responsible
   collects/tests/typed-scheme: no responsible
 props: 20 path errors
 [robby@yanpu] ~/git/plt/collects/meta$
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] props script

2012-07-20 Thread Sam Tobin-Hochstadt
I also see this error, and as I don't have those particular files, it
seems unlikely that it's something specific to Robby's setup.

On Fri, Jul 20, 2012 at 8:49 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Just to clarify: the props script is now useless to as a mechanism for
 actually setting properties, since the output is always the below, no
 matter of the arguments.

 And I think that deleting my DrRacket.app and .DS_Store files is
 probably not the way to go to get a working props script.

 Robby

 On Thu, Jul 19, 2012 at 7:16 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Does anyone know what this means from the props script?

 [robby@yanpu] ~/git/plt/collects/meta$ ./props
 Root: /Users/robby/git/plt/...
   .DS_Store: no responsible
   DrRacket.app: no responsible
   GRacket.app: no responsible
   PLT Games.app: no responsible
   Racket Documentation.app: no responsible
   Search Magic.app: no responsible
   Set Fonts.app: no responsible
   SirMail.app: no responsible
   Slideshow.app: no responsible
   Stopwatch.app: no responsible
   Webcam.app: no responsible
   collects/.DS_Store: no responsible
   collects/combinator-parser: no responsible
   collects/guibuilder: no responsible
   collects/srpersist: no responsible
   collects/tex2page: no responsible
   collects/waterworld: no responsible
   collects/tests/aligned-pasteboard: no responsible
   collects/tests/plot: no responsible
   collects/tests/typed-scheme: no responsible
 props: 20 path errors
 [robby@yanpu] ~/git/plt/collects/meta$
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



-- 
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] racket/gui performance problem when using lots of items in table-panels

2012-07-20 Thread Doug Williams
Matthew might be able to shed some light on it. But, I suspect you'd
have similar performance regardless of the container used.

On Fri, Jul 20, 2012 at 1:36 AM, Marijn hk...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 19-07-12 17:08, Doug Williams wrote:
 I think the problem is the time it takes to create 600 buttons in
 this case, not the time needed to switch between the tabs. I'm not
 sure why you are recreating them each refresh. Am I missing
 something?

 This is a cutdown slightly changed testcase for a performance problem
 I'm having in a real program. I'm using some tabs that recreate their
 contents in my program, because their contents depend on values input
 by the user from another tab. In the testcase, imagine that the first
 tab is not blank but lets you specify the number of rows and columns
 of the table of buttons on tab 2.

 Marijn
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlAJCm0ACgkQp/VmCx0OL2y6yQCfYPX0yMMNNSUdk5J3FoCeHYg9
 Ia4AnRbCOVgH13ZyQN/HbrJXkbTC37a4
 =Shso
 -END PGP SIGNATURE-
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] props script

2012-07-20 Thread Eli Barzilay
Two hours ago, Robby Findler wrote:
 Just to clarify: the props script is now useless to as a mechanism
 for actually setting properties, since the output is always the
 below, no matter of the arguments.

It was an attempt to make it verify the properties that drdr will
run.  I switched the strategy that is used for that now.

(As a side note, this changed happened a good while ago -- it confirms
my guess that most people just edit the file directly...)


 And I think that deleting my DrRacket.app and .DS_Store files is
 probably not the way to go to get a working props script.

Yeah -- it would be nice if it tried to verify only things that are in
git, but that doesn't work on the tree that drdr uses.  I've added
ignore patterns for the *.app and the .DS_Store files now, so it
should verify for you now (but now you'll need to run it with a
verify subverb to do it, of course).  BTW, the directories below are
old things that are no longer in the tree -- you probably still have
them in with a compiled directory (which is why git wouldn't remove
them when they're removed from the repo):

  collects/combinator-parser: no responsible
  collects/guibuilder: no responsible
  collects/srpersist: no responsible
  collects/tex2page: no responsible
  collects/waterworld: no responsible
  collects/tests/aligned-pasteboard: no responsible
  collects/tests/plot: no responsible
  collects/tests/typed-scheme: no responsible

-- 
  ((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


Re: [racket-dev] props script

2012-07-20 Thread Eli Barzilay
Two hours ago, Sam Tobin-Hochstadt wrote:
 I also see this error, and as I don't have those particular files, it
 seems unlikely that it's something specific to Robby's setup.

You shouldn't see errors about .DS_Store and *.app things if you don't
have them.

-- 
  ((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


Re: [racket-dev] props script

2012-07-20 Thread Sam Tobin-Hochstadt
On Fri, Jul 20, 2012 at 10:49 AM, Eli Barzilay e...@barzilay.org wrote:
 Two hours ago, Sam Tobin-Hochstadt wrote:
 I also see this error, and as I don't have those particular files, it
 seems unlikely that it's something specific to Robby's setup.

 You shouldn't see errors about .DS_Store and *.app things if you don't
 have them.

Right, I saw errors about different files.
-- 
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Official PLaneT account?

2012-07-20 Thread Carl Eastlund
On Fri, Jul 20, 2012 at 7:23 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
 On Fri, Jul 20, 2012 at 12:24 AM, Asumu Takikawa as...@ccs.neu.edu wrote:
 I heard rumours that there was once an official PLT PLaneT account
 intended for packages maintained by the dev team. Does anyone know if it
 exists and how to go about getting access to it?

 I think Carl is the right person to ask here.  (Hopefully he doesn't
 say the same about me.)

Oh dear, that's exactly what I was going to do...  I've clicked the
forgot my password link for that account, we'll see who gets the
email, I guess.

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


Re: [racket-dev] Official PLaneT account?

2012-07-20 Thread Carl Eastlund
On Fri, Jul 20, 2012 at 11:16 AM, Carl Eastlund c...@ccs.neu.edu wrote:
 On Fri, Jul 20, 2012 at 7:23 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu 
 wrote:
 On Fri, Jul 20, 2012 at 12:24 AM, Asumu Takikawa as...@ccs.neu.edu wrote:
 I heard rumours that there was once an official PLT PLaneT account
 intended for packages maintained by the dev team. Does anyone know if it
 exists and how to go about getting access to it?

 I think Carl is the right person to ask here.  (Hopefully he doesn't
 say the same about me.)

 Oh dear, that's exactly what I was going to do...  I've clicked the
 forgot my password link for that account, we'll see who gets the
 email, I guess.

 --Carl

Mystery solved, it's an alias to both Sam and me.  Asumu, I'll send
you details privately.

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


Re: [racket-dev] [plt] Push #25029: master branch updated

2012-07-20 Thread Matthias Felleisen

Yes, the commit with the docs sit on my desktop. 


On Jul 20, 2012, at 12:27 PM, Sam Tobin-Hochstadt wrote:

 This commit adds two undocumented exports to `racket/system` and thus
 `racket`.  Are they intended to be exported?
 
 On Fri, Jul 20, 2012 at 10:38 AM,  matth...@racket-lang.org wrote:
 
 
 f2b9cda Matthias Felleisen matth...@racket-lang.org 2012-07-20 10:37
 :
 | fixed a somewhat awkward error message that made 'system' look awkward
 :
  M collects/racket/system.rkt | 11 +++
 
 
 
 -- 
 sam th
 sa...@ccs.neu.edu

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


Re: [racket-dev] [plt] Push #25029: master branch updated

2012-07-20 Thread Eli Barzilay
I didn't have time to look more, but I think that two things are still
needed for this: using the new predicates in the docs, and changing
the contract strings in error messages of `subprocess' to use the same
terminology.


30 minutes ago, Matthias Felleisen wrote:
 
 Yes, the commit with the docs sit on my desktop. 

-- 
  ((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


[racket-dev] testing for v5.3

2012-07-20 Thread Ryan Culpepper

Just a reminder that testing for release v5.3 begins Monday.

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


Re: [racket-dev] [plt] Push #25038: master branch updated

2012-07-20 Thread Vincent St-Amour
At Fri, 20 Jul 2012 16:17:22 -0400,
as...@racket-lang.org wrote:
 3582b57 Asumu Takikawa as...@racket-lang.org 2012-07-20 15:10
 :
 | Move mzlib/defmacro = racket/defmacro

I'm not sure this belongs in `racket'. This is not a Racket feature.
It's closer to a CL compatibility library.

How about having a `compatibility' collect, which would include this and
things like `racket/package' (compatibility with Chez) and `racket/mpair'
(compatibility with Scheme)? It would be harder to confuse these things
with blessed Racket features.

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


Re: [racket-dev] [plt] Push #25038: master branch updated

2012-07-20 Thread Carl Eastlund
On Fri, Jul 20, 2012 at 4:33 PM, Vincent St-Amour stamo...@ccs.neu.edu wrote:
 At Fri, 20 Jul 2012 16:17:22 -0400,
 as...@racket-lang.org wrote:
 3582b57 Asumu Takikawa as...@racket-lang.org 2012-07-20 15:10
 :
 | Move mzlib/defmacro = racket/defmacro

 I'm not sure this belongs in `racket'. This is not a Racket feature.
 It's closer to a CL compatibility library.

 How about having a `compatibility' collect, which would include this and
 things like `racket/package' (compatibility with Chez) and `racket/mpair'
 (compatibility with Scheme)? It would be harder to confuse these things
 with blessed Racket features.

 Vincent

+1

For backwards (ahem) compatibility, we would have to maintain the
racket/package and racket/mpair names as aliases, but changing
existing uses of them to the new name and making the racket/
documentation point to compatibility/ would help make the point.

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


Re: [racket-dev] [plt] Push #25038: master branch updated

2012-07-20 Thread Ryan Culpepper

On 07/20/2012 04:36 PM, Carl Eastlund wrote:

On Fri, Jul 20, 2012 at 4:33 PM, Vincent St-Amourstamo...@ccs.neu.edu  wrote:

At Fri, 20 Jul 2012 16:17:22 -0400,
as...@racket-lang.org wrote:

3582b57 Asumu Takikawaas...@racket-lang.org  2012-07-20 15:10
:
| Move mzlib/defmacro =  racket/defmacro


I'm not sure this belongs in `racket'. This is not a Racket feature.
It's closer to a CL compatibility library.

How about having a `compatibility' collect, which would include this and
things like `racket/package' (compatibility with Chez) and `racket/mpair'
(compatibility with Scheme)? It would be harder to confuse these things
with blessed Racket features.

Vincent


+1

For backwards (ahem) compatibility, we would have to maintain the
racket/package and racket/mpair names as aliases, but changing
existing uses of them to the new name and making the racket/
documentation point to compatibility/ would help make the point.


-1

I think proliferating indirections and aliases is just as bad as (or 
maybe worse than) proliferating top-level collections. If it's in mzlib/ 
and it's still really useful, move it to racket/ (or data/, etc). If it 
isn't (eg, mzlib/defmacro, perhaps mzlib/thread), then just leave it alone.


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


Re: [racket-dev] [plt] Push #25038: master branch updated

2012-07-20 Thread Matthias Felleisen
++1 

Sent from my iPhone

On Jul 20, 2012, at 4:36 PM, Carl Eastlund c...@ccs.neu.edu wrote:

 On Fri, Jul 20, 2012 at 4:33 PM, Vincent St-Amour stamo...@ccs.neu.edu 
 wrote:
 At Fri, 20 Jul 2012 16:17:22 -0400,
 as...@racket-lang.org wrote:
 3582b57 Asumu Takikawa as...@racket-lang.org 2012-07-20 15:10
 :
 | Move mzlib/defmacro = racket/defmacro
 
 I'm not sure this belongs in `racket'. This is not a Racket feature.
 It's closer to a CL compatibility library.
 
 How about having a `compatibility' collect, which would include this and
 things like `racket/package' (compatibility with Chez) and `racket/mpair'
 (compatibility with Scheme)? It would be harder to confuse these things
 with blessed Racket features.
 
 Vincent
 
 +1
 
 For backwards (ahem) compatibility, we would have to maintain the
 racket/package and racket/mpair names as aliases, but changing
 existing uses of them to the new name and making the racket/
 documentation point to compatibility/ would help make the point.
 
 --Carl
 _
  Racket Developers list:
  http://lists.racket-lang.org/dev

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


[racket-dev] Compile issue in src/racket/gc2/sighand.c

2012-07-20 Thread crdueck

Hello all,

Recently, I tried to compile the unix source for racket-textual found 
here: 
http://download.racket-lang.org/racket-textual-5-2-1-src-unix-tgz.html 
using GCC 4.7.1 and kernel Linux 3.4.4-3 x86_64.


cd src  ./configure=/opt  make returned the following errors:

In file included from ./newgc.c:2436:0,
from ./gc2.c:15:
./sighand.c:63:35: warning: ‘struct siginfo’ declared inside parameter 
list [enabled by default]
./sighand.c:63:35: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]

./sighand.c: In function ‘fault_handler’:
./sighand.c:65:15: error: dereferencing pointer to incomplete type
./sighand.c:67:13: error: dereferencing pointer to incomplete type
./sighand.c:71:9: error: dereferencing pointer to incomplete type
./sighand.c:87:46: error: dereferencing pointer to incomplete type
./sighand.c:87:74: error: dereferencing pointer to incomplete type
./sighand.c:103:11: error: dereferencing pointer to incomplete type
In file included from ./newgc.c:2436:0,
from ./gc2.c:15:
./sighand.c: In function ‘initialize_signal_handler’:
./sighand.c:227:42: warning: assignment from incompatible pointer type 
[enabled by default]

make[4]: *** [gc2.o] Error 1

i opened src/racket/gc2/sighand.c and looked at the offending line 63, 
where struct siginfo doesnt seem to be an actual struct. Scrolling down 
a bit more to line 131, i see that siginfo_t is a valid typedef so on 
line 63 i did s/struct siginfo/siginfo_t/ and the syntax errors 
disappeared.


make  sudo make install then ran fine and I used the racket executable 
to run a .rkt source file with no problems.


seems like a typedef might have been changed somewhere along the road?
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Compile issue in src/racket/gc2/sighand.c

2012-07-20 Thread Eli Barzilay
10 minutes ago, crdueck wrote:
 
 i opened src/racket/gc2/sighand.c and looked at the offending line
 63, where struct siginfo doesnt seem to be an actual
 struct. Scrolling down a bit more to line 131, i see that siginfo_t
 is a valid typedef so on line 63 i did s/struct siginfo/siginfo_t/
 and the syntax errors disappeared.

This looks like it confirms this fix:

  http://sourceware.org/ml/libc-alpha/2012-03/msg00414.html

-- 
  ((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


Re: [racket-dev] [plt] Push #25038: master branch updated

2012-07-20 Thread Eli Barzilay
Three hours ago, Vincent St-Amour wrote:
 
 I'm not sure this belongs in `racket'. This is not a Racket feature.
 It's closer to a CL compatibility library.

+1


 How about having a `compatibility' collect, which would include this
 and things like `racket/package' (compatibility with Chez) and
 `racket/mpair' (compatibility with Scheme)? It would be harder to
 confuse these things with blessed Racket features.

+1

Two hours ago, Ryan Culpepper wrote:
 
 -1
 
 I think proliferating indirections and aliases is just as bad as (or
 maybe worse than) proliferating top-level collections. If it's in
 mzlib/ and it's still really useful, move it to racket/ (or data/,
 etc). If it isn't (eg, mzlib/defmacro, perhaps mzlib/thread), then
 just leave it alone.

+1 for the sentiment of having too many redirections both at the file
level and at the binding level (like the many @scheme bindings in
scribble).  But OTOH, I did mention that one of the weird things when
I talk about `defmacro' in class is the arbitrary looking mzlib...

So I think that organized expirations address this nicely.  Perhaps
it's another argument in favor of throwing a syntax error at the
end-of-life of a deprecated library/name, one that explicitly says
use `compat/defmacro' instead of `mzlib/defmacro', and leaving that
on for a release or two.  This will save people a dig through the
docs/mailing-list/google to find out how to change things.

(BTW, I think that the `scheme' collection could go this way too.)

-- 
  ((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


Re: [racket-dev] Coroutines (mzlib/thread)

2012-07-20 Thread Matthias Felleisen

There are two notions of coroutines and they actually are distinct forms of 
control abstractions. There are the ones that explicitly yield and received 
their name from Simula 67. And then there are the ones that implicitly yield 
(time, certain events) and then some 'master' picks the next one to run 
(depending on some conditions); in Simula 67 this is a 'pattern'. We can build 
it for real. Both interfaces have separate uses and should be kept separate. -- 
Matthias



On Jul 20, 2012, at 4:50 PM, Asumu Takikawa wrote:

 Hi all,
 
 I've been moving some libraries from mzlib to more appropriate places
 recently. I was meaning to move `mzlib/thread` to `racket/coroutine`,
 but had some questions about its API.
 
 It appears that the coroutines from `mzlib/thread` don't actually
 provide a built-in way to yield the computation to another coroutine.
 Instead, the coroutine is run with either a timeout or an event that
 suspends the computation and returns to the caller.
 
 Is this a useful coroutine API? It seems that to encode the typical
 `yield` construct you need to set up your own protocol with, say, a
 channel to trigger a context switch and then do scheduling manually. If
 we're going to bother providing it as a `racket` library, should we try
 to improve the API?
 
 NB: the only use I could find in the code base was in
 framework/private/color.rkt.
 
 Cheers,
 Asumu
 _
  Racket Developers list:
  http://lists.racket-lang.org/dev


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


Re: [racket-dev] [plt] Push #25038: master branch updated

2012-07-20 Thread Matthias Felleisen

+ a lot 


On Jul 20, 2012, at 7:32 PM, Eli Barzilay wrote:

 (BTW, I think that the `scheme' collection could go this way too.)

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


Re: [racket-dev] props script

2012-07-20 Thread Robby Findler
On Fri, Jul 20, 2012 at 9:48 AM, Eli Barzilay e...@barzilay.org wrote:
 Two hours ago, Robby Findler wrote:
 Just to clarify: the props script is now useless to as a mechanism
 for actually setting properties, since the output is always the
 below, no matter of the arguments.

 It was an attempt to make it verify the properties that drdr will
 run.  I switched the strategy that is used for that now.

 (As a side note, this changed happened a good while ago -- it confirms
 my guess that most people just edit the file directly...)

Well, I've learned my lesson, certainly.

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