Re: [racket-users] GUI problem -- main window loosing focus when two dialog boxes are opened
On Wednesday, May 9, 2018 at 7:25:34 AM UTC+8, gneuner2 wrote: > > > Ignoring Racket's extraneous added panels, a better organization would be: > > Window 00010010 "" #32769 (Desktop) > : > Window 0017076E "Hello World" PLTFrame > Window 000F03D2 "Dialog 1" #32770 (Dialog) > Window 00320BCC "Dialog 2" #32770 (Dialog) > Window 003A052E "Close Dialog 2" PLTBUTTON > Window 0057098A "Open Dialog 2..." PLTBUTTON > Window 001807D4 "Close Dialog 1" PLTBUTTON > Window 003704DA "Open Dialog 1..." PLTBUTTON > : > > but it would work even if the dialogs were just siblings under the top > level frame [assuming their creation Z-order was correct]. > I think the current window hierarchy is correct: I compared a similar setup in Visual Studio, where I opened two nested dialog boxes and inspected them with Spy++. The dialog boxes are toplevel windows, same as for the Racket sample application I had. The "OwnerWindow"of the dialogs is setup to point to the owner of the dialog boxes(i.e. the owner of Dialog 2 is Dialog 1 and the owner of Dialog 1 is the main frame). As far as I can tell the window hierarchy for the main frame + two dialog boxes is the same in Racket as it is for Visual Studio... Best Regards, Alex. -- 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] GUI problem -- main window loosing focus when two dialog boxes are opened
Hi Alex, fwiw: I tried with 32-bit 6.11 on Win7 and it messes up also. On 5/8/2018 6:24 AM, Alex Harsanyi wrote: I had a look at the application windows using Spy++ and all three windows (the main frame and the two dialog ones) are toplevel windows, as expected; however they are linked together as GetNextWindow/GetPreviousWindow correctly. Unfortunately, I am not very familiar with Windows GDI programming, but I will try to trace the messages to the windows themselves. I now also have taken a look with Spy. The problem is that the windows should NOT all be top level. Per the code, dialog1 should be a child of the frame, and dialog2 a child of dialog1. On my system, Spy shows: Window 00010010 "" #32769 (Desktop) : Window 00320BCC "Dialog 2" #32770 (Dialog) Window 001E0C6C "" PLTPanel Window 00DF0854 "" PLTTabPanel Window 003A052E "Close Dialog 2" PLTBUTTON Window 000F03D2 "Dialog 1" #32770 (Dialog) Window 00370596 "" PLTPanel Window 001806EE "" PLTTabPanel Window 0057098A "Open Dialog 2..." PLTBUTTON Window 001807D4 "Close Dialog 1" PLTBUTTON Window 0017076E "Hello World" PLTFrame Window 00430564 "" PLTPanel Window 000B03F8 "" PLTTabPanel Window 003704DA "Open Dialog 1..." PLTBUTTON : When the dialogs are "closed", they persist as hidden / deactivated windows. With this organization the GDI GetNextWindow() function can't be relied on to find the right focus target. It doesn't matter that the windows persist when not in use. Nor does it really matter whether they have a parent and child relationship or are siblings [created in the right order]. But for GetNextWindow() to work properly, it *does* matter that they are top level and that there is no "root" application window that is the parent of all the others. See: https://msdn.microsoft.com/en-us/library/windows/desktop/ms633509(v=vs.85).aspx The important part is right at the beginning: /If the specified window is a topmost window, the function searches for a topmost window. If the specified window is a top-level window, the function searches for a top-level window. If the specified window is a child window, the function searches for a child window./ The problem is: every application has at least one top level window. If the Z-order gets disturbed - say by another application activating momentarily - or if GetNextWindow() searches in the wrong direction[*], then a window belonging to another application may be found. [*] searching next vs previous doesn't matter with only 2 choices, but it does matter with more and when extraneous choices are intermixed. Also, the "topmost" part is a bit misleading: WS_EX_TOPMOST is a window style intended for things that should *always* stay on top [of other same application windows] when visible. It isn't used very often as there are other ways of keeping things visible: e.g., by using panels. And modal dialogs stay on top because their handler code won't permit switching to another [same application] window until the dialog is hidden / closed. Ignoring Racket's extraneous added panels, a better organization would be: Window 00010010 "" #32769 (Desktop) : Window 0017076E "Hello World" PLTFrame Window 000F03D2 "Dialog 1" #32770 (Dialog) Window 00320BCC "Dialog 2" #32770 (Dialog) Window 003A052E "Close Dialog 2" PLTBUTTON Window 0057098A "Open Dialog 2..." PLTBUTTON Window 001807D4 "Close Dialog 1" PLTBUTTON Window 003704DA "Open Dialog 1..." PLTBUTTON : but it would work even if the dialogs were just siblings under the top level frame [assuming their creation Z-order was correct]. I'm not sure how to verify it at the moment, but my suspicion is that - on Windows at least - Racket somehow is searching wrongly with GetNextWindow(). That might be a simple fix. Apart from that I don't see an easy work-around. Maybe creating custom window class(es) that focus the parent explicitly when a window object is hidden or destroyed. But right now I don't see a way to make it work using the stock gui objects . It would best if the GDI object hierarchy accurately reflected the Racket object hierarchy, but that's probably a whole lot of work. Sigh!, George -- 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] Unbound identifier error with syntax transformer that uses syntax-generating helper procedure
Thanks, that explanation helped. I had gaps in my knowledge. I also ended up daisy-chaining yet another submodule nested within the first, to require it both normally and for-template due to braid-shaped phase dependencies. Nothing seems to have gone wrong. On Tuesday, May 8, 2018 at 5:54:54 PM UTC-4, Alexis King wrote: > > The short answer is that you need a (require (for-template racket/base)) > in your utilities submodule: > > (module utilities racket/base > (provide compile-test) > > (require (for-template racket/base)) > > (define (compile-test) > #`(lambda (i) (displayln `(input: ,i) > > But this answer probably isn’t especially helpful towards debugging > similar problems in the future, so let me give a longer explanation. > > Racket’s macro system has phases. Phase 0 corresponds to runtime, phase > 1 corresponds to phase 0’s compile-time, phase 2 corresponds to phase > 1’s compile-time, etc. This space of phases is unbounded. Each phase > contains a completely distinct set of bindings, so when you write, say, > `let` at phase 0, it isn’t necessarily the same `let` as the one you use > at phase 1. > > The code you write in the body of a define-syntax definition is in phase > 1, since it is evaluated at compile-time. In your top-level module, you > use #lang racket, which happens to provide the bindings from racket/base > at both phase 0 and phase 1. This is why you can use `let` from > racket/base inside your this-works macro — it was provided at that phase > by #lang racket. The code in your template, in this case #`(lambda (i) > ), ends up getting evaluated at runtime, so it uses the phase 0 > bindings. > > You might have already known all that, since your question is about the > utilities submodule, but I wanted to include that explanation for > context. This module is interesting, since you require it for-syntax in > your enclosing module. This has the effect of *shifting* the phases of > your utilities submodule, so its phase 0 ends up aligning with phase 1 > of the enclosing module. Now, the language of this submodule is > racket/base, which provides bindings for `provide` and `define`, but > what about the code in the template? > > Well, from the utilities module’s perspective, that code is actually > going to be evaluated one phase level below phase 0: phase -1! This > phase-shifting that happens when you import things for-syntax is why > negative phases are meaningful — even though phase -1 doesn’t really > make any sense in isolation, after the phase-shifting that the > for-syntax import causes, phase -1 becomes phase 0. > > Racket manages all this complicated bookkeeping behind the scenes, so > you never need to worry about which *absolute* phase your code will be > used at. What you do need to worry about is which *relative* phase > pieces of code will end up at. In your utilities submodule, the `lambda` > identifier in the template will be evaluated at relative phase level -1, > so you need to ensure racket/base’s bindings are in scope at phase level > -1. This is what for-template does: it is like for-syntax, but it shifts > imports a phase level down instead of a phase level up. > > (Note that (for-template (for-syntax )) is a no-op, since the shifts > cancel each other out. It may be educational to think about the > implications of this for your program.) > > Alexis > > > > On May 8, 2018, at 16:00, Greg Rosenblatt > wrote: > > > > Hi, I'm having trouble writing a syntax transformer that uses a > syntax-generating procedure defined elsewhere. > > > > When the procedure is defined locally, everything is fine. > > > > When the procedure is defined outside the transformer, I have to do a > dance to make the procedure visible at the right phase, which seems to > work. However, upon use I get: > > > > > racket unbound-identifier.rkt > > unbound-identifier.rkt:9:7: lambda: unbound identifier; > > also, no #%app syntax transformer is bound > > context...: > >#(1973 module unbound-identifier 0) #(2181 module) #(2811 macro) > #(2822 local) > >#(2823 intdef) #(2824 module (unbound-identifier utilities) -1) > > other binding...: > ># > >#(1972 module) #(1973 module unbound-identifier 0) > > at: lambda > > in: (lambda (i) (displayln (quasiquote (input: (unquote input) > > context...: > >standard-module-name-resolver > > > > > > I wrote this self-contained example using a submodule, but the error > also occurs when requiring the module from another file. What am I doing > wrong? I imagine it's something silly. > > > > > > #lang racket > > (provide this-works this-does-not-work) > > > > (module utilities racket/base > > (provide compile-test) > > > > (define (compile-test) > > #`(lambda (i) (displayln `(input: ,input) > > > > (require (for-syntax 'utilities)) > > > > > > (define-syntax (this-works stx) > > (synta
Re: [racket-users] Unbound identifier error with syntax transformer that uses syntax-generating helper procedure
The short answer is that you need a (require (for-template racket/base)) in your utilities submodule: (module utilities racket/base (provide compile-test) (require (for-template racket/base)) (define (compile-test) #`(lambda (i) (displayln `(input: ,i) But this answer probably isn’t especially helpful towards debugging similar problems in the future, so let me give a longer explanation. Racket’s macro system has phases. Phase 0 corresponds to runtime, phase 1 corresponds to phase 0’s compile-time, phase 2 corresponds to phase 1’s compile-time, etc. This space of phases is unbounded. Each phase contains a completely distinct set of bindings, so when you write, say, `let` at phase 0, it isn’t necessarily the same `let` as the one you use at phase 1. The code you write in the body of a define-syntax definition is in phase 1, since it is evaluated at compile-time. In your top-level module, you use #lang racket, which happens to provide the bindings from racket/base at both phase 0 and phase 1. This is why you can use `let` from racket/base inside your this-works macro — it was provided at that phase by #lang racket. The code in your template, in this case #`(lambda (i) ), ends up getting evaluated at runtime, so it uses the phase 0 bindings. You might have already known all that, since your question is about the utilities submodule, but I wanted to include that explanation for context. This module is interesting, since you require it for-syntax in your enclosing module. This has the effect of *shifting* the phases of your utilities submodule, so its phase 0 ends up aligning with phase 1 of the enclosing module. Now, the language of this submodule is racket/base, which provides bindings for `provide` and `define`, but what about the code in the template? Well, from the utilities module’s perspective, that code is actually going to be evaluated one phase level below phase 0: phase -1! This phase-shifting that happens when you import things for-syntax is why negative phases are meaningful — even though phase -1 doesn’t really make any sense in isolation, after the phase-shifting that the for-syntax import causes, phase -1 becomes phase 0. Racket manages all this complicated bookkeeping behind the scenes, so you never need to worry about which *absolute* phase your code will be used at. What you do need to worry about is which *relative* phase pieces of code will end up at. In your utilities submodule, the `lambda` identifier in the template will be evaluated at relative phase level -1, so you need to ensure racket/base’s bindings are in scope at phase level -1. This is what for-template does: it is like for-syntax, but it shifts imports a phase level down instead of a phase level up. (Note that (for-template (for-syntax )) is a no-op, since the shifts cancel each other out. It may be educational to think about the implications of this for your program.) Alexis > On May 8, 2018, at 16:00, Greg Rosenblatt wrote: > > Hi, I'm having trouble writing a syntax transformer that uses a > syntax-generating procedure defined elsewhere. > > When the procedure is defined locally, everything is fine. > > When the procedure is defined outside the transformer, I have to do a dance > to make the procedure visible at the right phase, which seems to work. > However, upon use I get: > > > racket unbound-identifier.rkt > unbound-identifier.rkt:9:7: lambda: unbound identifier; > also, no #%app syntax transformer is bound > context...: >#(1973 module unbound-identifier 0) #(2181 module) #(2811 macro) #(2822 > local) >#(2823 intdef) #(2824 module (unbound-identifier utilities) -1) > other binding...: ># >#(1972 module) #(1973 module unbound-identifier 0) > at: lambda > in: (lambda (i) (displayln (quasiquote (input: (unquote input) > context...: >standard-module-name-resolver > > > I wrote this self-contained example using a submodule, but the error also > occurs when requiring the module from another file. What am I doing wrong? > I imagine it's something silly. > > > #lang racket > (provide this-works this-does-not-work) > > (module utilities racket/base > (provide compile-test) > > (define (compile-test) > #`(lambda (i) (displayln `(input: ,input) > > (require (for-syntax 'utilities)) > > > (define-syntax (this-works stx) > (syntax-case stx () > ((_ input) > (let () >(define (compile-test) > #`(lambda (i) (displayln `(input: ,input > >#`(#,(compile-test) input) > > (define-syntax (this-does-not-work stx) > (syntax-case stx () > ((_ input to-do ...) > (let () > >#`(#,(compile-test) input) > > (this-works 3) > (this-does-not-work 3) -- 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.
[racket-users] Unbound identifier error with syntax transformer that uses syntax-generating helper procedure
Hi, I'm having trouble writing a syntax transformer that uses a syntax-generating procedure defined elsewhere. When the procedure is defined locally, everything is fine. When the procedure is defined outside the transformer, I have to do a dance to make the procedure visible at the right phase, which seems to work. However, upon use I get: > racket unbound-identifier.rkt unbound-identifier.rkt:9:7: lambda: unbound identifier; also, no #%app syntax transformer is bound context...: #(1973 module unbound-identifier 0) #(2181 module) #(2811 macro) #(2822 local) #(2823 intdef) #(2824 module (unbound-identifier utilities) -1) other binding...: # #(1972 module) #(1973 module unbound-identifier 0) at: lambda in: (lambda (i) (displayln (quasiquote (input: (unquote input) context...: standard-module-name-resolver I wrote this self-contained example using a submodule, but the error also occurs when requiring the module from another file. What am I doing wrong? I imagine it's something silly. #lang racket (provide this-works this-does-not-work) (module utilities racket/base (provide compile-test) (define (compile-test) #`(lambda (i) (displayln `(input: ,input) (require (for-syntax 'utilities)) (define-syntax (this-works stx) (syntax-case stx () ((_ input) (let () (define (compile-test) #`(lambda (i) (displayln `(input: ,input #`(#,(compile-test) input) (define-syntax (this-does-not-work stx) (syntax-case stx () ((_ input to-do ...) (let () #`(#,(compile-test) input) (this-works 3) (this-does-not-work 3) -- 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.
[racket-users] markdown for embedded racket package documentation
Does anyone have experience using Markdown format for embedded documentation in Racket, including generating Scribble docs (to be the most cooperative Racket citizen)? How well has that worked, in practice? Do you end up having to kludge things, and do you find you can't express things you want to, that you could in Scribble? Background and comments... Long ago, I used embedded Texinfo format for documenting Scheme programs, and later made a Scribble backend after Scribble was created. The result out of Scribble's formatter was poor, compared to docs from Scribble source (e.g., the Texinfo couldn't express types in procedure signatures). I was reminded of Markdown because some Rust embeded documentation is using it, in 3-slash comments, and their docs look pretty good (excepting a usability problem in how they split across pages). Rust has complicated type information (more complicated than anything I've seen in Racket), but they seem to scrape the type declarations from the code, in the examples I've seen so far. I haven't looked at this yet, and don't yet know whether there's an option for expressing documented type information manually in the Markdown, when it can't be scraped. I'm trying to decide whether to do my next embedded docs thing using 3-semicolon Markdown in comments -- rather than Scribble in at-reader forms that the `#lang` special-cases, or Scribble in 3-semicolon comments. (I also have some experience scraping type info from Racket, and was surprised by the number of forms I had to handle, for lambdas and contracts alone, before I even got to TR.) Currently, 99% of my current interest is in the stock Scribble forms (including the BNF ones), and only 1% is in package-specific extensions of Scribble forms. I have already had occasion for package-specific extensions, such as for detailed spec citations shorthand, and for concepts like "http://www.neilvandyke.org/racket/roomba/#(part._.Sensor._.Packets)", but those haven't been crucial. Extensions become more important for `#lang` that introduce major API concepts other than procedures, methods, etc., so I suppose that might be a reason to stick with Scribble as the source format for all docs. Then there's potentially losing things like `@tech`, and the distinction between `@racket` and `@code`. Though the current Scribble CSS is distinguishing those less than the original did, anyway. Maybe an optional Markdown extension, like "r`foo`" would work, for the people who want to retain things like `@racket`. -- 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.
[racket-users] Can the embedded interpreter load modules not included using ++lib?
So, basically, I was wondering how one could go about requiring modules in
/usr/share/racket/collects from the embedded interpreter.
My current program links against a base.c file generated with raco ctool
base.c ++lib racket/base and simply runs REPL, it's essentially copied from
the Racket documentation that provides the same example:
int interpreter_run(Scheme_Env* env, int argc, char* argv[])
{
// set default collects path
scheme_set_collects_path(scheme_make_path("/usr/share/racket/collects"
));
// declare racket/base modules
declare_modules(env);
// require racket/base namespace
scheme_namespace_require(scheme_intern_symbol("racket/base"));
// require REPL symbols
Scheme_Object* symbols[2];
symbols[0] = scheme_intern_symbol("racket/base");
symbols[1] = scheme_intern_symbol("read-eval-print-loop");
// dynamically require function from racket/base
Scheme_Object* func = scheme_dynamic_require(2, symbols);
// invoke REPL
scheme_apply(func, 0, nullptr);
return EXIT_SUCCESS;
}
However, I have a few questions about this. Must all modules that one wants
to require be stated when doing the previous raco command (++lib)?
I'm not certain about the effect of doing *scheme_set_collects_path*
actually has in relation to how collections are required.
For example, from my REPL example:
> > $ ./racketeer
>
> > (find-system-path 'collects-dir)
> #
>
Evidently it successfully sets the collection path.
However, the context trace of attempting to require anything else from the
REPL example seems to completely omit this.
Example:
> > $
> ./racketeer
> > (require racket/base)
> > (require racket/gui)
> stdin::32: collection not found
> for module path: racket/gui
> collection: "racket"
> *in collection directories:*
> context...:
>show-collection-err
>standard-module-name-resolver
>/usr/share/racket/collects/racket/private/misc.rkt:88:7
> > (find-system-path 'collects-dir)
> #
>
It fails to require racket/gui and doesn't show any collection directories
at all. Is 'collects-dir completely separate from what the interpreter
actually uses to load modules from collections? If so, would I need to
register a proper collections directory prior to scheme_main_setup? From
what I can tell, it can only successfully (require racket/base) because it
was - for lack of accurate terminology - *compiled in* via raco's ++lib
option. Would that be a correct assumption to make?
My overall intention is to be able to do what racket's REPL can do from
command line, given a folder structure like this:
> > $ tree
> something
>
>
> something
> ├── compiled
> │ ├── main_rkt.dep
> │ ├── main_rkt.zo
> │ ├── other_rkt.dep
> │ └── other_rkt.zo
> ├── main.rkt
> └── other.rkt
>
Racket, from command line, ran from that the containing folder, can
(require something):
> $
> racket
> Welcome to Racket v6.12.
> > (require something)
> > (useless-func)
> Useless function
Yet, my REPL example can't do this but I suspect there's probably existent
scheme_* functions to do this (I seen one call something like
scheme_set_cmd and people pass argv[0] to it).
I just think it'd be useful to be able to dynamically require modules the
embedded interpreter but I can't seem to get it to work at all. I've
dabbled with things like dynamic-require and such, but due to my blatant
lack of understanding of how modules and collections are meant to work,
it's all just fell flat.
Any clarification on anything I've posted about would be much appreciated
as I'm currently going around in circles and manually purging files
generated by raco in a futile attempt to understand what's happening.
Out of interest, is it even possible to embed the Racket interpreter for
the purposes of interoperability? I've not seen anyone do it and the
documentation for scheme_* functions is sparing, to say the least. It seems
to me the only way to achieve interoperability would be to wrap C that
utilises native IPC to communicate with the intended application and then
load and execute the wrapper.
Sorry if my question is terribly unstructured or makes false assumptions or
assertions, I only started digging into Racket - and Lisp dialects overall
- recently.
As I say, any clarification on anything I've brought up would be much
appreciated.
Thanks.
--
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] what do people use for number formatting?
My ancient, half-finished R4RS Scheme number-formatting library is still used by at least one program. When I moved that library to the Racket new package system, I made an effort to deprecate it. But anyone improving modern-day idiomatic Racket formatting might want to take a quick peek at its docs, and consider which of the options it provides should be implemented in the modern thing. http://www.neilvandyke.org/racket/numformat-old/ -- 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] Provide form generator
Thanks Matthias. I'm fairly new to Racket, and I thought the provide form was just a way to indicate which functions to expose. I'll look into it. Dexter -Original Message- From: Matthias Felleisen Sent: Tuesday, May 8, 2018 12:11 PM To: Dexter Lagan Cc: us...@racket-lang.org Subject: Re: [racket-users] Provide form generator Neat. Keep in mind that the API of a module should be considered a specification (purpose, signature) that the module body (generated later) lives up to. No, this is not how we always work in practice because software evolves, but that is the principle. > On May 8, 2018, at 11:21 AM, Dexter Lagan wrote: > > Hi folks, > > I developed a provide form generator to take the pain out of writing module > headers: > > https://github.com/dexterlagan/provide-generator > > It works great, but I wonder if there wouldn’t be a simpler and more > standard way to write this. My original idea was to parse the module syntax > and simply delete the body of each define form, converting each function > definition to string and use it as comment to each provide element. I > couldn’t make it work that way, so I had to switch from syntax objects to > strings half-way and handle it by hand. Any insight? > > Thanks! > > Dex > > -- > 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] Provide form generator
Thanks a lot for your insights. I'll look into (module+test ...). Progedit looks great as well, it'd streamline a large part of my program. I need to get familiar with Scribble and write proper documentation, but my time is very limited. As soon as I got a free weekend I'll give Scribble a better look. I wasn't aware there was another way to use provide, thanks again for explaining. Have a great day, Dex -Original Message- From: Neil Van Dyke Sent: Tuesday, May 8, 2018 12:25 PM To: Dexter Lagan ; us...@racket-lang.org Subject: Re: [racket-users] Provide form generator Thank you for contributing. A few suggestions: * You probably want to put your unit tests, and the `(require rackunit)`, inside `(module+ test ...)` forms. That makes it better as a library or program, and also is what Racket expects for testing. * You can make this a full-fledged Racket package, with an `info.rkt` and Scribble documentation, and listing it on "http://pkgs.racket-lang.org/";. See: https://docs.racket-lang.org/pkg/index.html * You can make your program automatically add&update the `provide` form in user's files, and perhaps `progedit` is helpful for that: http://www.neilvandyke.org/racket/progedit/ * There seem to be two schools of thought on where `provide` belongs: (1) one big form near the top/bottom of the file or module, like an interface summary; and (2) locating the `provided`-ness information of a symbol at the definition site, such as through a `provide` form right next to the `define` form, or with syntax that combines `provide` and `define`. So, while you're using a tool you developed for #1, remember that #2 is something you might also want to try sometime. -- 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.
[racket-users] Re: what do people use for number formatting?
SRFI 54 - ever need a 4-character "thousands" separator? Bharat has units called lakhs & crores, instead of thousands I think there was a numberphile episode on it. French, Dutch, Babylonian, Indian ... Just one of the things I needed recently; I've used a bunch of SRFI 54 features over the last little while. ~r didn't do it for me. '(#\, 2)) is the separator spec. (cat 13412312.345612456 '(#\, 2)) ;"13,41,23,12.34,56,12,45,5" (cat 13412312.345612456 '(#\, 3)2.); "13,412,312.35" On Monday, May 7, 2018 at 7:46:30 PM UTC-4, johnbclements wrote: > > Okay, how many times have I written the function that accepts 1.237472387 > and returns “1.24” ? What do you folks use? I see that SRFI 54 covers this > use case, and a lot of others besides. Is this the most commonly used > package for formatting numbers? > > John > > > > -- 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] Provide form generator
Thank you for contributing. A few suggestions: * You probably want to put your unit tests, and the `(require rackunit)`, inside `(module+ test ...)` forms. That makes it better as a library or program, and also is what Racket expects for testing. * You can make this a full-fledged Racket package, with an `info.rkt` and Scribble documentation, and listing it on "http://pkgs.racket-lang.org/". See: https://docs.racket-lang.org/pkg/index.html * You can make your program automatically add&update the `provide` form in user's files, and perhaps `progedit` is helpful for that: http://www.neilvandyke.org/racket/progedit/ * There seem to be two schools of thought on where `provide` belongs: (1) one big form near the top/bottom of the file or module, like an interface summary; and (2) locating the `provided`-ness information of a symbol at the definition site, such as through a `provide` form right next to the `define` form, or with syntax that combines `provide` and `define`. So, while you're using a tool you developed for #1, remember that #2 is something you might also want to try sometime. -- 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] Provide form generator
Neat. Keep in mind that the API of a module should be considered a specification (purpose, signature) that the module body (generated later) lives up to. No, this is not how we always work in practice because software evolves, but that is the principle. > On May 8, 2018, at 11:21 AM, Dexter Lagan wrote: > > Hi folks, > > I developed a provide form generator to take the pain out of writing module > headers: > > https://github.com/dexterlagan/provide-generator > > It works great, but I wonder if there wouldn’t be a simpler and more > standard way to write this. My original idea was to parse the module syntax > and simply delete the body of each define form, converting each function > definition to string and use it as comment to each provide element. I > couldn’t make it work that way, so I had to switch from syntax objects to > strings half-way and handle it by hand. Any insight? > > Thanks! > > Dex > > -- > 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] question on quasisyntax/loc
Very nice explanation. Thank you! On Tue, May 8, 2018 at 11:08 AM, Alexis King wrote: > This behavior is intentional, though it could perhaps be more clearly > documented. The behavior is hinted at in the documentation for > syntax/loc: > > > Like syntax, except that the immediate resulting syntax object takes > > its source-location information from the result of stx-expr (which > > must produce a syntax object), unless the template is just a pattern > > variable, or both the source and position of stx-expr are #f. > > Note the “unless the template is just a pattern variable” condition. The > idea is that syntax/loc and quasisyntax/loc only ever adjust the source > location information on fresh syntax introduced in the template, never > on syntax from external pattern variables or syntax objects inserted > with unsyntax. For this reason, (quasisyntax/loc stx #,x) is always > equivalent to x. > > If you do actually want to modify the source location information on a > syntax object, you can do it with syntax-e and datum->syntax: > > (define (replace-outer-srcloc src-stx stx) > (datum->syntax stx (syntax-e stx) src-stx stx)) > > Then you could write (replace-outer-srcloc here y) to get the behavior > you want. > > Alexis > > > On May 8, 2018, at 09:56, Luke Whittlesey > > wrote: > > > > I'm having trouble understanding quasisyntax/loc in some cases. > > > > If I have the following example code: > > > > > > #lang racket > > > > (define here #'here) > > (define stx0 (syntax/loc here #'Y)) > > (define y #'Y) > > (define stx1 (quasisyntax/loc here #,y)) > > > > (displayln (format "here : line ~a" (syntax-line here))) > > (displayln (format "stx0 : line ~a" (syntax-line stx0))) > > (displayln (format "stx1 : line ~a" (syntax-line stx1))) > > > > > > It prints : > > > > here : line 3 > > stx0 : line 3 > > stx1 : line 5 > > > > > > I expect stx1 to also be at line 3 where `here` is defined. Is this > > example an incorrect use of quasisyntax/loc? What am I missing? > > > > Thanks, > > Luke > > -- 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.
[racket-users] Provide form generator
Hi folks, I developed a provide form generator to take the pain out of writing module headers: https://github.com/dexterlagan/provide-generator It works great, but I wonder if there wouldn’t be a simpler and more standard way to write this. My original idea was to parse the module syntax and simply delete the body of each define form, converting each function definition to string and use it as comment to each provide element. I couldn’t make it work that way, so I had to switch from syntax objects to strings half-way and handle it by hand. Any insight? Thanks! Dex -- 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] GUI problem -- main window loosing focus when two dialog boxes are opened
No problem on macOS 10.11.6 "El Capitan", Racket 6.10, or on macOS 10.13.4 "High Sierra", Racket 6.12. On May 7, 2018, at 8:46 PM, Alex Harsanyi wrote: > I have a problem with the Racket GUI where the main application window looses > focus if two dialog boxes are opened than closed. The problem occurs when the > main window opens the first dialog box and the first dialog box opens the > second one on top of it. Once both dialog boxes are closed, the main window > looses focus and goes to the bottom of the window stack (i.e. behind other > windows). This does not seem to happen if only one dialog box is opened than > closed -- in that case the main window will have the focus. > > Could someone confirm if this behaviour is seen on other platforms (I use > Windows), and perhaps offer a workaround? > > I attached a sample application that illustrates the problem below and you can > also find the code here: > https://gist.github.com/alex-hhh/20b3f1000813677330bbd2b85c57d319 > > Too see the problem, this code needs to be compiled into a stand-alone > executable (using the Racket/Create Executable... from DrRacket). > > #lang racket > (require racket/gui) > > (define toplevel (new frame% > [label "Hello World"] > [width 800] > [height 600])) > (define dialog-1 (new dialog% > [parent toplevel] > [label "Dialog 1"] > [width 400] > [height 300])) > (define dialog-2 (new dialog% > [parent dialog-1] > [label "Dialog 2"] > [width 200] > [height 150])) > > (define (on-open-dialog1 button event) > (send dialog-1 show #t)) > > (define (on-close-dialog1 button event) > (send dialog-1 show #f)) > > (define (on-open-dialog2 button event) > (send dialog-2 show #t)) > > (define (on-close-dialog2 button event) > (send dialog-2 show #f)) > > (define b1 (new button% > [parent toplevel] > [label "Open Dialog 1..."] > [callback on-open-dialog1])) > (define b2 (new button% > [parent dialog-1] > [label "Open Dialog 2..."] > [callback on-open-dialog2])) > (define b3 (new button% > [parent dialog-1] > [label "Close Dialog 1"] > [callback on-close-dialog1])) > (define b4 (new button% > [parent dialog-2] > [label "Close Dialog 2"] > [callback on-close-dialog2])) > > (send toplevel show #t) > > Thanks, > Alex. > > -- > 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] question on quasisyntax/loc
This behavior is intentional, though it could perhaps be more clearly documented. The behavior is hinted at in the documentation for syntax/loc: > Like syntax, except that the immediate resulting syntax object takes > its source-location information from the result of stx-expr (which > must produce a syntax object), unless the template is just a pattern > variable, or both the source and position of stx-expr are #f. Note the “unless the template is just a pattern variable” condition. The idea is that syntax/loc and quasisyntax/loc only ever adjust the source location information on fresh syntax introduced in the template, never on syntax from external pattern variables or syntax objects inserted with unsyntax. For this reason, (quasisyntax/loc stx #,x) is always equivalent to x. If you do actually want to modify the source location information on a syntax object, you can do it with syntax-e and datum->syntax: (define (replace-outer-srcloc src-stx stx) (datum->syntax stx (syntax-e stx) src-stx stx)) Then you could write (replace-outer-srcloc here y) to get the behavior you want. Alexis > On May 8, 2018, at 09:56, Luke Whittlesey > wrote: > > I'm having trouble understanding quasisyntax/loc in some cases. > > If I have the following example code: > > > #lang racket > > (define here #'here) > (define stx0 (syntax/loc here #'Y)) > (define y #'Y) > (define stx1 (quasisyntax/loc here #,y)) > > (displayln (format "here : line ~a" (syntax-line here))) > (displayln (format "stx0 : line ~a" (syntax-line stx0))) > (displayln (format "stx1 : line ~a" (syntax-line stx1))) > > > It prints : > > here : line 3 > stx0 : line 3 > stx1 : line 5 > > > I expect stx1 to also be at line 3 where `here` is defined. Is this > example an incorrect use of quasisyntax/loc? What am I missing? > > Thanks, > Luke -- 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.
[racket-users] question on quasisyntax/loc
I'm having trouble understanding quasisyntax/loc in some cases. If I have the following example code: #lang racket (define here #'here) (define stx0 (syntax/loc here #'Y)) (define y #'Y) (define stx1 (quasisyntax/loc here #,y)) (displayln (format "here : line ~a" (syntax-line here))) (displayln (format "stx0 : line ~a" (syntax-line stx0))) (displayln (format "stx1 : line ~a" (syntax-line stx1))) It prints : here : line 3 stx0 : line 3 stx1 : line 5 I expect stx1 to also be at line 3 where `here` is defined. Is this example an incorrect use of quasisyntax/loc? What am I missing? Thanks, Luke -- 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] GUI problem -- main window loosing focus when two dialog boxes are opened
Hi Alex, On 5/8/2018 6:24 AM, Alex Harsanyi wrote: On Tuesday, May 8, 2018 at 2:08:02 PM UTC+8, gneuner2 wrote: So I guess the 1st question to answer is: does the GDI object have the correct parent HWND? [The Racket dialog% object has a parent, but does the underlying display object?] If it does, there's something weird going on in finding the right window to switch to. I had a look at the application windows using Spy++ and all three windows (the main frame and the two dialog ones) are toplevel windows, as expected; however they are linked together as GetNextWindow/GetPreviousWindow correctly. Unfortunately, I am not very familiar with Windows GDI programming, but I will try to trace the messages to the windows themselves. I'm not sure why exactly Racket creates "top level" windows everywhere [other than for the annoying issue that style WS_CHILD prevents a window from having a menu bar]. Maybe it's just terminology - i.e. it's not a WS_CHILD, so what do we call it? Also, if I only open the first dialog, than close it, the main frame does not go to the bottom of the window stack... Yes. I saw that. It makes me wonder about how (or even if) Racket is using GetNextWindow. Since the Racket objects form their own hierarchy, Racket could be walking *that* structure to find the window rather than letting GDI handle it. Thanks for looking into this. "Looking into" is perhaps too strong to describe what I did, but you're welcome. Alex. George -- 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] GUI problem -- main window loosing focus when two dialog boxes are opened
On Tuesday, May 8, 2018 at 2:08:02 PM UTC+8, gneuner2 wrote: > > Hi Alex, > > > So I guess the 1st question to answer is: does the GDI object have the > correct parent HWND? [The Racket dialog% object has a parent, but does > the underlying display object?] If it does, there's something weird > going on in finding the right window to switch to. > I had a look at the application windows using Spy++ and all three windows (the main frame and the two dialog ones) are toplevel windows, as expected; however they are linked together as GetNextWindow/GetPreviousWindow correctly. Unfortunately, I am not very familiar with Windows GDI programming, but I will try to trace the messages to the windows themselves. Also, if I only open the first dialog, than close it, the main frame does not go to the bottom of the window stack... Thanks for looking into this. Alex. > > -- 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.
