[racket-users] Re: gui change-children portability and nuances

[Alex Harsanyi]

Hi Neil,

I have used `change-children` on a Win32 GUI and the widgets that are 
switched in and out keep all their state, including the scroll position, 
unless, of course, if you change this state from the program.This 
means, for example, that if you have a list-box% and you remove it from a 
panel than later add it back in, the list-box% will keep its scroll 
position.

As for whether `change-children` it is a good way to switch between 
widgets, I am not aware of any other option...

Alex.

On Wednesday, August 8, 2018 at 3:43:47 AM UTC+8, Neil Van Dyke wrote:
>
> Two questions, as I'm trying to extend the Racket `gui` widgets just a 
> little, for small touchscreens, while remaining cross-platform and 
> desktop friendly: 
>
> 1. For all the platforms supported by Racket `gui` widgets, is 
> `change-children` a good way to frequently switch among subtrees of 
> widgets?  (Like currently for `tab-panel%`, but also for a 
> smartphone-like app's dynamic stack of UI pages.) 
>
> 2. If `change-children` is a good way, is any noteworthy state of a 
> widget tree *not* preserved between hiding and unhiding this way, 
> assuming that the parent container widget geometry hasn't changed in the 
> meantime?  (Offhand, I'm especially interested in whether the current 
> scroll position of panels is retained between hiding and unhiding, by 
> default, such as when user is going through a big hierarchy of 
> Android-style scrolling lists of settings, and not wanting to lose their 
> scrolling place when they back up to the big top level.  You could also 
> see such page stacks be used for things like what might be modal popup 
> windows in a traditional desktop GUI.) 
>
> (Reason for asking: I can't tell from the documentation, and this seems 
> like a time to ask.  Although I can test behavior with GTK2 and 
> GTK3 on GNU/Linux handhelds and desktops, I'd prefer to use an an 
> approach that should also work well on all the other Racket `gui` 
> platforms (current and future), without expending time right now 
> to test on all the current ones. One idea for this handhelds 
> unfunded side project (which might not go anywhere) is that 
> handheld-oriented apps people make for Racket-on-Linux might also turn 
> out to work well for whatever desktop/laptop platform Racketeers use.  
> For example, a straightforward set of traditional handheld 
> email/IRC/monitoring/etc. apps, but in tiled windows on your desktop 
> side monitor or laptop workspace, might work pretty well.  Well enough 
> to inspire more such cross-handheld/desktop apps to be written, whatever 
> platform the initial developer targets initially.) 
>
>

-- 
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] Testing & global variables

[Alex Harsanyi]

If this is a problem only in your test code, you could write a function to 
reset/re-initialize the global state, and call that function at the 
beginning of each test.

If you want to have a "global state" for each of the file that requires 
your module, global variables might not be the right approach...

Alex.

On Wednesday, August 8, 2018 at 1:29:38 AM UTC+8, lysseus wrote:
>
> I’ve got a library that takes  maintains global variables. I’d like to be 
> able to test different test files that require this library, but of course 
> if I require those files into a single test file for testing various 
> combinations of data it corrupts the global variables, which are only valid 
> for a single instance of test file. 
>
> Conceptually it looks like: 
>
> Library-File 
> global a 
> library-functions 
> Test-file-1 
> require Library-file 
> test-data-file-1 
> Test-file-2 
> require Library-file 
> test-data-file-2 
> Master-test-file 
> require Test-file-1 Test-file-2 ;; doesn’t work of course…. 
>
> Any suggestions are appreciated. 
>
> Kevin 
>
>
>

-- 
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: Trying to understand the module system.

[Alex Gian]

After some deliberation, and consultation with heads wiser than my own, I 
have decided to abandon the idea of porting the "rule-system" directly. 
There was no point, really. It relies on too many techniques that were 
hacks, albeit very clever ones, in their time, to make up for tools that 
today we take for granted.  (Some of that codee predates OOP, just to give 
an idea)


Even more seriously, the old system paid little - if any - heed to ideas of 
modularity and hygeine -- something which I intend to focus on. So there's 
no point starting off in a way that you don't intend to continue.


An implementation of the core ideas, but set in a more modern framework, is 
a much better idea, even if it does take a bit longer.

I will now look at implementing the rule-system in a more modern setting.  
The good thing is that Racket offers a number of good options for this.


-- 
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] Re: Recommendation for learning syntax?

[Ben Greenman]

Hope this helps with syntax-parse:
http://docs.racket-lang.org/syntax-parse-example/index.html

If not, please submit an issue!

-- 
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] gui change-children portability and nuances

[Neil Van Dyke]

