I try to encourage people to participate, but be careful because this task
is probably too big for a first contribution. GUI is difficult, DrRacket
has a lot of moving parts, and opening DrRacket inside DrRacket is possible
but weird.

I think the guess of Matthew is correct, it´s a problem with the blue arrow
with the docs. There is no pause while you type numbers but when you type a
letter or +-*/... there is a pause of 1 or 2 seconds.

I didn't see the code but my guess is that the docs are loaded lazily in a
thread and when DrRackets see something like an identifier it waits until
the thread is ready. It would be nice if the blue arrow is disabled until
the docs are completely loaded lazily. I think Robby can tell if I'm
correct and how hard is to fix this.

Gustavo


On Fri, May 1, 2020 at 5:10 PM Matthew Flatt <mfl...@cs.utah.edu> wrote:

> At Fri, 1 May 2020 16:59:22 +0200, Dexter Lagan wrote:
> >   I'd like to download DrRacket's source and profile it, say to improve
> > scrolling performance or track this post-startup lock-up :
>
> Does the start-time delay happen if you just type a number and hit
> return, as opposed to typing an identifier? If not, the delay is
> probably in loading documentation as triggered the first time DrRacket
> sees an identifier to look up.
>
> > - Do I need to download the entire Racket tree in order to build
> DrRacket?
>
> You can start with minimal Racket and install DrRacket, as Sorawee
> said, but be aware that installing DrRacket will pull in most of a
> normal Racket distribution, anyway.
>
> > - Is the DrRacket's built-in profiler solid enough to handle profiling
> > DrRacket itself?
>
> Running DrRacket inside of DrRacket is not likely to give you useful
> information for something like scrolling, because DrRacket shares the
> GUI instance with programs that it runs.
>
> Running DrRacket with `raco profile` is more promising. It doesn't work
> as easily as it should, partly because DrRacket wants to be in control,
> and partly because `raco profile` doesn't deal with the custodian being
> changed or waiting for a GUI program to exit. But I was able to run it
> by supplying this wrapper program to `raco profile`:
>
>  #lang racket/base
>  (require racket/gui/base)
>
>  (define c (make-custodian))
>  (define done (make-semaphore))
>
>  (parameterize ([current-custodian c])
>    (parameterize ([exit-handler
>                    (lambda (v)
>                      (semaphore-post done)
>                      (custodian-shutdown-all c))])
>      (define e (make-eventspace))
>      (parameterize ([current-eventspace e])
>        (queue-callback (lambda ()
>                          ;; here's where we finally start DrRacket
>                          (dynamic-require 'drracket #f))))))
>
>  (sync done)
>
>
> > - Modules in DrRacket's repo don't always have very telling names. Is
> there
> > a document describing what each module does?
>
> There's nothing like that, as far as I know.
>
> > - If I make a change to a source file on my system, yet somebody else
> > modifies the same file on their local system. Say both of our changes are
> > accepted by whoever manages commits, how will accepted changes to the
> code
> > merged?
>
> We use Git, which provides good tools for merging changes.
>
> >   Also, say I have a suggestion regarding how DrRacket handles compiling
> > standalone executables, do I still need to create an issue on its Github?
> > For work I compile to standalone all day long, and I really wish DrRacket
> > didn't zip the resulting file (it would be better to have the .exe file
> in
> > an automatically created /bin or /output folder). Zipping the file takes
> > time, and I have to unzip it each time, which takes more time, this piles
> > up when done every few minutes, all day long. I could use raco exe, but
> I'd
> > rather stay in DrRacket, and I'm sure many people would rather have the
> > default behavior to not zip, just to have single responsibility on the
> > compile function.
>
> That sounds plausible for many cases. (In some cases, depending on the
> platform and the program, there are unavoidably multiple output files.)
>
> >  One last questions: I have encountered differences in the behavior of
> > macros between the REPL, a launcher and a standalone executable for
> > distribution. Is there a document outlining the deeper differences
> between
> > these three ways of executing Racket code?
>
> I think you're probably encountering differences in how the namespace
> and module registry is set up for `eval` and/or `dynamic-require`.
>
> Maybe you've already seen these, but if not, they're good starting
> points:
>
>   https://docs.racket-lang.org/guide/reflection.html
>
>   https://docs.racket-lang.org/raco/exe.html
>   (especially paragraphs 3 through 6 about modules)
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/5eac8218.1c69fb81.f0545.ba78SMTPIN_ADDED_MISSING%40gmr-mx.google.com
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAPaha9Og2-8gav0y-jf2gxTddA-VfrzJ91rgW%3D%2BF3%2BoLNqC-Sw%40mail.gmail.com.

Reply via email to