Re: [racket-dev] Racket docs and data-driven design
On Sep 16, 2011, at 11:52 AM, Shriram Krishnamurthi wrote: I introduced templates today. Almost as if on cue, one student asked whether he could use else instead of (cons? l). I told them I was going to make a MORAL judgment about why it was EVIL, and spent ten minutes talking about all that. As class ended, one of my students came up and said, So why doesn't the Racket language Web site agree with you? http://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html (Look for [else.) Interesting. I'm with you: I tell my students to use else to capture true none of the above cases that can't easily be described directly, e.g. (define (size thing) (cond [(string? thing) (string-length thing)] [(real? thing) (abs thing)] [(image? thing) (* (image-width thing) (image-height thing))] [else (error 'size I don't know how to handle that type.)])) Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] mips/ia64 build failures due to unaligned memory access (was: Re: Build failure on specific PPC systems)
On Fri, Aug 26, 2011 at 05:42:10AM -0400, Eli Barzilay wrote: Two days ago, James Vega wrote: Since I've generally had more luck using the cgc GC on less mainstream systems, I set the build to use that for PowerPC and let it be in case things changed and it started working. This is a bad idea. There are certain things that are practically impossible with the CGC. Given that warning, I started revisiting the failures I had seen with 3m. All the below is with 5.1.3. mips and ia64 both fail with unaligned access, although in different places. ia64's build failure ,-- |cd gc2; /usr/bin/make all |make[4]: Entering directory `/home/jamessan/racket-5.1.3+dfsg1/build/racket/gc2' |/usr/bin/make xsrc/precomp.h |make[5]: Entering directory `/home/jamessan/racket-5.1.3+dfsg1/build/racket/gc2' |env XFORM_PRECOMP=yes ../racketcgc -cqu /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/xform.rkt --setup . --cpp gcc -E -I./.. -I/home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../include --keep-lines -o xsrc/precomp.h /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/precomp.c |GC Warning: GC_register_stackbottom should be set with GC_stackbottom |Removing old xform-collects tree... |Copying tree... |[snip copying] |Compiling xform support... |xform.rkt(2950): unaligned access to 0x6003708c, ip=0x4035a9e1 |make[5]: *** [xsrc/precomp.h] Illegal instruction (core dumped) |make[5]: Leaving directory `/home/jamessan/racket-5.1.3+dfsg1/build/racket/gc2' `-- and backtrace ,-- |(gdb) bt full |#0 0x4035ac31 in scheme_setjmpup_relative (b=0x0, base=0x47e0b40, |start=0x47e0b002000, c=0x47e0ac02000) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/src/setjmpup.c:553 |local = 1 |disguised_b = 0 `-- mips' build failure ,-- |make[3]: Leaving directory `/home/jamessan/racket-5.1.3+dfsg1/build' |env CFLAGS=-g -Wall -Wall LDFLAGS= racket/racket3m -X /home/jamessan/racket-5.1.3+dfsg1/debian/tmp/usr/share/racket/collects -N raco setup -l- setup -j 1 --no-docs --no-zo --no-user |raco setup: bootstrapping from source... |make[2]: *** [install-3m] Bus error (core dumped) `-- and backtrace ,-- |(gdb) bt |#0 0x0060675c in syncing_ready (s=0x2dbf3220, sinfo=0x7fe4efc0) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/thread.c:5661 |#1 0x00601e34 in scheme_block_until (_f=0x606114 syncing_ready, |fdf=0x60697c syncing_needs_wakeup, data=0x2dbf3220, delay=0) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/thread.c:4258 |#2 0x006079fc in do_sync (name=0x6aa2fc sync, argc=1, argv=0x2d69efa8, with_break=0, |with_timeout=0, _tailok=1) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/thread.c:5903 |#3 0x00607fe4 in sch_sync (argc=1, argv=0x2d69efa8) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/thread.c:5996 |#4 0x00441944 in scheme_do_eval (obj=0x71bc78, num_rands=1, rands=0x2d69efa8, get_value=1) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/eval.c:2407 |#5 0x00444a28 in scheme_do_eval (obj=0x2d6bb9b8, num_rands=5, rands=0x2d69ef9c, get_value=-1) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/eval.c:3368 |#6 0x00465928 in apply_k () at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/fun.c:1285 |#7 0x00465204 in scheme_top_level_do_worker (k=0x465870 apply_k, eb=1, new_thread=1, |dyn_state=0x0) at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/fun.c:1126 |#8 0x00465b30 in scheme_apply_thread_thunk (rator=0x2d74af48) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/fun.c:1325 |#9 0x005fd854 in start_child (child=0x2d689038, child_eval=0x2dbf32b0) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/thread.c:2766 |#10 0x005fdc10 in make_subprocess (child_thunk=0x2dbf32b0, child_start=0x7fe4f99c, |config=0x2dbf3210, cells=0x2dbf31e8, break_cell=0x2b2587c0, mgr=0x0, normal_kill=1) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/thread.c:2855 |#11 0x005fe800 in scheme_thread_w_details (thunk=0x4, config=0x2b2085b0, cells=0x7fe4f9e0, |break_cell=0x436a2c, mgr=0x0, suspend_to_kill=4) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/thread.c:3073 |#12 0x2d5147b0 in ?? () |warning: GDB can't find the start of the function at 0x2d5147ae. `-- If there's more information I can provide, let me know. Thanks, -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] foreign struct access different in 5.1.3?
At Sat, 17 Sep 2011 07:44:50 -0600, Kevin Tew wrote: If you would like document the fact that cstructs are generative only up to version 5.1.3. I think that improve the docs. I think the right next step is for you (Kevin) to update doc/release-notes/racket/HISTORY.txt to describe the change. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] mips/ia64 build failures due to unaligned memory access (was: Re: Build failure on specific PPC systems)
At Sat, 17 Sep 2011 09:10:44 -0400, James Vega wrote: mips and ia64 both fail with unaligned access, although in different places. ia64's build failure I think Racket won't work on ia64 because we never worked out how to deal with its multiple stacks. mips' build failure ,-- |make[3]: Leaving directory `/home/jamessan/racket-5.1.3+dfsg1/build' |env CFLAGS=-g -Wall -Wall LDFLAGS= racket/racket3m -X /home/jamessan/racket-5.1.3+dfsg1/debian/tmp/usr/share/racket/collects -N raco setup -l- setup -j 1 --no-docs --no-zo --no-user |raco setup: bootstrapping from source... |make[2]: *** [install-3m] Bus error (core dumped) `-- and backtrace ,-- |(gdb) bt |#0 0x0060675c in syncing_ready (s=0x2dbf3220, sinfo=0x7fe4efc0) |at /home/jamessan/racket-5.1.3+dfsg1/src/racket/gc2/../src/thread.c:5661 I'm not sure, but here are two things to try: * In src/racket/gc2/newgc.c around line 2601, force `generations_available' to 0: newgc-generations_available = 0; If something is going wrong with the write barrier, then disabling generational GC should allow the build to continue. * In src/racket/gc2/sighand.c around line 122, change # define USE_SIGACTON_SIGNAL_KIND SIGSEGV to # define USE_SIGACTON_SIGNAL_KIND SIGBUS to check whether page-protection failures trigger SIGBUS instead of SIGSEGV. I think this is unlikely to be the problem, but it may be worth checking. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] posting to semaphore from C causes seg fault
It looks like the call in C might have been in a thread other than the
thread where Racket was started. In that case, when scheme_post_sema()
tries to cooperate with the GC, then it would end up with a NULL
pointer for the Racket GC information of the current thread.
In particular, since you're asking about semaphores, I wonder whether
you were trying to use Racket semaphores to synchronize OS-level
threads? If so, it won't work; Racket semaphores only work among Racket
threads, and you'd have to use OS-level semaphores to synchronize
OS-level threads.
If you were calling scheme_post_sema() from an OS thread where Racket
was started, though, then we need to investigate further.
At Wed, 14 Sep 2011 00:14:33 -0700, John Clements wrote:
I'm unable to pass a semaphore to C and post to it from there. In particular,
it causes a seg fault. I'm testing the Scheme_Object * with SCHEME_SEMAP, so
I'm pretty sure it's a semaphore. Also, I can see this happen in gdb, but the
code is optimized, so it's hard to see exactly where it's failing. The
semaphore object looks like this in gdb:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0008
[Switching to process 1825]
scheme_post_sema (o=0x104a14668) at sema.c:284
284
(gdb) l
279
280 void scheme_post_sema(Scheme_Object *o)
281 {
282 Scheme_Sema *t = (Scheme_Sema *)o;
283 int v, consumed;
284
285 if (t-value 0) return;
286
287 v = t-value + 1;
288 if (v t-value) {
(gdb) p t
$1 = (Scheme_Sema *) 0x104a14668
(gdb) p t-value
$2 = 0
(gdb) p v
Unable to access variable v
$5 = variable optimized away by compiler
(gdb) p *t
$6 = {
so = {
type = 78,
keyex = 0
},
first = 0x0,
last = 0x0,
value = 0
}
The strange thing here is that the C code for scheme_sema_post suggests that
when t-first is 0x0, it should just silently return. Okay, so I dug into the
assembly a bit more, and it turns out that the compiled version of this code
looks like this:
Dump of assembler code for function scheme_post_sema:
0x00010020e0d0 scheme_post_sema+0: push %rbp
0x00010020e0d1 scheme_post_sema+1: mov%rsp,%rbp
0x00010020e0d4 scheme_post_sema+4: push %r14
0x00010020e0d6 scheme_post_sema+6: push %r13
0x00010020e0d8 scheme_post_sema+8: push %r12
0x00010020e0da scheme_post_sema+10: push %rbx
0x00010020e0db scheme_post_sema+11: sub$0x30,%rsp
0x00010020e0df scheme_post_sema+15: mov%rdi,-0x28(%rbp)
0x00010020e0e3 scheme_get_thread_local_variables+0: lea
0x104cce(%rip),%r13# 0x100312db8 scheme_thread_local_offset
0x00010020e0ea scheme_get_thread_local_variables+7: mov
0x0(%r13),%edx
0x00010020e0ee scheme_get_thread_local_variables+11:lea
0x12434b(%rip),%r14# 0x100332440 scheme_thread_local_key
0x00010020e0f5 scheme_get_thread_local_variables+18:mov
(%r14),%eax
0x00010020e0f8 scheme_get_thread_local_variables+21:addr32 mov
%gs:(%edx,%eax,8),%rdx
-- IT CRASHES ON THIS NEXT INSTRUCTION: --
0x00010020e0fe scheme_post_sema+46: mov0x8(%rdx),%rax
0x00010020e102 scheme_post_sema+50: mov%rax,-0x50(%rbp)
0x00010020e106 scheme_post_sema+54: lea-0x50(%rbp),%rax
0x00010020e10a scheme_post_sema+58: mov%rax,0x8(%rdx)
0x00010020e10e scheme_post_sema+62: lea-0x28(%rbp),%rax
0x00010020e112 scheme_post_sema+66: mov%rax,-0x40(%rbp)
0x00010020e116 scheme_post_sema+70: mov0x18(%rdi),%rdx
0x00010020e11a scheme_post_sema+74: test %rdx,%rdx
The problem on the given instruction is that %rdx is 0, and thus that loading
from an offset of 8 from 0x0 seg faults.
The gdb info makes it look as though this is an inlining of a function called
scheme_get_thread_local_variables, though I can't see why it would be called
here; the C code looks like it should just increment the counter and return.
As I said, this is completely and totally reproducible, so I'm happy to carry
out any experiments; at this point, I'm at the throwing up my hands and
saying
compiler bug? stage.
Many thanks for any suggestions,
John
--
[application/#f smime.p7s] [~/Desktop open] [~/Temp open]
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] posting to semaphore from C causes seg fault
On Sep 17, 2011, at 7:32 AM, Matthew Flatt wrote: It looks like the call in C might have been in a thread other than the thread where Racket was started. In that case, when scheme_post_sema() tries to cooperate with the GC, then it would end up with a NULL pointer for the Racket GC information of the current thread. In particular, since you're asking about semaphores, I wonder whether you were trying to use Racket semaphores to synchronize OS-level threads? If so, it won't work; Racket semaphores only work among Racket threads, and you'd have to use OS-level semaphores to synchronize OS-level threads. If you were calling scheme_post_sema() from an OS thread where Racket was started, though, then we need to investigate further. Nope, that's it; I was trying to use scheme_post_sema to synchronize threads. I spent another few minutes in the docs, and *finally* found the relevant paragraph: In an embedding application, Racket can co-exist with additional OS-implemented threads, but the additional OS threads must not call any scheme_ function. Only the OS thread representing a particular place can call scheme_ functions. (This restriction is stronger than saying all calls for a given place must be serialized across threads. Racket relies on properties of specific threads to avoid stack overflow and garbage collection.) For the original place, only the OS thread used to call scheme_basic_env can call scheme_ functions. For any other place, only the OS thread that is created by Racket for the place can be used to call scheme_ functions. So: yes, it was in there. Would it make sense to add a sentence to the beginning of Section 8, Threads, that reads (This section describes Racket threads. For information on OS threads, see Racket and OS Threads) ... and rename Inside/1.6, Racket and Threads, to Racket and OS Threads ? I suppose this means there's no platform-independent synchronization mechanism? Anyhow, this is clearly not your problem. Thanks! John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] foreign struct access different in 5.1.3?
I'll do that. Kevin On 09/17/2011 07:53 AM, Matthew Flatt wrote: At Sat, 17 Sep 2011 07:44:50 -0600, Kevin Tew wrote: If you would like document the fact that cstructs are generative only up to version 5.1.3. I think that improve the docs. I think the right next step is for you (Kevin) to update doc/release-notes/racket/HISTORY.txt to describe the change. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] FYI crash in os X cairo
Disregard unless interested: crash while running program, drracket #8e5bb730b369b169821695e1b3216d68a8d71d64 from Friday 16th. Process: racket [11531] Path:/Users/clements/plt/bin/racket Identifier: racket Version: ??? (???) Code Type: X86-64 (Native) Parent Process: bash [537] Date/Time: 2011-09-17 10:09:10.294 -0700 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Interval Since Last Report: 138200 sec Crashes Since Last Report: 17 Per-App Crashes Since Last Report: 17 Anonymous UUID: 2B5B5A13-9161-4495-BE51-9AEEEA441DE8 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x00010001 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 com.apple.CoreGraphics 0x7fff82f030aa CGGStateTextCopy + 47 1 com.apple.CoreGraphics 0x7fff82f02f53 CGGStateCreateCopy + 101 2 com.apple.CoreGraphics 0x7fff82f02ecb CGGStackSave + 65 3 com.apple.CoreGraphics 0x7fff82f02e7f CGContextSaveGState + 65 4 libcairo.2.dylib0x00010500787a _cairo_quartz_surface_fill + 202 5 libcairo.2.dylib0x000104feb494 _cairo_surface_fill + 180 6 libcairo.2.dylib0x000104fc4a1f _cairo_gstate_fill + 479 7 libcairo.2.dylib0x000104fbb1f3 cairo_fill_preserve + 35 8 Racket 0x000100293a6c ffi_call_unix64 + 76 9 Racket 0x000100294684 ffi_call + 644 10 Racket 0x000100286a6b ffi_do_call + 1371 11 Racket 0x00010005d33d scheme_do_eval + 10557 12 Racket 0x00010005fc3f _scheme_apply_multi_from_native + 95 13 ??? 0x0001004e3f40 0 + 4300095296 14 ??? 0x00011ba9d67e 0 + 4759082622 15 ??? 0x0001004fa930 0 + 4300187952 16 ??? 0x0001004fa930 0 + 4300187952 17 Racket 0x00010005d0d5 scheme_do_eval + 9941 18 Racket 0x000100077305 scheme_dynamic_wind + 1029 19 Racket 0x000100077a71 dynamic_wind + 321 20 ??? 0x0001013d759d 0 + 4315772317 21 ??? 0x0001013d55d0 0 + 4315764176 22 ??? 0x0001004e3b10 0 + 4300094224 23 ??? 0x0001004e3b10 0 + 4300094224 24 Racket 0x00010005d0d5 scheme_do_eval + 9941 25 Racket 0x00010005fc3f _scheme_apply_multi_from_native + 95 26 ??? 0x0001004e3f40 0 + 4300095296 27 ??? 0x0001004e3b10 0 + 4300094224 28 Racket 0x00010005d0d5 scheme_do_eval + 9941 29 Racket 0x000100078c49 scheme_finish_apply_for_prompt + 873 30 Racket 0x000100078e1c scheme_apply_for_prompt + 92 31 Racket 0x000100085612 call_with_prompt + 1282 32 ??? 0x0001004d9215 0 + 4300050965 33 Racket 0x00010005d0d5 scheme_do_eval + 9941 34 Racket 0x000100078c49 scheme_finish_apply_for_prompt + 873 35 Racket 0x000100078e1c scheme_apply_for_prompt + 92 36 Racket 0x000100085612 call_with_prompt + 1282 37 ??? 0x0001004e3cc5 0 + 4300094661 38 Racket 0x00010005d0d5 scheme_do_eval + 9941 39 Racket 0x000100070e94 force_values + 292 40 Racket 0x00010007afb2 scheme_force_value_same_mark + 114 41 ??? 0x0001004e3719 0 + 4300093209 42 Racket 0x00010005d0d5 scheme_do_eval + 9941 43 Racket 0x00010005fc3f _scheme_apply_multi_from_native + 95 44 ??? 0x0001004d9142 0 + 4300050754 45 Racket 0x00010005d0d5 scheme_do_eval + 9941 46 Racket 0x00010007ae33 apply_k + 179 47 Racket 0x00010007bac6 scheme_top_level_do_worker + 1222 48 racket 0x000133fe finish_cmd_line_run + 3598 49 racket 0x00014051 main_after_stack + 2753 50 Racket
Re: [racket-dev] [plt] Push #23561: master branch updated
I think you are missing a test case here. Robby On Sat, Sep 17, 2011 at 9:39 PM, gmarc...@racket-lang.org wrote: gmarceau has updated `master' from 14014b3d36 to 9b49de16e7. http://git.racket-lang.org/plt/14014b3d36..9b49de16e7 =[ 1 Commits ]== Directory summary: 100.0% collects/lang/private/ ~~ 9b49de1 Guillaume Marceau gmarc...@racket-lang.org 2011-09-17 22:37 : | Fixed 'reference to an identifier before its definition' error in *SL. : M collects/lang/private/rewrite-error-message.rkt | 2 ++ =[ Overall Diff ]=== collects/lang/private/rewrite-error-message.rkt ~~~ --- OLD/collects/lang/private/rewrite-error-message.rkt +++ NEW/collects/lang/private/rewrite-error-message.rkt @@ -58,6 +58,8 @@ (list #rxprocedure application: expected procedure, given: (.*); arguments were:.* (lambda (all one) (format function call: expected a function after the open parenthesis, but received ~a one))) + (list #rxreference to an identifier before its definition: (.*) + (lambda (all one) (format ~a is used here before its definition one))) (list #rxexpects argument of type (([^]+)) (lambda (all one two) (format expects a ~a two))) (list #rxexpected argument of type (([^]+)) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Code compiled for version ~a, not ~a
On Sat, Sep 17, 2011 at 11:11 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Whoops, I see we lost the mailing list at some point in this thread. We're back now. If the former, then those are the directories that DrRacket intentionally doens't compile (and those are the ones that I'd expect you to have multiple copies of). That's pretty subtle. I don't remember seeing a notice of this in the documentation. Is it somewhere and I didn't stumble on it? It might be worth changing the behavior or the error message to make the behavior more discoverable. Does this mean that you added it to the directory that's listed first in the PLTCOLLECTS variable or that you added a second path to that variable? It breaks both ways, with export PLTCOLLECTS=';c:\documents\collects' and with export PLTCOLLECTS='c:\documents\collects;' If the latter, what does #lang racket/base (require setup/dirs) (find-collects-dir) produce on your machine? (And what is PLTCOLLECTS)? It produced #path:C:\documents\projects\plt\collects , which is where my git repository is. In case it is useful, (current-library-collection-paths) produces: '(#path:C:\Documents and Settings\gmarceau\Application Data\Racket\5.1.3.9\collects #path:C:\documents\projects\plt\collects #path:c:\documents\collects) When logging-tool is linked with raco, the error doesn't occur at lunch because DrRacket doesn't attempt loads tools the linked collects. It is supposed to. So maybe something is wrong there too. ah, ok. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