Two questions, as I'm trying to extend the Racket `gui` widgets just a 
little, for small touchscreens, while remaining cross-platform and 
desktop friendly:


1. For all the platforms supported by Racket `gui` widgets, is 
`change-children` a good way to frequently switch among subtrees of 
widgets?  (Like currently for `tab-panel%`, but also for a 
smartphone-like app's dynamic stack of UI pages.)


2. If `change-children` is a good way, is any noteworthy state of a 
widget tree *not* preserved between hiding and unhiding this way, 
assuming that the parent container widget geometry hasn't changed in the 
meantime?  (Offhand, I'm especially interested in whether the current 
scroll position of panels is retained between hiding and unhiding, by 
default, such as when user is going through a big hierarchy of 
Android-style scrolling lists of settings, and not wanting to lose their 
scrolling place when they back up to the big top level.  You could also 
see such page stacks be used for things like what might be modal popup 
windows in a traditional desktop GUI.)


(Reason for asking: I can't tell from the documentation, and this seems 
like a time to ask.  Although I can test behavior with GTK2 and 
GTK3 on GNU/Linux handhelds and desktops, I'd prefer to use an an 
approach that should also work well on all the other Racket `gui` 
platforms (current and future), without expending time right now 
to test on all the current ones. One idea for this handhelds 
unfunded side project (which might not go anywhere) is that 
handheld-oriented apps people make for Racket-on-Linux might also turn 
out to work well for whatever desktop/laptop platform Racketeers use.  
For example, a straightforward set of traditional handheld 
email/IRC/monitoring/etc. apps, but in tiled windows on your desktop 
side monitor or laptop workspace, might work pretty well.  Well enough 
to inspire more such cross-handheld/desktop apps to be written, whatever 
platform the initial developer targets initially.)


--
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] Testing & global variables

[Kevin Forchione]

> On Aug 7, 2018, at 10:56 AM, Alexis King  wrote:
> 
> I guess I’ll take the bait and give the obvious-but-unhelpful answer,
> “Don’t use global variables.” :)
> 
> I’m joking, but only just barely. It seems difficult to give concrete
> advice without knowing more details about your program and why you felt
> it was necessary to use global mutable state in the first place, so
> absent some reason why you need them, I have to recommend you just
> refactor your code to eliminate the globals. The standard techniques for
> writing testable code in other languages still apply in Racket, most
> notably dependency injection (aka “passing arguments to functions”).
> Racket also provides a few tools of its own for managing that kind of
> dynamic parameterization, such as parameters and units.
> 
> Theoretically, an alternative solution would be to create a separate
> namespace (via racket/sandbox or otherwise) for each test file, allowing
> each test to use its own instantiation of the library. This almost
> certainly isn’t what you actually want, though, since real (non-test)
> clients of your library will bump into the same problem, and expecting
> them to do the same workaround is unreasonable. Indeed, I think the
> difficulty of testing an API like this means the the test suite is doing
> what it probably should: hinting that your API is hard to work with and
> needs to be changed.
> 
> Alexis


Here’s a more concrete example: 

Test-file-1
(require library)
(fact foo 10)
(fact bar 30)
(ans (? 30)) 

So the program collects facts and other prolog-like statement into the global, 
then allows that data to be queried (similar to datalog, although I’m not sure 
of datalog’s internals only its syntax and what it does). I suppose what would 
be interesting would be some way of having the library understand what module 
it is a part of and keep track of its data individually. I could probably do 
that by replacing the globals with a hash table and since fact, and, etc are 
macros I could grab the path /filename from the environment and pass that on to 
the library…. parameters are something I’ve not played around with much, but 
that’s something I’ll look into. 

Kevin

-- 
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] Call for Participation: ICFP 2018

['Lindsey Kuper' via users-redirect]

*** Early registration ends 27 August. ***

=

Call for Participation

ICFP 2018
23rd ACM SIGPLAN International Conference on Functional Programming
and affiliated events

September 23 - September 29, 2018
St. Louis, Missouri, USA
http://icfp18.sigplan.org/

=

ICFP provides a forum for researchers and developers to hear
about the latest work on the design, implementations, principles, and
uses of functional programming. The conference covers the entire
spectrum of work, from practice to theory, including its peripheries.

This year, ICFP is co-located with Strange Loop!

Considering attending ICFP for the first time? See our brief
explainer: https://icfp18.sigplan.org/attending/introduction-to-icfp

  * Overview and affiliated events:
http://icfp18.sigplan.org/home

  * Program:
http://icfp18.sigplan.org/program/program-icfp-2018

  * Accepted papers:
http://icfp18.sigplan.org/track/icfp-2018-papers

  * Registration is available via:
