Re: [racket-dev] [racket] Profiling mostly macro-generated definitions?
At Fri, 31 Aug 2012 07:35:12 -0600, Matthew Flatt wrote: Sorry that I've been slow to catch on in this thread... Yes, stack traces in JIT mode don't really work in Win64, and that's why `profile' gives no information. I'll try to improve Win64 context support sometime soon. I forgot to report back: Win64 context support should work in the latest (including in the currently nightly build). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What are single flonums good for?
On 09/16/2012 04:10 PM, Matthias Felleisen wrote: Suppose we had started Racket long ago and maintained it until now. Then we'd be looking at 8bit, 16, 32, and 64 precision. In some N years from now, we may need 128. (Actually there were machines in the past that did, but never mind.) Could we separate precision and type into separate dimensions so that we could state types like this: ∀ p : precision. FP[p] - FP[p] where we see FP as a type constructor that consumes a precision value to generate the right kind of type. This might be a dependent type but it could be a useful one. Of course, it isn't really a parametric form of polymorphism as Neil's functions show (and better still Vincent's rewrites). 80-bit, and then 128-bit flonums are inevitable. After TR has type classes or something like them, this would work really well. The C++ Boost libraries use templates to achieve something similar. Functions with an FPU implementation (sin, exp, etc.) just dispatch to the proper bare-metal function. Functions without an FPU implementation (gamma, erf, etc.) also dispatch depending on precision, but can share implementation details when the algorithms are similar. (Example: the gamma function uses a different Lanczos polynomial for each precision, but always uses it in the same way.) Compositions of either kind are fully polymorphic. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket Questions?
I'll implement `flmodulo' in the math library, which already has `flodd?' and `fleven?'. These things can be tricky to get right; for example, most people wouldn't notice that their implementation is wrong on negative inputs. I'll probably also do `flremainder'. Neil ⊥ On 09/15/2012 12:45 PM, Michael Wilber wrote: For the record, I've always just defined my own modulo when I need it for floats: ; A modulo operator for floats! (define (float-modulo p q) (- p (* q (truncate (/ p q) It doesn't properly handle negative numbers though. David Van Horn dvanh...@ccs.neu.edu writes: On 9/14/12 3:36 PM, Becca MacKenzie wrote: Hello! So a friend of mine just started learning Racket and was wondering if there's a particular reason why the modulo function in racket only takes in integers? He wrote his own mod function to take in other things but he was just wondering what the reasoning is behind this. Hi Becca, Excellent question -- I hope you don't mind that I've forwarded it to the Racket developers list for a more authoritative answer (and potentially a change to Racket). I don't believe there's any principled reason not to extend `modulo' to other kinds of numbers such as rationals and (exact) complex numbers. I worry that the idea of modulo may not be well defined for inexact numbers, but I could be wrong (inexact numbers don't obey a lot of the usual mathematical properties we're used to). I see that in Mathematica, the arguments of Mod can be any numeric quantities, not necessarily integers. Here are some examples: http://reference.wolfram.com/mathematica/ref/Mod.html#6881 Recently, Racket's GCD and LCM were extended to work on non-integer arguments, and I believe this is a similar case where the function could (and should?) be extended to work for more kinds of numbers. But I'm interested to hear what the dev list has to say on the matter. David _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Is this expected behavior?
On a freshly pulled and compiled racket: jordan@serenity ~ racket Welcome to Racket v5.3.0.24. (enter! slideshow/pict) define-values: assignment disallowed; cannot re-define a constant constant: invoke-unit/core in module: /usr/local/lib/racket/collects/racket/unit.rkt context...: /usr/local/lib/racket/collects/racket/unit.rkt: [running body] standard-module-name-resolver /usr/local/lib/racket/collects/mzlib/unit.rkt: [traversing imports] /usr/local/lib/racket/collects/texpict/mrpict.rkt: [traversing imports] /usr/local/lib/racket/collects/slideshow/pict.rkt: [traversing imports] /usr/local/lib/racket/collects/racket/enter.rkt:51:0: enter-require /usr/local/lib/racket/collects/racket/enter.rkt:33:0: do-enter! /usr/local/lib/racket/collects/racket/private/misc.rkt:87:7 I think it has to do with the new module system? - Jordan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What are single flonums good for?
At Sun, 16 Sep 2012 17:10:01 -0500, Matthias Felleisen wrote: Suppose we had started Racket long ago and maintained it until now. Then we'd be looking at 8bit, 16, 32, and 64 precision. In some N years from now, we may need 128. (Actually there were machines in the past that did, but never mind.) Could we separate precision and type into separate dimensions so that we could state types like this: ∀ p : precision. FP[p] - FP[p] where we see FP as a type constructor that consumes a precision value to generate the right kind of type. This might be a dependent type but it could be a useful one. Of course, it isn't really a parametric form of polymorphism as Neil's functions show (and better still Vincent's rewrites). I think row types can give us that, and clean up other parts of the numeric tower, too. That's something we've been thinking about for some time. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax parsing: must be a nice pattern-y way to do this
On Sep 16, 2012, at 5:48 PM, Ryan Culpepper wrote: See 'define-template-metafunction' in syntax/parse/experimental/template. Remember to change the relevant occurrences of 'syntax' to 'template'. Neat! I'm guessing, though, that I probably shouldn't release planet packages that depend on experimental-mumble… John Ryan On 09/16/2012 08:31 PM, John Clements wrote: I want to apply a transformation to a nested pattern element. To start with, suppose I have a (kind of useless) with-handlers that looks like this: (with-syntax ([((arg ...) ...) #`((clause.input ...) ...)]) et-cetera) That is, I've basically just renamed clause.input to arg. But now, I want to perform some transformation on the elements. I'd like to write this: (with-syntax ([((arg ...) ...) #`((#,(transform #'clause.input) ...) ...)]) et-cetera) .. but this fails, with the error new-style-signals.rkt:42:30: syntax: missing ellipsis with pattern variable in template in: clause.input I can certainly work around this, by abandoning the pattern-matching slickness and just using a bunch of syntax-lists, but it seems like there must be a nicer way. Am I missing some nifty trick? John _ Racket Developers list: http://lists.racket-lang.org/dev smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Is this expected behavior?
On 2012-09-17 11:39:55 -0600, Jordan Schatz wrote: On a freshly pulled and compiled racket: This is a known bug, see PR 13096: http://bugs.racket-lang.org/query/?cmd=viewpr=13096 It does indeed seem to be an issue with submodules, but the precise problem is hard to track down. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax parsing: must be a nice pattern-y way to do this
On 09/17/2012 02:20 PM, John Clements wrote: On Sep 16, 2012, at 5:48 PM, Ryan Culpepper wrote: See 'define-template-metafunction' in syntax/parse/experimental/template. Remember to change the relevant occurrences of 'syntax' to 'template'. Neat! I'm guessing, though, that I probably shouldn't release planet packages that depend on experimental-mumble… I think it's fine if you're prepared to update the package when it changes. If I do remove syntax/parse/experimental/template, I'll mark it as deprecated for a release cycle or two first. Ryan On 09/16/2012 08:31 PM, John Clements wrote: I want to apply a transformation to a nested pattern element. To start with, suppose I have a (kind of useless) with-handlers that looks like this: (with-syntax ([((arg ...) ...) #`((clause.input ...) ...)]) et-cetera) That is, I've basically just renamed clause.input to arg. But now, I want to perform some transformation on the elements. I'd like to write this: (with-syntax ([((arg ...) ...) #`((#,(transform #'clause.input) ...) ...)]) et-cetera) .. but this fails, with the error new-style-signals.rkt:42:30: syntax: missing ellipsis with pattern variable in template in: clause.input I can certainly work around this, by abandoning the pattern-matching slickness and just using a bunch of syntax-lists, but it seems like there must be a nicer way. Am I missing some nifty trick? John _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax parsing: must be a nice pattern-y way to do this
On Sep 17, 2012, at 11:27 AM, Ryan Culpepper wrote: On 09/17/2012 02:20 PM, John Clements wrote: On Sep 16, 2012, at 5:48 PM, Ryan Culpepper wrote: See 'define-template-metafunction' in syntax/parse/experimental/template. Remember to change the relevant occurrences of 'syntax' to 'template'. Neat! I'm guessing, though, that I probably shouldn't release planet packages that depend on experimental-mumble… I think it's fine if you're prepared to update the package when it changes. If I do remove syntax/parse/experimental/template, I'll mark it as deprecated for a release cycle or two first. I'm still not quite sold. In particular, I have students writing code against this planet package, and I've just recently had a situation where a student wanted to run his old code, and I was happy to be able to tell him to qualify his planet reference so as to avoid having to update his code; relying on a feature that later disappears reduces the chance that students will be able to run their code as-is three years from now. I really don't mean to be persnickety, here: another motivation is that I've already bitten the bullet and written the code that doesn't require define-template-metafunction :). John Ryan On 09/16/2012 08:31 PM, John Clements wrote: I want to apply a transformation to a nested pattern element. To start with, suppose I have a (kind of useless) with-handlers that looks like this: (with-syntax ([((arg ...) ...) #`((clause.input ...) ...)]) et-cetera) That is, I've basically just renamed clause.input to arg. But now, I want to perform some transformation on the elements. I'd like to write this: (with-syntax ([((arg ...) ...) #`((#,(transform #'clause.input) ...) ...)]) et-cetera) .. but this fails, with the error new-style-signals.rkt:42:30: syntax: missing ellipsis with pattern variable in template in: clause.input I can certainly work around this, by abandoning the pattern-matching slickness and just using a bunch of syntax-lists, but it seems like there must be a nicer way. Am I missing some nifty trick? John _ Racket Developers list: http://lists.racket-lang.org/dev smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Segmentation fault 11?
I'm seeing weirdness when trying to import Dave Herman's memoize package on Racket 5.3: ;;; (require (planet dherman/memoize:3:1)) WARNING: collected information for key multiple times: '(index-entry (mod-path (planet schematics/sake))); values: Segmentation fault: 11 ;;; I'm on a Macbook Air running 10.7. The following includes the stack trace I'm seeing under gdb. What else can I do to help with debugging information? # (gdb) 204-99-169-77:~ dyoo$ gdb racket GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC 2012) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-apple-darwin...Reading symbols for shared libraries ... done (gdb) handle SIGSEGV nostop noprint SignalStop Print Pass to program Description SIGSEGV NoNo Yes Segmentation fault (gdb) run Starting program: /Applications/Racket v5.3/bin/racket Welcome to Racket v5.3. (require (planet dherman/memoize:3:1)) Reading symbols for shared libraries .. done Reading symbols for shared libraries . done WARNING: collected information for key multiple times: '(mod-path (planet schematics/sake)); values: '#((Build files) (mod-path (planet schematics/sake)) (2) #path:/Users/dyoo/Library/Racket/planet/300/5.3/cache/schematics/sake.plt/1/0/doc/sake/Build_files.html #t) '#((The Sake API) (mod-path (planet schematics/sake)) (3) #path:/Users/dyoo/Library/Racket/planet/300/5.3/cache/schematics/sake.plt/1/0/doc/sake/The_Sake_API.html #t) WARNING: collected information for key multiple times: '(index-entry (mod-path (planet schematics/sake))); values: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x2566d2f4 0x002142fb in chaperone_struct_ref () (gdb) bt #0 0x002142fb in chaperone_struct_ref () #1 0x001ad91c in setup_graph_table () #2 0x001ad934 in setup_graph_table () #3 0x001ad74b in setup_graph_table () #4 0x001ad934 in setup_graph_table () #5 0x001ad74b in setup_graph_table () #6 0x001ad74b in setup_graph_table () #7 0x001ad6c0 in setup_graph_table () #8 0x001b6efb in print_to_string () #9 0x001b7d55 in print_to_string_k () #10 0x00075b1e in scheme_top_level_do_worker () #11 0x00075d48 in scheme_top_level_do () #12 0x0004743d in error_write_to_string_w_max () #13 0x00047566 in scheme_make_provided_string () #14 0x001fd398 in scheme_do_format () #15 0x001fd9b7 in sch_eprintf () #16 0x00367d6d in ?? () #17 0x0007bf7f in _apply_native () #18 0x0008206d in scheme_apply_chaperone () #19 0x0006043b in _scheme_apply_multi_from_native () #20 0x011f663c in ?? () #21 0x0005ccfe in scheme_do_eval () #22 0x00060329 in _scheme_apply_multi_from_native () #23 0x011f89a8 in ?? () #24 0x0005ccfe in scheme_do_eval () #25 0x00060529 in _scheme_apply_from_native () #26 0x00366f20 in ?? () #27 0x00357ac4 in ?? () #28 0x0005ccfe in scheme_do_eval () #29 0x00060329 in _scheme_apply_multi_from_native () #30 0x00367962 in ?? () #31 0x00357ac4 in ?? () #32 0x0005ccfe in scheme_do_eval () #33 0x0007d718 in scheme_finish_apply_for_prompt () #34 0x0007d8cc in scheme_apply_for_prompt () #35 0x0008838f in call_with_prompt () #36 0x003509d3 in ?? () #37 0x003551d4 in ?? () #38 0x00356e84 in ?? () #39 0x0005ccfe in scheme_do_eval () #40 0x0007d718 in scheme_finish_apply_for_prompt () #41 0x0007d8cc in scheme_apply_for_prompt () #42 0x0008838f in call_with_prompt () #43 0x003509d3 in ?? () #44 0x011f6364 in ?? () #45 0x0005ccfe in scheme_do_eval () #46 0x000760ba in apply_k () #47 0x00075c78 in scheme_top_level_do_worker () #48 0x00075ee4 in scheme_apply_thread_thunk () #49 0x00243c4d in start_child () #50 0x00247b5d in make_subprocess () #51 0x00247d96 in scheme_thread_w_details () #52 0x00247c5b in scheme_thread_w_details () Previous frame inner to this frame (gdb could not unwind past this frame) _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Top level is hopeless or bug?
Hi all, Is the following interaction the expected behavior here or is it a bug? Welcome to Racket v5.3.0.24. - (module foo racket (define x 0) (provide x)) - (require 'foo) - x 0 - (module foo racket (module* bar #f (define x 1) (provide x))) - x ; readline-input:4:0: link: module mismatch; ; possibly, bytecode file needs re-compile because dependencies changed ; exporting module: 'foo ; exporting phase level: 0 ; internal explanation: variable not provided (directly or indirectly) ; in: x ; [,bt for context] This is also interesting: Welcome to Racket v5.3.0.24. - (module foo racket (define x 0) (provide x)) - (require 'foo) - x 0 - (module foo racket (define x 1) (provide x)) ; define-values: assignment disallowed; ; cannot re-define a constant ; constant: x ; in module: 'foo ; [,bt for context] - x 1 Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
