Re: [racket-users] listing the identifiers from "all-defined-out" and "all-from-out"
You might also like `filtered-out` from `racket/provide` [1]. The code sample below prints two identifiers (at compile-time): a:x y [1] http://docs.racket-lang.org/reference/require.html#%28mod-path._racket%2Fprovide%29 #lang racket/base (module a racket/base (provide x) (define x 1)) (require 'a) (require racket/provide) (require (for-syntax racket/base)) (define y 4) (define-for-syntax (print-provide str) (displayln str) str) (provide (filtered-out print-provide (prefix-out a: (all-from-out 'a))) (filtered-out print-provide (all-defined-out))) On Tue, Dec 22, 2015 at 5:21 PM, Asumu Takikawa wrote: > On 2015-12-18 17:27:54 -0800, Sanjeev Sharma wrote: > > how can I get lists of identifiers im/exported when one uses > > > > all-defined-out > > all-from-out > > > > I can't yet make sense of regprov.rkt > > Do you mean how can you tell what's exported given a particular module > someone > has written? Or do you mean something more specific? > > For the former, you can just call `module->exports` to get a list of > exports: > > -> (require data/gvector) > -> (module->exports 'data/gvector) > '() > '((0 > (for*/gvector ()) > (for/gvector ()) > (gvector ()) > (gvector->list ()) > (gvector->vector ()) > (gvector-add! ()) > (gvector-count ()) > (gvector-ref ()) > (gvector-remove! ()) > (gvector-remove-last! ()) > (gvector-set! ()) > (gvector? ()) > (in-gvector ()) > (make-gvector ( > > Cheers, > Asumu > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Can scribble/lp2 typeset comments within chunks?
I'm a scribble/lp2 noob for sure, but why not eliminate the need for `code:comment` within a `chunk`? Because I find this curious: when the `chunk` is typeset in documentation mode, scribble/lp2 is apparently parsing the comments, because they get converted to whitespace. So ... instead of converting them to whitespace, why not just typeset them literally? Noob question complete On Dec 22, 2015, at 2:45 PM, Asumu Takikawa wrote: > On 2015-12-18 12:20:13 -0800, Matthew Butterick wrote: >> Third try: also tried scribble/comment-reader [2] but this doesn't work >> (apparently because `racketblock` knows about `code:comment` but `chunk` does >> not: > > I think things like `code:comment` are intended to work, but don't because > they're > not bound to anything within chunk blocks. For example, this works: > > #lang scribble/lp2 > > @chunk[prologue > (define code:comment 3)] > > @CHUNK[<*> > prologue > (define (f x) ; not g > (code:comment "foo") > (* x x))] > > But this typesets the silly definition of `code:comment` too. Maybe the > scribble/lp2 language should bind these forms in chunk blocks. (UNSYNTAX > doesn't work for the same reason) > > Cheers, > Asumu -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Confused about the difference between the REPL and the toplevel.
Okay, thank you for the explanation. I totally see what you mean now by the top level being hopeless. (Or at least I think I do.) It seems there is no way to get a meaning that does everything we would want it to... As a side not Matthew, I notice that you seem to be sending out two identical emails every time you send out an email. If memory serves you use Mr Ed, right? I wonder if that might be a bug. ~Leif Andersen On Tue, Dec 22, 2015 at 6:54 AM, Robby Findler wrote: > Oh right. Sorry for the confusion! > > Robby > > > On Tuesday, December 22, 2015, Matthew Flatt wrote: >> >> I think Robby was confused by your example (which is understandable). >> >> The `expand` function does not splice any differently than `compile`, >> so `compile` behaves the same as `expand` in your example: >> >> > (eval (compile #'(begin >> (define-syntax (foo stx) >> (displayln "hello") >> #'5) >> foo))) >> foo: undefined; >> cannot reference undefined identifier >>context...: >> /Users/mflatt/plt/racket/collects/racket/private/misc.rkt:87:7 >> > (compile #'(begin >> (define-syntax (foo stx) >> (displayln "goodbye") >> #'5) >> foo)) >> hello >> #~ >> >> >> I think Robby was just confused by your example, because he's used to >> starting with a fresh REPL. :) >> >> At Mon, 21 Dec 2015 22:16:44 -0700, Leif Andersen wrote: >> > Wait, now I'm even more confused. If expand does the splicing and >> > compile time evals song and dance, why do we need a separate function >> > for: >> > >> > expand-syntax-top-level-with-compile-time-evals >> > >> > ? >> > >> > ~Leif Andersen >> > >> > >> > On Mon, Dec 21, 2015 at 9:48 PM, Robby Findler >> > wrote: >> > > I believe that's because expand does the splicing dance, but compile >> > > doesn't (which is why you need the funny-named function ... "need" is >> > > perhaps a poor choice of words here :). >> > > >> > > Robby >> > > >> > > >> > > On Mon, Dec 21, 2015 at 10:30 PM, Leif Andersen >> > > >> > wrote: >> > >> Ah, that's a good question. One that I don't really know the answer >> > >> too, because when I do: >> > >> >> > >>> (compile #'(begin >> > >>(define-syntax (foo stx) >> > >> (displayln "hello") >> > >> #'5) >> > >>foo)) >> > >> >> > >> I get back the compiled object. Also foo is not displayed. And when I >> > >> do: >> > >> >> > >> > (eval (compile #'(begin >> > >>(define-syntax (foo stx) >> > >> (displayln "hello") >> > >> #'5) >> > >>foo))) >> > >> >> > >> I get the error: >> > >> >> > >> foo: undefined; >> > >> cannot reference an identifier before its definition >> > >> >> > >> But, when I do: >> > >> >> > >>> (expand #'(begin >> > >>(define-syntax (foo stx) >> > >> (displayln "hello") >> > >> #'5) >> > >>foo)) >> > >> >> > >> It displays 'hello' to the console. And expands to what I would >> > >> expect it >> > too. >> > >> >> > >> ~Leif Andersen >> > >> >> > >> >> > >> On Mon, Dec 21, 2015 at 9:15 PM, Alex Knauth >> > >> wrote: >> > >>> >> > On Dec 21, 2015, at 10:53 PM, Leif Andersen >> > wrote: >> > >>> >> > But `compile` is not supposed to evaluate any code, it just >> > compiles >> > it. Which is why it fails to compile that code. But if you >> > interleave >> > it with evals, it will run the require code, which gives the phase >> > level 2 code some meaning. >> > >>> >> > >>> I understand that `compile` isn't supposed to evaluate any _runtime_ >> > >>> code, >> > but I thought it had to evaluate the compile-time code for it to compile >> > the >> > program? >> > >>> >> > >>> Am I misunderstanding what `compile` is supposed to do? Or what >> > compile-time code is, or? >> > >>> >> > Does that make any sense, or was it too rambly. >> > >> > ~Leif Andersen >> > >> > >> > On Mon, Dec 21, 2015 at 8:24 PM, Alex Knauth >> > wrote: >> > > I get that `compile` doesn't evaluate the require form, but why >> > > doesn't >> > it evaluate what's needed for compile time? I thought that was the >> > reason for >> > needing require as a macro instead of a function. Or am I getting the >> > purpose >> > of compile wrong? >> > > >> > > Alex Knauth >> > > >> > >> On Dec 21, 2015, at 7:47 PM, Matthew Flatt >> > >> wrote: >> > >> >> > >> In the REPL, `begin` splices at the granularity of expansion and >> > >> evaluation. That is, the first of the two forms grouped by >> > >> `begin` is >> > >> compiled and evaluated, and only afterward the second one is >> > >> compiled >> > >> and evaluated. >> > >> >> > >> The `compile` function can't do that, because it's only supposed >> > >
Re: [racket-users] Can scribble/lp2 typeset comments within chunks?
On 2015-12-18 12:20:13 -0800, Matthew Butterick wrote: > Third try: also tried scribble/comment-reader [2] but this doesn't work > (apparently because `racketblock` knows about `code:comment` but `chunk` does > not: I think things like `code:comment` are intended to work, but don't because they're not bound to anything within chunk blocks. For example, this works: #lang scribble/lp2 @chunk[prologue (define code:comment 3)] @CHUNK[<*> prologue (define (f x) ; not g (code:comment "foo") (* x x))] But this typesets the silly definition of `code:comment` too. Maybe the scribble/lp2 language should bind these forms in chunk blocks. (UNSYNTAX doesn't work for the same reason) Cheers, Asumu -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] listing the identifiers from "all-defined-out" and "all-from-out"
On 2015-12-18 17:27:54 -0800, Sanjeev Sharma wrote: > how can I get lists of identifiers im/exported when one uses > > all-defined-out > all-from-out > > I can't yet make sense of regprov.rkt Do you mean how can you tell what's exported given a particular module someone has written? Or do you mean something more specific? For the former, you can just call `module->exports` to get a list of exports: -> (require data/gvector) -> (module->exports 'data/gvector) '() '((0 (for*/gvector ()) (for/gvector ()) (gvector ()) (gvector->list ()) (gvector->vector ()) (gvector-add! ()) (gvector-count ()) (gvector-ref ()) (gvector-remove! ()) (gvector-remove-last! ()) (gvector-set! ()) (gvector? ()) (in-gvector ()) (make-gvector ( Cheers, Asumu -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] backwards incompatible change to redex: does it break your models?
On Sun, Dec 20, 2015 at 08:42:25PM -0600, Robby Findler wrote: > The reason the "E_1" and the "e_1" are treated differently is that the > "e" is mentioned in "binding" position of the shortcut. That is what > makes it special. Does this make sense? Yes, thank you. > (Have a read of the paragraph > in the redex docs for reduction-semantics that talks about shortcuts > and let me know if it makes more sense now and, even better, if you > have any suggestions for edits!) I read through the documentation at http://pkg-build.racket-lang.org/doc/redex/The_Redex_Reference.html?q=reduction-relation#(mod-path._redex/reduction-semantics). The closest paragraph I can see to talking about this seems out of date. "Each shortcut clause defines arrow names in terms of base-arrow-name and earlier shortcut definitions. The left- and right-hand sides of a shortcut definition are identifiers, not patterns and terms. These identifiers need not correspond to non-terminals in language." Of course now, the last sentence requires s/need not/must not/. I would also add a final sentence such as "Therefore, the output of the shortcut is not checked against the syntax of any non-terminal." > What if I were to actually make it do what people seem to think it > does, in the case that the chosen name is a non-terminal? So, if you > write a shortcut whose name is NOT a non-terminal, say "x" then it > would be like you wrote "any_x". And if you used a non-terminal, then > the shortcut would apply only when the expression actually matches the > corresponding non-terminal. Redex would still have to insist that the > parameters to the shortcuts are identifiers, but I could add in that > restriction? > > This is also backwards incompatible, but in a different way, tho. So > that's slightly worrying. This form of backwards incompatibility has > the downside that it will just make things stop reducing instead of > getting a syntax error. So we'd have to like it a LOT to go this way. The fact that it will cause previously good code to fail silently is rather unacceptable. Although, I think this changed behavior is preferable because it matches the behavior of much of the rest of Redex, and matches what people seem to except. Perhaps a different syntax for this changed version of shortcut, and deprecating the current version? -- William J. Bowman -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. pgpoJU_ugC6C7.pgp Description: PGP signature
Re: [racket-users] DrRacket crashes on simple pict3d script
On Tuesday, December 22, 2015 at 3:32:20 PM UTC+1, Robby Findler wrote:
> Hi Greg: just in case it wasn't obvious, Jay also needed to upgrade
> his Racket to a version that's newer than 6.3. You can find our
> snapshot builds here if you want to try that:
>
> http://pre.racket-lang.org/installers/
>
> Robby
>
Thanks Robby - it wasn't obvious to me and updating to newest snapshot 6.3.0.8
resolved the issue.
Thanks Jay for fixing it!
Just in case you still need here is the output of the shaders tests:
Compiling shaders from pict3d/private/engine/draw/draw-passes
Compiling (program-code "fullscreen-program" (vertex-code
"fullscreen-vertex" '() '() '() '() (list (attribute "" 'vec2 "vert_position")
(attribute "" 'vec2 "vert_texcoord")) #0=(list (attribute "smooth" 'vec2
"frag_texcoord")) "gl_Position = vec4(vert_position, ...
Compiling (program-code "fullscreen-depth-program" (vertex-code
"fullscreen-vertex" '() '() '() '() (list (attribute "" 'vec2 "vert_position")
(attribute "" 'vec2 "vert_texcoord")) #0=(list (attribute "smooth" 'vec2
"frag_texcoord")) "gl_Position = vec4(vert_posi...
Compiling (program-code "fullscreen-alpha-program" (vertex-code
"fullscreen-vertex" '() '() '() '() (list (attribute "" 'vec2 "vert_position")
(attribute "" 'vec2 "vert_texcoord")) #0=(list (attribute "smooth" 'vec2
"frag_texcoord")) "gl_Position = vec4(vert_posi...
Compiling (program-code "blend-program" (vertex-code
"fullscreen-vertex" '() '() '() '() (list (attribute "" 'vec2 "vert_position")
(attribute "" 'vec2 "vert_texcoord")) #0=(list (attribute "smooth" 'vec2
"frag_texcoord")) "gl_Position = vec4(vert_position, 0, 1)...
Compiling (program-code "bloom-extract-program" (vertex-code
"fullscreen-vertex" '() '() '() '() (list (attribute "" 'vec2 "vert_position")
(attribute "" 'vec2 "vert_texcoord")) #0=(list (attribute "smooth" 'vec2
"frag_texcoord")) "gl_Position = vec4(vert_positio...
Compiling (program-code "bloom-combine-program" (vertex-code
"fullscreen-vertex" '() '() '() '() (list (attribute "" 'vec2 "vert_position")
(attribute "" 'vec2 "vert_texcoord")) #0=(list (attribute "smooth" 'vec2
"frag_texcoord")) "gl_Position = vec4(vert_positio...
Compiling (program-code "blur-vert-program" (vertex-code
"fullscreen-vertex" '() '() '() '() (list (attribute "" 'vec2 "vert_position")
(attribute "" 'vec2 "vert_texcoord")) #0=(list (attribute "smooth" 'vec2
"frag_texcoord")) "gl_Position = vec4(vert_position, 0...
Compiling (program-code "blur-horz-program" (vertex-code
"fullscreen-vertex" '() '() '() '() (list (attribute "" 'vec2 "vert_position")
(attribute "" 'vec2 "vert_texcoord")) #0=(list (attribute "smooth" 'vec2
"frag_texcoord")) "gl_Position = vec4(vert_position, 0...
Compiling shaders from pict3d/private/gui/shape/light-grid
Compiling (program-code "light-grid-program" (vertex-code
"light-grid-vertex" '() '() (list (standard-uniform "" 'mat4 "unproj" 'unproj)
(standard-uniform "" 'int "width" 'width) (standard-uniform "" 'int "height"
'height)) '() (list (attribute "" 'float/byte "ve...
Compiling shaders from pict3d/private/gui/shape/point-light-shell
Compiling (program-code "point-light-shell-program" (vertex-code
"point-light-shell-vertex" (list (partial-code "output-impostor-vertex" (list
#1=(partial-code "rect" '() '("struct rect {\n vec3 mins;\n vec3 maxs;\n
float is_degenerate;\n};") '() '() '() '()) ...
Compiling shaders from pict3d/private/shape/directional-light
Compiling (program-code "directional-light-program" (vertex-code
"directional-light-vertex" '() '() (list (standard-uniform "" 'mat4 "unproj"
'unproj)) '() (list (attribute "" 'float/byte "vert_id")) #0=(list (attribute
"smooth" 'vec3 "frag_dir")) "// output the ...
Compiling shaders from pict3d/private/shape/cylinder
Compiling (program-code "cylinder-mat-program-30" (vertex-code
"cylinder-mat-vertex-30" (list (partial-code "output-unit-cube-vertex" '()
'("void output_unit_cube_vertex2(mat4 trans, mat4 proj, int vertex_id) {\n
vec4 p = vec4(mix(-1.0, +1.0, float(vertex_id & 1...
Compiling (program-code "cylinder-opaq-program-30" (vertex-code
"cylinder-draw-vertex-30" (list (partial-code "output-unit-cube-vertex" '()
'("void output_unit_cube_vertex2(mat4 trans, mat4 proj, int vertex_id) {\n
vec4 p = vec4(mix(-1.0, +1.0, float(vertex_id &...
Compiling (program-code "cylinder-tran-program-30" (vertex-code
"cylinder-draw-vertex-30" (list (partial-code "output-unit-cube-vertex" '()
'("void output_unit_cube_vertex2(mat4 trans, mat4 proj, int vertex_id) {\n
vec4 p = vec4(mix(-1.0, +1.0, float(vertex_id &...
Compiling shaders from pict3d/private/shape/disk
Compiling (program-code "disk-mat-program-30" (vertex-code
"disk-mat-vertex-30" (list (partial-code "output-unit-quad-vertex" '() '("void
output_unit_quad_vertex2(mat4 trans, mat4 proj, int vertex_id) {\n vec4 p =
vec4(mix(-1.0,
Re: [racket-users] DrRacket crashes on simple pict3d script
Hi Greg: just in case it wasn't obvious, Jay also needed to upgrade his Racket to a version that's newer than 6.3. You can find our snapshot builds here if you want to try that: http://pre.racket-lang.org/installers/ Robby On Tue, Dec 22, 2015 at 7:52 AM, Greg Trzeciak wrote: > On Tuesday, December 22, 2015 at 2:44:54 PM UTC+1, Jay McCarthy wrote: >> I tried on Windows 10 with 6.2.1 and can confirm that just installing >> pict3d cases a bunch of segfaults. >> >> If I try with the current snapshot build, I can successfully install >> and run pict3d using an Nvidia GPU. >> >> Jay > > I am currently trying to eliminate possible causes on my end (drivers, > memory, etc.) so will let you know. > So far I can say that my Nvidia drivers are definitely up to date. > > Greg > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Confused about the difference between the REPL and the toplevel.
Oh right. Sorry for the confusion! Robby On Tuesday, December 22, 2015, Matthew Flatt wrote: > I think Robby was confused by your example (which is understandable). > > The `expand` function does not splice any differently than `compile`, > so `compile` behaves the same as `expand` in your example: > > > (eval (compile #'(begin > (define-syntax (foo stx) > (displayln "hello") > #'5) > foo))) > foo: undefined; > cannot reference undefined identifier >context...: > /Users/mflatt/plt/racket/collects/racket/private/misc.rkt:87:7 > > (compile #'(begin > (define-syntax (foo stx) > (displayln "goodbye") > #'5) > foo)) > hello > #~ > > > I think Robby was just confused by your example, because he's used to > starting with a fresh REPL. :) > > At Mon, 21 Dec 2015 22:16:44 -0700, Leif Andersen wrote: > > Wait, now I'm even more confused. If expand does the splicing and > > compile time evals song and dance, why do we need a separate function > > for: > > > > expand-syntax-top-level-with-compile-time-evals > > > > ? > > > > ~Leif Andersen > > > > > > On Mon, Dec 21, 2015 at 9:48 PM, Robby Findler > > > wrote: > > > I believe that's because expand does the splicing dance, but compile > > > doesn't (which is why you need the funny-named function ... "need" is > > > perhaps a poor choice of words here :). > > > > > > Robby > > > > > > > > > On Mon, Dec 21, 2015 at 10:30 PM, Leif Andersen > > > wrote: > > >> Ah, that's a good question. One that I don't really know the answer > > >> too, because when I do: > > >> > > >>> (compile #'(begin > > >>(define-syntax (foo stx) > > >> (displayln "hello") > > >> #'5) > > >>foo)) > > >> > > >> I get back the compiled object. Also foo is not displayed. And when I > do: > > >> > > >> > (eval (compile #'(begin > > >>(define-syntax (foo stx) > > >> (displayln "hello") > > >> #'5) > > >>foo))) > > >> > > >> I get the error: > > >> > > >> foo: undefined; > > >> cannot reference an identifier before its definition > > >> > > >> But, when I do: > > >> > > >>> (expand #'(begin > > >>(define-syntax (foo stx) > > >> (displayln "hello") > > >> #'5) > > >>foo)) > > >> > > >> It displays 'hello' to the console. And expands to what I would > expect it > > too. > > >> > > >> ~Leif Andersen > > >> > > >> > > >> On Mon, Dec 21, 2015 at 9:15 PM, Alex Knauth > wrote: > > >>> > > On Dec 21, 2015, at 10:53 PM, Leif Andersen > wrote: > > >>> > > But `compile` is not supposed to evaluate any code, it just compiles > > it. Which is why it fails to compile that code. But if you > interleave > > it with evals, it will run the require code, which gives the phase > > level 2 code some meaning. > > >>> > > >>> I understand that `compile` isn't supposed to evaluate any _runtime_ > code, > > but I thought it had to evaluate the compile-time code for it to compile > the > > program? > > >>> > > >>> Am I misunderstanding what `compile` is supposed to do? Or what > > compile-time code is, or? > > >>> > > Does that make any sense, or was it too rambly. > > > > ~Leif Andersen > > > > > > On Mon, Dec 21, 2015 at 8:24 PM, Alex Knauth > wrote: > > > I get that `compile` doesn't evaluate the require form, but why > doesn't > > it evaluate what's needed for compile time? I thought that was the > reason for > > needing require as a macro instead of a function. Or am I getting the > purpose > > of compile wrong? > > > > > > Alex Knauth > > > > > >> On Dec 21, 2015, at 7:47 PM, Matthew Flatt > wrote: > > >> > > >> In the REPL, `begin` splices at the granularity of expansion and > > >> evaluation. That is, the first of the two forms grouped by > `begin` is > > >> compiled and evaluated, and only afterward the second one is > compiled > > >> and evaluated. > > >> > > >> The `compile` function can't do that, because it's only supposed > to > > >> compile -- not evaluate. > > >> > > >> The `syntax/toplevel` library provides > > >> > > >> expand-syntax-top-level-with-compile-time-evals > > >> > > >> as an intermediate point between those: it pulls apart `begin` and > > >> `expands` (which is the interesting part of `compile`) the forms > in > > >> sequence, but it evaluates only compile-time parts of the given > forms. > > >> That works for many cases, including your example. > > >> > > >> At Mon, 21 Dec 2015 17:35:22 -0700, Leif Andersen wrote: > > >>> So, I was under the impression that the REPL was the toplevel > (unless > > >>> you entered a module context or something like that). But I just > had
Re: [racket-users] DrRacket crashes on simple pict3d script
On Tuesday, December 22, 2015 at 2:44:54 PM UTC+1, Jay McCarthy wrote: > I tried on Windows 10 with 6.2.1 and can confirm that just installing > pict3d cases a bunch of segfaults. > > If I try with the current snapshot build, I can successfully install > and run pict3d using an Nvidia GPU. > > Jay I am currently trying to eliminate possible causes on my end (drivers, memory, etc.) so will let you know. So far I can say that my Nvidia drivers are definitely up to date. Greg -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Confused about the difference between the REPL and the toplevel.
I think Robby was confused by your example (which is understandable). The `expand` function does not splice any differently than `compile`, so `compile` behaves the same as `expand` in your example: > (eval (compile #'(begin (define-syntax (foo stx) (displayln "hello") #'5) foo))) foo: undefined; cannot reference undefined identifier context...: /Users/mflatt/plt/racket/collects/racket/private/misc.rkt:87:7 > (compile #'(begin (define-syntax (foo stx) (displayln "goodbye") #'5) foo)) hello #~ I think Robby was just confused by your example, because he's used to starting with a fresh REPL. :) At Mon, 21 Dec 2015 22:16:44 -0700, Leif Andersen wrote: > Wait, now I'm even more confused. If expand does the splicing and > compile time evals song and dance, why do we need a separate function > for: > > expand-syntax-top-level-with-compile-time-evals > > ? > > ~Leif Andersen > > > On Mon, Dec 21, 2015 at 9:48 PM, Robby Findler > wrote: > > I believe that's because expand does the splicing dance, but compile > > doesn't (which is why you need the funny-named function ... "need" is > > perhaps a poor choice of words here :). > > > > Robby > > > > > > On Mon, Dec 21, 2015 at 10:30 PM, Leif Andersen > wrote: > >> Ah, that's a good question. One that I don't really know the answer > >> too, because when I do: > >> > >>> (compile #'(begin > >>(define-syntax (foo stx) > >> (displayln "hello") > >> #'5) > >>foo)) > >> > >> I get back the compiled object. Also foo is not displayed. And when I do: > >> > >> > (eval (compile #'(begin > >>(define-syntax (foo stx) > >> (displayln "hello") > >> #'5) > >>foo))) > >> > >> I get the error: > >> > >> foo: undefined; > >> cannot reference an identifier before its definition > >> > >> But, when I do: > >> > >>> (expand #'(begin > >>(define-syntax (foo stx) > >> (displayln "hello") > >> #'5) > >>foo)) > >> > >> It displays 'hello' to the console. And expands to what I would expect it > too. > >> > >> ~Leif Andersen > >> > >> > >> On Mon, Dec 21, 2015 at 9:15 PM, Alex Knauth wrote: > >>> > On Dec 21, 2015, at 10:53 PM, Leif Andersen > wrote: > >>> > But `compile` is not supposed to evaluate any code, it just compiles > it. Which is why it fails to compile that code. But if you interleave > it with evals, it will run the require code, which gives the phase > level 2 code some meaning. > >>> > >>> I understand that `compile` isn't supposed to evaluate any _runtime_ > >>> code, > but I thought it had to evaluate the compile-time code for it to compile the > program? > >>> > >>> Am I misunderstanding what `compile` is supposed to do? Or what > compile-time code is, or? > >>> > Does that make any sense, or was it too rambly. > > ~Leif Andersen > > > On Mon, Dec 21, 2015 at 8:24 PM, Alex Knauth > wrote: > > I get that `compile` doesn't evaluate the require form, but why doesn't > it evaluate what's needed for compile time? I thought that was the reason for > needing require as a macro instead of a function. Or am I getting the purpose > of compile wrong? > > > > Alex Knauth > > > >> On Dec 21, 2015, at 7:47 PM, Matthew Flatt wrote: > >> > >> In the REPL, `begin` splices at the granularity of expansion and > >> evaluation. That is, the first of the two forms grouped by `begin` is > >> compiled and evaluated, and only afterward the second one is compiled > >> and evaluated. > >> > >> The `compile` function can't do that, because it's only supposed to > >> compile -- not evaluate. > >> > >> The `syntax/toplevel` library provides > >> > >> expand-syntax-top-level-with-compile-time-evals > >> > >> as an intermediate point between those: it pulls apart `begin` and > >> `expands` (which is the interesting part of `compile`) the forms in > >> sequence, but it evaluates only compile-time parts of the given forms. > >> That works for many cases, including your example. > >> > >> At Mon, 21 Dec 2015 17:35:22 -0700, Leif Andersen wrote: > >>> So, I was under the impression that the REPL was the toplevel (unless > >>> you entered a module context or something like that). But I just had > >>> something challenge that assumption and so now I'm a bit confused. > >>> > >>> I have the following top level program: > >>> > >>> (begin > >>> (require (for-meta 1 racket) > >>> (for-meta 2 racket)) > >>> (begin-for-syntax > >>> (begin-for-syntax > >>> (define x 5 > >>> > >>> When I run thi
Re: [racket-users] DrRacket crashes on simple pict3d script
I tried on Windows 10 with 6.2.1 and can confirm that just installing pict3d cases a bunch of segfaults. If I try with the current snapshot build, I can successfully install and run pict3d using an Nvidia GPU. Jay On Tue, Dec 22, 2015 at 7:24 AM, Greg Trzeciak wrote: > On Tuesday, December 22, 2015 at 1:06:55 PM UTC+1, Jay McCarthy wrote: >> Greg - What version of Racket are you running? >> >> Matthew - Do you know how to get logs from Windows crashes? >> >> Jay > > Racket version is 6.3 > My windows event log says that the module causing error in relation to Racket > is: > C:\WINDOWS\SYSTEM32\ntdll.dll (version: 10.0.10586.20) > > full log: > - http://schemas.microsoft.com/win/2004/08/events/event";> > - > > 1000 > 2 > 100 > 0x80 > > 2341 > Application > WIN8-ZEUS > > > - > DrRacket.exe > 6.3.0.0 > 564eb766 > ntdll.dll > 10.0.10586.20 > 56540c3b > c005 > 00034b64 > 33b8 > 01d13cb2ea820501 > C:\Program Files\Racket\DrRacket.exe > C:\WINDOWS\SYSTEM32\ntdll.dll > dbd80579-7b68-4b96-94b3-e4b404bab9d1 > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Jay McCarthy Associate Professor PLT @ CS @ UMass Lowell http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Confused about the difference between the REPL and the toplevel.
Expanding a form triggers compile-time evaluation in the sense of running macros. Currently, though, compilation treats changing the set of bindings at the top level as a kind of run-time effect (to be avoided at compile time). For example, compiling `(define x 5)` does not change the current binding of `x` at the top level: > (require (only-in racket [+ x])) > (define code (compile #'(define x 5))) > (x 1 2) 3 Evaluating the compiled form of `(define x 5)` does change the binding f `x`: > (eval code) > x 5 It seems clear that top-level binding needs to be a run-time effect in that latter sense, but maybe it could also happen as a compile-time effect. That would be a significant change, though; some things would break. As it happens, the new expander at first leaked a binding effect when compiling `define` --- until Leif reported it as a bug and I fixed it. Neither the current interaction of `compile` and binding or the alternative seems obviously right to me, though. As you know, I've given up on finding completely satisfactory rules for the top level. At Mon, 21 Dec 2015 23:15:58 -0500, Alex Knauth wrote: > > > On Dec 21, 2015, at 10:53 PM, Leif Andersen wrote: > > > But `compile` is not supposed to evaluate any code, it just compiles > > it. Which is why it fails to compile that code. But if you interleave > > it with evals, it will run the require code, which gives the phase > > level 2 code some meaning. > > I understand that `compile` isn't supposed to evaluate any _runtime_ code, > but > I thought it had to evaluate the compile-time code for it to compile the > program? > > Am I misunderstanding what `compile` is supposed to do? Or what compile-time > code is, or? > > > Does that make any sense, or was it too rambly. > > > > ~Leif Andersen > > > > > > On Mon, Dec 21, 2015 at 8:24 PM, Alex Knauth wrote: > >> I get that `compile` doesn't evaluate the require form, but why doesn't it > evaluate what's needed for compile time? I thought that was the reason for > needing require as a macro instead of a function. Or am I getting the purpose > of compile wrong? > >> > >> Alex Knauth > >> > >>> On Dec 21, 2015, at 7:47 PM, Matthew Flatt wrote: > >>> > >>> In the REPL, `begin` splices at the granularity of expansion and > >>> evaluation. That is, the first of the two forms grouped by `begin` is > >>> compiled and evaluated, and only afterward the second one is compiled > >>> and evaluated. > >>> > >>> The `compile` function can't do that, because it's only supposed to > >>> compile -- not evaluate. > >>> > >>> The `syntax/toplevel` library provides > >>> > >>> expand-syntax-top-level-with-compile-time-evals > >>> > >>> as an intermediate point between those: it pulls apart `begin` and > >>> `expands` (which is the interesting part of `compile`) the forms in > >>> sequence, but it evaluates only compile-time parts of the given forms. > >>> That works for many cases, including your example. > >>> > >>> At Mon, 21 Dec 2015 17:35:22 -0700, Leif Andersen wrote: > So, I was under the impression that the REPL was the toplevel (unless > you entered a module context or something like that). But I just had > something challenge that assumption and so now I'm a bit confused. > > I have the following top level program: > > (begin > (require (for-meta 1 racket) > (for-meta 2 racket)) > (begin-for-syntax > (begin-for-syntax > (define x 5 > > When I run this top level program in the REPL, it works just fine. And > I can even reference x in later evaluations. (Provided I'm at the > meta-level of 2). > > However, when I pass this top level program into compile like so: > http://pasterack.org/pastes/38556 > > (compile #'(begin > (require (for-meta 1 racket) > (for-meta 2 racket)) > (begin-for-syntax > (begin-for-syntax > (define x 5) > > > I get the following error: > > define: unbound identifier at phase 2; > also, no #%app syntax transformer is bound in: define > > Can someone give me the reason (or at least some intuition) as to why > this works in the repl, but not at the top level? > > Thank you. > > ~Leif Andersen > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > >>> > >>> -- > >>> You received this message because you are subscribed to the Google Groups > "Racket Users" group. > >>> To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googleg
Re: [racket-users] Confused about the difference between the REPL and the toplevel.
At Mon, 21 Dec 2015 21:30:45 -0700, Leif Andersen wrote: > Ah, that's a good question. One that I don't really know the answer > too, because when I do: > > > (compile #'(begin >(define-syntax (foo stx) > (displayln "hello") > #'5) >foo)) > > I get back the compiled object. The compiled object ends with a reference to a top-level `foo` variable, not an expansion of the `foo` macro. > Also foo is not displayed. That's because the `foo` macro was only compiled, not bound, and so the ending `foo` didn't reference it. > And when I do: > > > (eval (compile #'(begin >(define-syntax (foo stx) > (displayln "hello") > #'5) >foo))) > > I get the error: > > foo: undefined; > cannot reference an identifier before its definition That demonstrates the reference to `foo`, which is never defined as a variable. Confusingly, however, `foo` at this point is bound to a macro. To make sense of that, you have to remember that there are two levels to identifier resolution. The first is a binding layer that points `foo` to either a module import, a top-level macro, or a top-level variable. In the case of a variable, a second layer maps the variable name to its value. Compilation commits to a choice in the first layer; it commits to the the `foo` as a variable reference before that first layer is changed to make `foo` a macro. > But, when I do: > > > (expand #'(begin >(define-syntax (foo stx) > (displayln "hello") > #'5) >foo)) > > It displays 'hello' to the console. And expands to what I would expect it too. That example doesn't display anything if you try it in a fresh REPL. But if you continue in the same REPL as the previous `eval`, then it's the other `foo` that gets used as a macro here, not this one. > On Mon, Dec 21, 2015 at 9:15 PM, Alex Knauth wrote: > > > >> On Dec 21, 2015, at 10:53 PM, Leif Andersen wrote: > > > >> But `compile` is not supposed to evaluate any code, it just compiles > >> it. Which is why it fails to compile that code. But if you interleave > >> it with evals, it will run the require code, which gives the phase > >> level 2 code some meaning. > > > > I understand that `compile` isn't supposed to evaluate any _runtime_ code, > but I thought it had to evaluate the compile-time code for it to compile the > program? > > > > Am I misunderstanding what `compile` is supposed to do? Or what > > compile-time > code is, or? > > > >> Does that make any sense, or was it too rambly. > >> > >> ~Leif Andersen > >> > >> > >> On Mon, Dec 21, 2015 at 8:24 PM, Alex Knauth wrote: > >>> I get that `compile` doesn't evaluate the require form, but why doesn't > >>> it > evaluate what's needed for compile time? I thought that was the reason for > needing require as a macro instead of a function. Or am I getting the purpose > of compile wrong? > >>> > >>> Alex Knauth > >>> > On Dec 21, 2015, at 7:47 PM, Matthew Flatt wrote: > > In the REPL, `begin` splices at the granularity of expansion and > evaluation. That is, the first of the two forms grouped by `begin` is > compiled and evaluated, and only afterward the second one is compiled > and evaluated. > > The `compile` function can't do that, because it's only supposed to > compile -- not evaluate. > > The `syntax/toplevel` library provides > > expand-syntax-top-level-with-compile-time-evals > > as an intermediate point between those: it pulls apart `begin` and > `expands` (which is the interesting part of `compile`) the forms in > sequence, but it evaluates only compile-time parts of the given forms. > That works for many cases, including your example. > > At Mon, 21 Dec 2015 17:35:22 -0700, Leif Andersen wrote: > > So, I was under the impression that the REPL was the toplevel (unless > > you entered a module context or something like that). But I just had > > something challenge that assumption and so now I'm a bit confused. > > > > I have the following top level program: > > > > (begin > > (require (for-meta 1 racket) > > (for-meta 2 racket)) > > (begin-for-syntax > > (begin-for-syntax > > (define x 5 > > > > When I run this top level program in the REPL, it works just fine. And > > I can even reference x in later evaluations. (Provided I'm at the > > meta-level of 2). > > > > However, when I pass this top level program into compile like so: > > http://pasterack.org/pastes/38556 > > > > (compile #'(begin > >(require (for-meta 1 racket) > > (for-meta 2 racket)) > >(begin-for-syntax > > (begin-for-syntax > >(define x 5) > > > > > > I get the
Re: [racket-users] DrRacket crashes on simple pict3d script
On Tuesday, December 22, 2015 at 1:06:55 PM UTC+1, Jay McCarthy wrote: > Greg - What version of Racket are you running? > > Matthew - Do you know how to get logs from Windows crashes? > > Jay Racket version is 6.3 My windows event log says that the module causing error in relation to Racket is: C:\WINDOWS\SYSTEM32\ntdll.dll (version: 10.0.10586.20) full log: - http://schemas.microsoft.com/win/2004/08/events/event";> - 1000 2 100 0x80 2341 Application WIN8-ZEUS - DrRacket.exe 6.3.0.0 564eb766 ntdll.dll 10.0.10586.20 56540c3b c005 00034b64 33b8 01d13cb2ea820501 C:\Program Files\Racket\DrRacket.exe C:\WINDOWS\SYSTEM32\ntdll.dll dbd80579-7b68-4b96-94b3-e4b404bab9d1 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] DrRacket crashes on simple pict3d script
Greg - What version of Racket are you running?
Matthew - Do you know how to get logs from Windows crashes?
Jay
On Tue, Dec 22, 2015 at 6:45 AM, Greg Trzeciak wrote:
> On Monday, December 21, 2015 at 5:00:05 PM UTC+1, Jay McCarthy wrote:
>> Hi Greg,
>>
>> Can you update and check if you still get the same error? If you do,
>> or if you get a different one, can you send me the output of
>>
>> racket -l pict3d/tests/shaders
>>
>> Thanks!
>>
>> Jay
>>
>
> Hi,
>
> I tried running shaders tests but everytime I try I get: "Racket stopped
> working". I tried running some other tests in this catalog: spaceship and
> snowman with the same command and got the same error.
> Running it from DrRacket crashes GUI.
>
> As a side note during update of pict3d (or rather at the end of update)
> DrRacket crashed again ("Racket GUI stopped working").
>
> Greg
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io
"Wherefore, be not weary in well-doing,
for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
- D&C 64:33
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] DrRacket crashes on simple pict3d script
On Monday, December 21, 2015 at 5:00:05 PM UTC+1, Jay McCarthy wrote:
> Hi Greg,
>
> Can you update and check if you still get the same error? If you do,
> or if you get a different one, can you send me the output of
>
> racket -l pict3d/tests/shaders
>
> Thanks!
>
> Jay
>
Hi,
I tried running shaders tests but everytime I try I get: "Racket stopped
working". I tried running some other tests in this catalog: spaceship and
snowman with the same command and got the same error.
Running it from DrRacket crashes GUI.
As a side note during update of pict3d (or rather at the end of update)
DrRacket crashed again ("Racket GUI stopped working").
Greg
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