https://regmaster4.com/2018conf/ICFP18/register.php
Early registration ends 27 August, 2018.

  * Programming contest results:
https://icfpcontest2018.github.io/

  * Student Research Competition:
https://icfp18.sigplan.org/track/icfp-2018-Student-Research-Competition

  * Follow us on Twitter for the latest news:
http://twitter.com/icfp_conference

In addition to Strange Loop (9/26-9/28), there are several events co-located 
with ICFP:

  * Erlang Workshop (9/29)
  * Functional Art, Music, Modeling and Design (9/29)
  * Functional High-Performance Computing (9/29)
  * Haskell Implementors' Workshop (9/23)
  * Haskell Symposium (9/27-9/28)
  * Higher-order Programming with Effects (9/23)
  * ICFP Tutorials (9/27-9/29)
  * ML Family Workshop (9/28)
  * Numerical Programming in Functional Languages (9/27)
  * OCaml Workshop (9/27)
  * Programming Languages Mentoring Workshop (9/23)
  * Scala Symposium (9/28)
  * Scheme Workshop (9/28)
  * Type-Driven Development (9/27)

Conference Organizers:

General Chair: Robby Findler (Northwestern University, USA)
Program Chair: Matthew Flatt (University of Utah, USA)

Accessibility Chair: Alan Jeffrey (Mozilla Research, USA)
Artefact Evaluation Co-Chair: Simon Marlow (Facebook, UK)
Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA)
PLMW Co-Chair: Dan Licata (Wesleyan University, USA)
PLMW Co-Chair: David Van Horn (University of Maryland, USA)
PLMW Co-Chair: Niki Vazou (University of Maryland, USA)
Programming Contest Organizer: Matthew Fluet (Rochester Institute of 
Technology, USA)
Publications Co-Chair: Alex Potanin (Victoria University of Wellington, New 
Zealand)
Publicity Chair: Lindsey Kuper (UC Santa Cruz, USA)
Student Research Competition Chair: Ravi Chugh (University of Chicago, USA)
Student Volunteer Co-Captain: Jakub Zalewski (University of Edinburgh, UK)
Student Volunteer Co-Captain: Spencer P. Florence (Northwestern University, USA)
Treasurer and Conference Manager: Annabel Satin (P.C.K., UK)
Video Co-Chair Jamie Willis (University of Bristol, UK)
Video Co-Chair: Jose Calderon (Galois, USA)
Workshops Co-Chair: Christophe Scholliers (Ghent University, Belgium)
Workshops Co-Chair: David Christiansen (Galois, USA)

Sponsors and industrial partners:

 Platinum supporters:
   Ahrefs
   Jane Street
   Standard Chartered
   X  

 Gold supporters:
   DFINITY
   Facebook
   Mozilla
   McCormick School of Engineering, Northwestern University

 Silver supporters:
   Bloomberg
   Cal Poly Computer Science & Software Engineering
   Digital Asset
   Galois
   Microsoft Research
   Oracle Labs
   Tweag I/O

 Bronze supporters:
   Google
   IntelliFactory
   Kadena
   Obsidian Systems
   Systor Vest
   Well-Typed

-- 
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] Testing & global variables

[Alexis King]

I guess I’ll take the bait and give the obvious-but-unhelpful answer,
“Don’t use global variables.” :)

I’m joking, but only just barely. It seems difficult to give concrete
advice without knowing more details about your program and why you felt
it was necessary to use global mutable state in the first place, so
absent some reason why you need them, I have to recommend you just
refactor your code to eliminate the globals. The standard techniques for
writing testable code in other languages still apply in Racket, most
notably dependency injection (aka “passing arguments to functions”).
Racket also provides a few tools of its own for managing that kind of
dynamic parameterization, such as parameters and units.

Theoretically, an alternative solution would be to create a separate
namespace (via racket/sandbox or otherwise) for each test file, allowing
each test to use its own instantiation of the library. This almost
certainly isn’t what you actually want, though, since real (non-test)
clients of your library will bump into the same problem, and expecting
them to do the same workaround is unreasonable. Indeed, I think the
difficulty of testing an API like this means the the test suite is doing
what it probably should: hinting that your API is hard to work with and
needs to be changed.

Alexis

> On Aug 7, 2018, at 12:29, Kevin Forchione  wrote:
> 
> I’ve got a library that takes  maintains global variables. I’d like
> to be able to test different test files that require this library, but
> of course if I require those files into a single test file for testing
> various combinations of data it corrupts the global variables, which
> are only valid for a single instance of test file.
> 
> Conceptually it looks like:
> 
> Library-File
>   global a
>   library-functions
> Test-file-1
>   require Library-file
>   test-data-file-1
> Test-file-2
>   require Library-file
>   test-data-file-2
> Master-test-file
>   require Test-file-1 Test-file-2 ;; doesn’t work of course….
> 
> Any suggestions are appreciated.
> 
> Kevin

