Re: [racket-users] [meta] Please review pending member requests?

2022-06-30 Thread thomas_d...@alumni.brown.edu
thanks for the heads up - I'll pass it along :)

On Thursday, June 30, 2022 at 10:30:23 AM UTC-4 jry...@gmail.com wrote:

> I am not a list admin, so I can't help with your original request,
> but... I thought it would be good to highlight that nearly all Racket
> discussion has moved away from these mailing lists and over to the
> Discourse-based forum at https://racket.discourse.group. I would
> recommend moving over there instead as you're more likely to get
> replies.
>
> - Ryan
>
> On Thu, 30 Jun 2022 at 15:24, thomas_d...@alumni.brown.edu
>  wrote:
> >
> > Hi Admins - If you could approve pending subscription requests for the 
> listserv that would be great. One of my interns has been stuck in the queue 
> for more than a week
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/ddaac2fb-8ac5-4a79-84a6-adad2053a690n%40googlegroups.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/4b27b303-a7b6-4f46-bd8d-c800e8ac55acn%40googlegroups.com.


[racket-users] [meta] Please review pending member requests?

2022-06-30 Thread thomas_d...@alumni.brown.edu
Hi Admins - If you could approve pending subscription requests for the 
listserv that would be great. One of my interns has been stuck in the queue 
for more than a week

-- 
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/ddaac2fb-8ac5-4a79-84a6-adad2053a690n%40googlegroups.com.


Re: [racket-users] Porting embedded app from BC to CS

2021-12-20 Thread thomas_d...@alumni.brown.edu
Thanks! A couple follow-up questions inline.

On Monday, December 20, 2021 at 2:34:29 PM UTC-5 Matthew Flatt wrote:

> There's not really anything you can do to catch exception C-side right 
> now. If you need to catch exceptions, that has to be done Racket-side, 
> possibly with a helper created via `racket_eval`. 
>

So what happens from the perspective of embedding C code if an exception 
occurs in Racket code it calls?

You can get `cpointer?` using `racket_primitive`. To disable garbage 
> collection, I don't have a better idea than using `disable-interrupts` 
> and `enable-interrupts` (again, obtained via `racket_primitive`), 
> although that's limited in the sense that `disable-interrupts` could 
> itself allow a GC through before disabling interrupts, at least in 
> principle. 
>
 
I can't seem to locate `disable-interrupts` or `enable-interrupts`  via 
searching the docs, but it sounds like if I needed to compose a sequence of 
several calls into Racket while keeping a consistent view of memory on the 
C side, I could do something like:

racket_apply(racket_primitive("disable-interrupts"),Snil);
// sequence of racket_ function calls
racket_apply(racket_primitive("enable-interrupts"),Snil);

Does that sound correct?

-- 
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/2c776d90-747f-4b57-b965-a08ad02bd3d0n%40googlegroups.com.


[racket-users] Re: Porting embedded app from BC to CS

2021-12-20 Thread thomas_d...@alumni.brown.edu
Gently bumping this thread in the hopes it might get some new eyes.

On Friday, November 5, 2021 at 11:58:07 AM UTC-4 
thomas_d...@alumni.brown.edu wrote:

> I have some fairly simple code setting up an embedded Racket BC instance 
> in a C++ coroutine, allowing me to call `scheme_dynamic_require` a module 
> using a custom #lang (supported by an embedded module) and extract a 
> cpointer matching a certain type tag from the exported symbols.
>
> It *looks* like it should be possible to port this over to even simpler 
> Racket CS code since Racket CS handles suspending itself between calls 
> instead of assuming a main-loop program structure; however I have a few 
> questions here:
>  - What are the preconditions and error-handling setup for calling 
> `racket_dynamic_require` and/or other `racket_*` functions?
>  - How does one obtain a path from a C string to pass to 
> `racket_dynamic_require`? (i.e. what's the equivalent idiom to 
> `scheme_make_path`?
>  - There don't appear to be documented equivalents to SCHEME_CPTRP and 
> SCHEME_CPTR_TYPE. 
> What does `racket_cpointer_address` do if the argument is not a cpointer, 
> and is there some way to check the type tag without triggering garbage 
> collection?
> - One of the hassles with Racket BC is that the garbage collection 
> algorithm intetionally triggers segfaults and uses a signal handler to 
> resolve them, marking it hard to use GDB on the larger embedded 
> application. Does Racket CS have the same behavior, or is this not a 
> problem anymore?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/0e2ce781-1466-4b52-8621-37019eaa59bbn%40googlegroups.com.


[racket-users] Porting embedded app from BC to CS

2021-11-05 Thread thomas_d...@alumni.brown.edu
I have some fairly simple code setting up an embedded Racket BC instance in 
a C++ coroutine, allowing me to call `scheme_dynamic_require` a module 
using a custom #lang (supported by an embedded module) and extract a 
cpointer matching a certain type tag from the exported symbols.

It *looks* like it should be possible to port this over to even simpler 
Racket CS code since Racket CS handles suspending itself between calls 
instead of assuming a main-loop program structure; however I have a few 
questions here:
 - What are the preconditions and error-handling setup for calling 
`racket_dynamic_require` and/or other `racket_*` functions?
 - How does one obtain a path from a C string to pass to 
`racket_dynamic_require`? (i.e. what's the equivalent idiom to 
`scheme_make_path`?
 - There don't appear to be documented equivalents to SCHEME_CPTRP and 
SCHEME_CPTR_TYPE. 
What does `racket_cpointer_address` do if the argument is not a cpointer, 
and is there some way to check the type tag without triggering garbage 
collection?
- One of the hassles with Racket BC is that the garbage collection 
algorithm intetionally triggers segfaults and uses a signal handler to 
resolve them, marking it hard to use GDB on the larger embedded 
application. Does Racket CS have the same behavior, or is this not a 
problem anymore?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/3c713776-3dfc-44f9-b148-b44c623a1d36n%40googlegroups.com.