Re: [racket-users] Wills, plumbers, and checking if a port is closed

[Ryan Culpepper]

Here's a function that creates a thread that waits until a port is closed
and then prints a message:

  (define (watch-for-port-close p)
(thread (lambda () (sync (port-closed-evt out)) (eprintf "port
closed\n"

For example:

  (define out (open-output-string))
  (watch-for-port-close out) ;; => #
  (close-output-port out) ;; prints "port closed"

One reason a port can get closed is because of a custodian shutdown, and in
that case you'd need to make sure that the watcher thread and its
current-error-port are not managed by the same custodian. Here's a version
that creates an unkillable thread (generally a bad idea, but probably okay
for debugging):

  (require ffi/unsafe/custodian)
  (define (watch-for-port-close p)
(parameterize ((current-custodian (make-custodian-at-root)))
  (thread (lambda () (sync (port-closed-evt out)) (eprintf "port
closed\n")

Ryan

On Wed, Jul 1, 2020 at 1:08 AM Matthew Flatt  wrote:

> At Tue, 30 Jun 2020 16:27:56 -0400, David Storrs wrote:
> > I have a port that (my current theory says) is being closed when it
> > shouldn't, but I'm having trouble isolating exactly where and when.  I
> > thought maybe I could do something Rackety to say "as soon as this port
> > gets closed, run this function".  I went digging through Wills and
> Plumbers
> > but I'm having trouble grokking it.  Am I headed in the right direction,
> or
> > is there a better way?
>
> Wills and plumbers will not help.
>
> Do you have control over where the port is used to that you can
> substitute another port? In that case, you could wrap the port with
> `make-input-port` or `make-output-port`, and then you have control over
> the close method.
>
> --
> 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/20200630164403.17c%40sirmail.smtp.cs.utah.edu
> .
>

-- 
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/CANy33qn%3Da6gWS0geiYWCd4W%3Djo5mVPSgxye6b_MxvGkzZ1N5Cw%40mail.gmail.com.

Re: [racket-users] Wills, plumbers, and checking if a port is closed

[George Neuner]

On 6/30/2020 4:27 PM, David Storrs wrote:
I have a port that (my current theory says) is being closed when it 
shouldn't, but I'm having trouble isolating exactly where and when.  I 
thought maybe I could do something Rackety to say "as soon as this 
port gets closed, run this function".  I went digging through Wills 
and Plumbers but I'm having trouble grokking it.  Am I headed in the 
right direction, or is there a better way?


Ports are able to raise events.  I don't know if any of these are 
directly useful to diagnose your early close problem, but you may be 
able to cobble something using multiple events.


https://docs.racket-lang.org/reference/sync.html
https://docs.racket-lang.org/reference/port-lib.html?q=port#%28part._.Port_.Events%29


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/47967210-b87b-7a94-a9e2-035a8159e380%40comcast.net.

Re: [racket-users] Wills, plumbers, and checking if a port is closed

[Matthew Flatt]

At Tue, 30 Jun 2020 16:27:56 -0400, David Storrs wrote:
> I have a port that (my current theory says) is being closed when it
> shouldn't, but I'm having trouble isolating exactly where and when.  I
> thought maybe I could do something Rackety to say "as soon as this port
> gets closed, run this function".  I went digging through Wills and Plumbers
> but I'm having trouble grokking it.  Am I headed in the right direction, or
> is there a better way?

Wills and plumbers will not help.

Do you have control over where the port is used to that you can
substitute another port? In that case, you could wrap the port with
`make-input-port` or `make-output-port`, and then you have control over
the close method.

-- 
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/20200630164403.17c%40sirmail.smtp.cs.utah.edu.

Re: [racket-users] Wills, plumbers, and checking if a port is closed

[Sorawee Porncharoenwase]

It doesn't look like will executor will do what you want, since it has to
do with garbage collection rather than port closing.

This could be overkill, but it's possible to construct a custom port (
https://docs.racket-lang.org/reference/customport.html). Is it possible to
construct a new port that wraps your target port inside, and specify the
`close` argument to do whatever you want to do?

On Tue, Jun 30, 2020 at 3:37 PM David Storrs  wrote:

> I have a port that (my current theory says) is being closed when it
> shouldn't, but I'm having trouble isolating exactly where and when.  I
> thought maybe I could do something Rackety to say "as soon as this port
> gets closed, run this function".  I went digging through Wills and Plumbers
> but I'm having trouble grokking it.  Am I headed in the right direction, or
> is there a better way?
>
> --
> 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/CAE8gKofeSmxqSs7RUL-PT0my-JcuW9atP2%2BDdj6o1o_hJVrsmw%40mail.gmail.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/CADcuegueQkjYUq1NTcyEUv-XMhdAYrbh4o0PVtxqs9BEWOgUoA%40mail.gmail.com.

[racket-users] Wills, plumbers, and checking if a port is closed

[David Storrs]

I have a port that (my current theory says) is being closed when it
shouldn't, but I'm having trouble isolating exactly where and when.  I
thought maybe I could do something Rackety to say "as soon as this port
gets closed, run this function".  I went digging through Wills and Plumbers
but I'm having trouble grokking it.  Am I headed in the right direction, or
is there a better way?

-- 
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/CAE8gKofeSmxqSs7RUL-PT0my-JcuW9atP2%2BDdj6o1o_hJVrsmw%40mail.gmail.com.

Re: [racket-users] FYI, build from HEAD fails in realloc()

[Sam Tobin-Hochstadt]

It should be fine to do both of those in the same directory.

Sam

On Tue, Jun 30, 2020 at 4:47 PM 'John Clements' via Racket Users
 wrote:
>
> D’oh!  Closing the loop on this one… it appears to me that this problem 
> occurred after running a “make” (that is, a BC make) in a directory in which 
> I’d been running “make cs”). I just did it again, which is how I figured it 
> out. It’s a silly mistake on my part. It seems that running “math.scrbl” 
> triggers the problem. Honestly, I have no idea if this is a bug or not.
>
> John
>
> > On Mar 23, 2020, at 04:34, Paulo Matos  wrote:
> >
> > Hi John,
> >
> > Has anyone already looked into this? I haven't seen this problem yet. If
> > it's not solved, can you please open an issue?
> >
> > Thanks,
> >
> > Paulo Matos
> >
> > 'John Clements' via Racket Users writes:
> >
> >> Bang! I was wrong. Here’s another similar trace:
> >>
> >> raco setup: 6 running: 
> >> /pfds/pfds/scribblings/functional-data-structures.scrbl
> >> raco setup: 4 running: /jbc-utils/gradeserver/gradeserver.scrbl
> >> raco setup: 3 running: 
> >> /htdp-doc/scribblings/htdp-langs/htdp-langs.scrbl
> >> raco setup: 2 running: /images-doc/images/scribblings/images.scrbl
> >> raco setup: 0 running: 
> >> /macro-debugger/macro-debugger/macro-debugger.scrbl
> >> raco setup: 7 running: /math-doc/math/scribblings/math.scrbl
> >> raco setup: 5 running: /net-doc/net/scribblings/net.scrbl
> >> raco setup: 1 running: 
> >> /compatibility-doc/mzlib/scribblings/mzlib.scrbl
> >> raco setup: 4 running: /racket-doc/openssl/openssl.scrbl
> >> raco setup: 4 running: 
> >> /optimization-coach/optimization-coach/scribblings/optimization-coach.scrbl
> >> raco setup: 4 running: 
> >> /option-contract-doc/scribblings/option-contract.scrbl
> >> raco setup: 4 running: /net-doc/net/scribblings/osx-ssl.scrbl
> >> raco setup: 5 running: /overeasy/overeasy.scrbl
> >> raco setup: 4 running: /parsack/parsack/parsack.scrbl
> >> raco setup: 1 running: 
> >> /parser-tools-doc/parser-tools/parser-tools.scrbl
> >> raco setup: 5 running: /pict-doc/pict/scribblings/pict.scrbl
> >> raco setup: 1 running: 
> >> /pict-snip-doc/scribblings/pict-snip/pict-snip.scrbl
> >> raco setup: 4 running: 
> >> /picturing-programs/picturing-programs/picturing-programs.scrbl
> >> raco setup: 1 running: /racket-doc/pkg/scribblings/pkg.scrbl
> >> raco setup: 4 running: /plai-doc/scribblings/plai.scrbl
> >> raco setup: 1 running: /planet-doc/planet/planet.scrbl
> >> raco setup: 4 running: /plot-doc/plot/scribblings/plot.scrbl
> >> racket(54631,0x762f) malloc: *** error for object 0x12f96cdc8: 
> >> pointer being realloc'd was not allocated
> >> racket(54631,0x762f) malloc: *** set a breakpoint in 
> >> malloc_error_break to debug
> >> make[2]: *** [in-place-setup] Abort trap: 6
> >> make[1]: *** [plain-in-place] Error 2
> >> make: *** [in-place] Error 2
> >> make  240.77s user 75.70s system 398% cpu 1:19.32 total
> >>
> >>
> >>> On Mar 20, 2020, at 3:11 PM, 'John Clements' via Racket Users 
> >>>  wrote:
> >>>
> >>> Here’s the tail of a build of racket HEAD that just failed during a call 
> >>> to realloc(). I went back far enough to be sure I had a full record of 
> >>> what was running on cores 0-7.
> >>>
> >>> I strongly suspect this is not reproducible, and I don’t think there’s 
> >>> any further information that would be useful here, alas.
> >>>
> >>> John
> >>>
> >>> raco setup: 1 running: 
> >>> /pfds/pfds/scribblings/functional-data-structures.scrbl
> >>> raco setup: 0 running: 
> >>> /future-visualizer/future-visualizer/scribblings/future-visualizer.scrbl
> >>> raco setup: 4 running: /games/scribblings/games.scrbl
> >>> raco setup: 6 running: 
> >>> /racket-doc/scribblings/getting-started/getting-started.scrbl
> >>> raco setup: 6 running: /games/gl-board-game/gl-board-game.scrbl
> >>> raco setup: 0 running: /GLPK/glpk/glpk.scrbl
> >>> raco setup: 5 running: /jbc-utils/gradeserver/gradeserver.scrbl
> >>> read-compiled-linklet: version mismatch  expected: "7.6.0.17"  found: 
> >>> "7.6"  in: 
> >>> /Users/clements/git-clements/pkgs/jbc-utils/gradeserver/compiled/gradeserver_scrbl.zo
> >>> context...:
> >>>  read-linklet-or-directory
> >>>  read-dispatch
> >>>  read-syntax
> >>>  default-load-handler
> >>>  standard-module-name-resolver
> >>>  module-path-index-resolve
> >>>  module-declared?
> >>>  /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:1529:27
> >>>  /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:904:0: 
> >>> load-doc/ensure-prefix
> >>>  /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:1162:13
> >>>  .../parallel-do.rkt:388:17
> >>>  
> >>> /Users/clements/racket/racket/collects/setup/../racket/private/more-scheme.rkt:261:28
> >>>  /Users/clements/racket/racket/collects/setup/parallel-do.rkt:441:20: loop
> >>>
> >>> context...:
> >>>  /Users/clements/racket/racket/collects/setup/parallel-do.rkt:332:4: 
> >>> work-done method in list-queue%
> >>>  

Re: [racket-users] FYI, build from HEAD fails in realloc()

['John Clements' via Racket Users]

D’oh!  Closing the loop on this one… it appears to me that this problem 
occurred after running a “make” (that is, a BC make) in a directory in which 
I’d been running “make cs”). I just did it again, which is how I figured it 
out. It’s a silly mistake on my part. It seems that running “math.scrbl” 
triggers the problem. Honestly, I have no idea if this is a bug or not.

John

> On Mar 23, 2020, at 04:34, Paulo Matos  wrote:
> 
> Hi John,
> 
> Has anyone already looked into this? I haven't seen this problem yet. If
> it's not solved, can you please open an issue?
> 
> Thanks,
> 
> Paulo Matos
> 
> 'John Clements' via Racket Users writes:
> 
>> Bang! I was wrong. Here’s another similar trace:
>> 
>> raco setup: 6 running: 
>> /pfds/pfds/scribblings/functional-data-structures.scrbl
>> raco setup: 4 running: /jbc-utils/gradeserver/gradeserver.scrbl
>> raco setup: 3 running: 
>> /htdp-doc/scribblings/htdp-langs/htdp-langs.scrbl
>> raco setup: 2 running: /images-doc/images/scribblings/images.scrbl
>> raco setup: 0 running: 
>> /macro-debugger/macro-debugger/macro-debugger.scrbl
>> raco setup: 7 running: /math-doc/math/scribblings/math.scrbl
>> raco setup: 5 running: /net-doc/net/scribblings/net.scrbl
>> raco setup: 1 running: /compatibility-doc/mzlib/scribblings/mzlib.scrbl
>> raco setup: 4 running: /racket-doc/openssl/openssl.scrbl
>> raco setup: 4 running: 
>> /optimization-coach/optimization-coach/scribblings/optimization-coach.scrbl
>> raco setup: 4 running: 
>> /option-contract-doc/scribblings/option-contract.scrbl
>> raco setup: 4 running: /net-doc/net/scribblings/osx-ssl.scrbl
>> raco setup: 5 running: /overeasy/overeasy.scrbl
>> raco setup: 4 running: /parsack/parsack/parsack.scrbl
>> raco setup: 1 running: 
>> /parser-tools-doc/parser-tools/parser-tools.scrbl
>> raco setup: 5 running: /pict-doc/pict/scribblings/pict.scrbl
>> raco setup: 1 running: 
>> /pict-snip-doc/scribblings/pict-snip/pict-snip.scrbl
>> raco setup: 4 running: 
>> /picturing-programs/picturing-programs/picturing-programs.scrbl
>> raco setup: 1 running: /racket-doc/pkg/scribblings/pkg.scrbl
>> raco setup: 4 running: /plai-doc/scribblings/plai.scrbl
>> raco setup: 1 running: /planet-doc/planet/planet.scrbl
>> raco setup: 4 running: /plot-doc/plot/scribblings/plot.scrbl
>> racket(54631,0x762f) malloc: *** error for object 0x12f96cdc8: 
>> pointer being realloc'd was not allocated
>> racket(54631,0x762f) malloc: *** set a breakpoint in 
>> malloc_error_break to debug
>> make[2]: *** [in-place-setup] Abort trap: 6
>> make[1]: *** [plain-in-place] Error 2
>> make: *** [in-place] Error 2
>> make  240.77s user 75.70s system 398% cpu 1:19.32 total
>> 
>> 
>>> On Mar 20, 2020, at 3:11 PM, 'John Clements' via Racket Users 
>>>  wrote:
>>> 
>>> Here’s the tail of a build of racket HEAD that just failed during a call to 
>>> realloc(). I went back far enough to be sure I had a full record of what 
>>> was running on cores 0-7. 
>>> 
>>> I strongly suspect this is not reproducible, and I don’t think there’s any 
>>> further information that would be useful here, alas.
>>> 
>>> John
>>> 
>>> raco setup: 1 running: 
>>> /pfds/pfds/scribblings/functional-data-structures.scrbl
>>> raco setup: 0 running: 
>>> /future-visualizer/future-visualizer/scribblings/future-visualizer.scrbl
>>> raco setup: 4 running: /games/scribblings/games.scrbl
>>> raco setup: 6 running: 
>>> /racket-doc/scribblings/getting-started/getting-started.scrbl
>>> raco setup: 6 running: /games/gl-board-game/gl-board-game.scrbl
>>> raco setup: 0 running: /GLPK/glpk/glpk.scrbl
>>> raco setup: 5 running: /jbc-utils/gradeserver/gradeserver.scrbl
>>> read-compiled-linklet: version mismatch  expected: "7.6.0.17"  found: "7.6" 
>>>  in: 
>>> /Users/clements/git-clements/pkgs/jbc-utils/gradeserver/compiled/gradeserver_scrbl.zo
>>> context...:
>>>  read-linklet-or-directory
>>>  read-dispatch
>>>  read-syntax
>>>  default-load-handler
>>>  standard-module-name-resolver
>>>  module-path-index-resolve
>>>  module-declared?
>>>  /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:1529:27
>>>  /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:904:0: 
>>> load-doc/ensure-prefix
>>>  /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:1162:13
>>>  .../parallel-do.rkt:388:17
>>>  
>>> /Users/clements/racket/racket/collects/setup/../racket/private/more-scheme.rkt:261:28
>>>  /Users/clements/racket/racket/collects/setup/parallel-do.rkt:441:20: loop
>>> 
>>> context...:
>>>  /Users/clements/racket/racket/collects/setup/parallel-do.rkt:332:4: 
>>> work-done method in list-queue%
>>>  /Users/clements/racket/racket/collects/setup/parallel-do.rkt:282:17
>>>  /Users/clements/racket/racket/collects/setup/parallel-do.rkt:236:4
>>>  /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:138:0: 
>>> setup-scribblings
>>>  /Users/clements/racket/racket/collects/setup/setup-core.rkt:72:0: 
>>> setup-core
>>>  

[racket-users] Re: Understanding P. Ragde's Proust

[Adrian Manea]

Thank you very much for coming back and posting this resource! I will be 
reading it carefully and I'm already sure there is a lot of useful content! 
Much appreciated.

-- 
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/58acb83a-e00a-4e56-84f3-9b50e2d3621do%40googlegroups.com.

[racket-users] Re: Understanding P. Ragde's Proust

[Prabhakar Ragde]

The "free online resource" I alluded to earlier is up on my Web page now.

https://cs.uwaterloo.ca/~plragde/flaneries/LACI/

I call it a "flânerie", but it's a mini-textbook on logic and proof 
assistants, using Racket to first construct a small proof assistant 
(Proust), expanding it to handle propositional and predicate logic, and 
then moving into discussion of the much larger Agda and Coq systems. --PR

On Monday, March 16, 2020 at 8:25:38 AM UTC-4, Adrian Manea wrote:
>
> Dear Prof. Ragde,
>
> Thank you very much for the reply! I watched your talk at the Racket con 
> more carefully today and noticed you specifically point out that you don't 
> give your students the whole code and that the entire project is presented 
> as a "proof of concept" and used especially for didactic purposes.
>
> I totally appreciate this approach and I have to say I don't feel quite 
> prepared to fill in the details myself. So I'm doing my best to learn some 
> preliminaries and general Racket first!
>
> Thank you,
> Adrian
>
> On Monday, March 16, 2020 at 12:08:51 PM UTC, Prabhakar Ragde wrote:
>>
>>
>> Hi! Sorry, I only get this list as a digest, so I didn't see your message 
>> until this morning. The code in the paper is not complete, and the paper 
>> isn't written so that a beginner in Racket could easily extract a working 
>> program from it. When I teach students this material, I give them a working 
>> starter file, and I will send that to you by private email, where we can 
>> also continue to discuss as needed.
>>
>> I am at this moment working on converting my course materials on this 
>> topic into a free online resource similar to the one I did for functional 
>> data structures. But this is not ready yet. I hope to finish it in the next 
>> few months and I will post here when it is ready. --PR
>>
>

-- 
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/1f0d4dd7-6534-4a66-9d45-525e31c1b436o%40googlegroups.com.

[racket-users] Survey reminder

[Stephen De Gabrielle]

Hi,

If you haven't completed it yet...please do.

https://forms.gle/XeHdgv8R7o2VjBbF9
(announcement: https://blog.racket-lang.org/2020/06/racket-survey-2020.html
 )

If you have colleagues or peers who use Racket, or have used Racket in the
past, but are no longer on the mailing list/IRC/Slack, please let
them know. We are after their input too.

It is anonymous by default - you don't need to include any personal
information such as your name or email address. It works fine from a
'privacy tab' in your browser.

I'm happy for you to contact me if you have any questions or concerns.

Kind regards

Stephen

-- 
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/CAGHj7-Ka0%3DmPmbKEY2nn--xz4kDM3ckJf91RBMmfKNG9mZVUsQ%40mail.gmail.com.