-- 
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] Testing & global variables

[Kevin Forchione]

I’ve got a library that takes  maintains global variables. I’d like to be able 
to test different test files that require this library, but of course if I 
require those files into a single test file for testing various combinations of 
data it corrupts the global variables, which are only valid for a single 
instance of test file. 

Conceptually it looks like:

Library-File
global a
library-functions
Test-file-1
require Library-file
test-data-file-1
Test-file-2
require Library-file
test-data-file-2
Master-test-file
require Test-file-1 Test-file-2 ;; doesn’t work of course….

Any suggestions are appreciated.

Kevin


-- 
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: Recommendation for learning syntax?

[Alexander McLin]

I was an attendee of Racket Summer School 2018 where we covered 
syntax-parse extensively.

The lecture plans and problem assignments are still available online and 
they together comprise a good tutorial for syntax-parse and language design 
principles.

I encourage you to give it a try! 
https://summer-school.racket-lang.org/2018/plan/  


-- 
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] Recommendation for learning syntax?

[Alex Gian]

Simply put, I find syntax to be a brain

I can do simple stuff, often by extensive study of example code, and I even 
have the odd moment of illumination, which shows me that there is more to 
it than just masochism!

What I do not have is the flow, the mojo, to be able to write syntax like 
second nature, and what's more to intersperse it with normal code without 
freaking out.

So I've decided to bite the bullet and dedicate some quality time to the 
subject, without constantly winging it.  In the light of this, what would 
the good folk here recommend as a reasonable path on which to proceed 
fairly quickly?   I am not averse to meta-anything, but sometimes I just 
don't see the elegance that is supposed to be there.

One of my targets would also be to get the hang of syntax-parse.  Are there 
any tutorials out there?  I do not mind if they are simple.  When it comes 
to syntax, so am I.

-- 
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] parameterized logging

[David Storrs]

I realize it's not ideal Racket, but I've gotten a lot of mileage out of
the following:

;;--

(define prefix-for-say (make-parameter ""))

(define-syntax (say stx)
  (syntax-case stx ()
[(say a ...)
 #'(displayln (~a (prefix-for-say) a ...))]
))

(define-syntax (__WHERE:__ stx) ; Note the ':'
  (with-syntax ((fpath (syntax-source stx))
(line  (syntax-line stx)))
(syntax-case stx ()
  [_ #'(~a "file:" fpath " (line:" line "): ")])))

;;--


I then sprinkle my code with:

(say __WHERE:__ "the thing was: " thing ", and it had " num-owners " owners)

which gets me output like:

file:/Users/dstorrs/some/path/to/file.rkt (line:131): the thing was:
, and it had 7 owners


For threading, I have this:

(define/contract (threaded thnk)
  (-> (-> any) any)

  (define current-prefix (prefix-for-say))

  (define thread-label
(cond [(empty-string? current-prefix) (~a (rand-val "thread") ": ")]
  [else (~a (rand-val "thread") " / " current-prefix)]))

  (parameterize ([prefix-for-say thread-label])
(thread (thunk (begin0 (thnk) (sleep 0)) ; sleep 0 suggests that
the thread run now


(define (foo x)  (threaded (thunk (bar x
(define (bar x)  (threaded (thunk (say x

(foo "hello, world")

And I get output like this:

thread-261855 / thread-861893: hello, world

There are improvements that I could make to this -- for example, make
'threaded' a macro so you don't need to pass a thunk, then special-case it
so that thunks were executed so that existing code continues to work. Also,
'say' could have an option that lets you use println instead of displayln,
or automatically map ~v over arguments. And obviously this system doesn't
take advantage of Racket's hierarchical logging infrastructure.  That said,
it's simple and it works really well for me.



On Tue, Aug 7, 2018 at 11:22 AM, Sean Kanaley  wrote:

> Thanks, Neil. Unfortunately #2 didn't work. The historically written
> define-logger calls like log-something-debug overwrites the "foo" topic
> with "something". If only they were appended together. #3 can't intercept
> logs of define-logger loggers (if a woodchuck could...) even with
> topic/level hardcoded because the #:logger keyword is also needed. So it
> seems like the usage would be a series of nested with-intercepted-loggings,
> one for each define-logger. Lastly, #1 is what I'm trying to avoid :)
>
> To be fair, either #1 or #3 is fully *practical*, but the Racketeer in me
> would prefer to fully automate this. The "proper" solution seems to require
> a Racket change.
>
> Is #3 a bug? Or I might be getting confused at the timing with the
> define-logger = current-logger being used to write the log and the
> interceptor reverting to the previous logger, but the code that seems like
> it should work here:
>
> #lang racket/base
> (require racket/logging)
>
> (define-logger x)
>
> ;works, no define-logger topic though
> (let ([thread-id "hurray"])
>   (with-intercepted-logging
>   (λ (v)
> (printf "~a: ~a~n" thread-id (vector-ref v 1)))
> (λ ()
>   (log-debug "we interrupt this program to bring you this important
> message"))
> 'debug))
>
> ;doesn't work
> (let ([thread-id "hurray"])
>   (with-intercepted-logging
>   (λ (v)
> (printf "~a: ~a~n" thread-id (vector-ref v 1)))
> (λ ()
>   (log-x-debug "we interrupt this program to bring you this important
> message"))
> 'debug))
>
> ;works but messy for many define-loggers
> (let ([thread-id "hurray"])
>   (with-intercepted-logging
>   #:logger x-logger
>   (λ (v)
> (printf "~a: ~a~n" thread-id (vector-ref v 1)))
> (λ ()
>   (log-x-debug "we interrupt this program to bring you this important
> message"))
> 'debug))
>
> --
> 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] Trying to understand the module system.

[Alex Gian]

(new links, old ones not working after refactoring)

> The offending code is here 
 - 
'rules.rkt'  ca. line 173  
> Once it tries to execute the 'rule-system' macro, in order to load up the 
rules, it crashes with the following message.
> The macro is defined here 
 - 
'syntax.rkt' line 49   (I intend to use the chez one which is commented out 
(just for the build))

Oops,  I forgot to put in the message.  Here it is:-  (when trying to run 
rules.rkt)

Welcome to DrRacket, version 6.12 [3m].
Language: racket, with debugging; memory limit: 1024 MB.
rule:make: unbound identifier;
 also, no #%app syntax transformer is bound in: rule:make
> 

*Why would the system give back this message re an identifier KNOWN to be 
bound?*
All requires appear set correctly.
It is bound here 
 
- 'rule-syntax.rkt' line 24, and also invoked in line 54 in the same file. 

-- 
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] parameterized logging

[Sean Kanaley]

Thanks, Neil. Unfortunately #2 didn't work. The historically written
define-logger calls like log-something-debug overwrites the "foo" topic
with "something". If only they were appended together. #3 can't intercept
logs of define-logger loggers (if a woodchuck could...) even with
topic/level hardcoded because the #:logger keyword is also needed. So it
seems like the usage would be a series of nested with-intercepted-loggings,
one for each define-logger. Lastly, #1 is what I'm trying to avoid :)

To be fair, either #1 or #3 is fully *practical*, but the Racketeer in me
would prefer to fully automate this. The "proper" solution seems to require
a Racket change.

Is #3 a bug? Or I might be getting confused at the timing with the
define-logger = current-logger being used to write the log and the
interceptor reverting to the previous logger, but the code that seems like
it should work here:

#lang racket/base
(require racket/logging)

(define-logger x)

;works, no define-logger topic though
(let ([thread-id "hurray"])
  (with-intercepted-logging
  (λ (v)
(printf "~a: ~a~n" thread-id (vector-ref v 1)))
(λ ()
  (log-debug "we interrupt this program to bring you this important
message"))
'debug))

;doesn't work
(let ([thread-id "hurray"])
  (with-intercepted-logging
  (λ (v)
(printf "~a: ~a~n" thread-id (vector-ref v 1)))
(λ ()
  (log-x-debug "we interrupt this program to bring you this important
message"))
'debug))

;works but messy for many define-loggers
(let ([thread-id "hurray"])
  (with-intercepted-logging
  #:logger x-logger
  (λ (v)
(printf "~a: ~a~n" thread-id (vector-ref v 1)))
(λ ()
  (log-x-debug "we interrupt this program to bring you this important
message"))
'debug))

-- 
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] Find out whether the debugger is running

[Erich Rast]

Hi!

Is there a reliable way to find out whether a racket program is
currently running in the debugger?

I've got a deployment function that fails with a cryptic error message
when the language is set to debugging in DrRacket and would like to
print a warning in that case. Deployment ought be with debugging off
anyway. Or can the debugger be switched off programmatically?

Best,

Erich

P.S. In case someone is interested, the error message is:

expand: namespace mismatch; cannot locate module instance
  module: # use phase: 0
  definition phase: 0
  for identifier:
# compilation context...:

-- 
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.