Re: [racket-users] Cross-VM method for sending any input port to C runtime?

[Philip McGrath]

On Sun, May 23, 2021 at 7:57 PM Matthew Flatt  wrote:

> At Sun, 23 May 2021 14:57:42 +, Sage Gerard wrote:
> > Is there a cross-VM way to pass an arbitrary input port to the C
> > runtime (e.g. via open-input-bytes), such that the C runtime can read
> > bytes on its own?
>
> No, not unless you know that the port's implementation is sufficiently
> constrained. In general, reading from a port can involve thread
> switches and synchronization, and those are not allowed in callbacks
> from foreign libraries.
>

Off hand, I think some some version of "sanitizing" an arbitrary port for
use from C is used by:

   - `racket/system` (here
   

   and here
   
),
   where the implementation comes from `racket/private/streams`;
   - `racket/draw`, for the various parts of Cairo that can read from or
   write to ports, in `racket/draw/unsafe/callback` (and maybe something
   similar in `racket/draw/private/write-bytes`?); and
   - `readline`, which uses callbacks rather than creating file-stream
   ports.

Would it make sense to expose some part of this functionality as a new
primitive?

(I'm not familiar with all of the constraints in these use-cases: maybe
they're different enough that the answer is "no".)

-Philip

-- 
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/010001799bd5ab46-d39f83a5-bb2d-49e5-8ce2-3315307742ac-00%40email.amazonses.com.

Re: [racket-users] Cross-VM method for sending any input port to C runtime?

[Matthew Flatt]

At Sun, 23 May 2021 14:57:42 +, Sage Gerard wrote:
> Is there a cross-VM way to pass an arbitrary input port to the C
> runtime (e.g. via open-input-bytes), such that the C runtime can read
> bytes on its own?

No, not unless you know that the port's implementation is sufficiently
constrained. In general, reading from a port can involve thread
switches and synchronization, and those are not allowed in callbacks
from foreign libraries.

(BC doesn't prohibit non-atomic callbacks as aggressively as CS, but
interacting with the Racket thread scheduler from a callback can go
wrong in various ways with BC, too.)


Matthew

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

[racket-users] CFP: Scheme 2021 - 22nd Scheme and Functional Programming Workshop (Co-located with ICFP 2021)

[web...@gmail.com]

The 2021 Scheme and Functional Programming Workshop is calling for 
submissions.

We invite high-quality papers about novel research results, lessons learned 
from practical experience in industrial or educational setting, and even 
new insights on old ideas. We welcome and encourage submissions that apply 
to any language that can be considered Scheme: from strict subsets of RnRS 
to other “Scheme” implementations, to Racket, to Lisp dialects including 
Clojure, Emacs Lisp, Common Lisp, to functional languages with 
continuations and/or macros (or extended to have them) such as Dylan, 
ECMAScript, Hop, Lua, Scala, Rust, etc. The elegance of the paper and the 
relevance of its topic to the interests of Schemers will matter more than 
the surface syntax of the examples used. Topics of interest include (but 
are not limited to):

Interaction: program-development environments, debugging, testing, 
refactoring
Implementation: interpreters, compilers, tools, garbage collectors, 
benchmarks
Extension: macros, hygiene, domain-specific languages, reflection, and 
how such extension affects interaction.
Expression: control, modularity, ad hoc and parametric polymorphism, 
types, aspects, ownership models, concurrency, distribution, parallelism, 
non-determinism, probabilism, and other programming paradigms
Integration: build tools, deployment, interoperation with other 
languages and systems
Formal semantics: Theory, analyses and transformations, partial 
evaluation
Human Factors: Past, present and future history, evolution and 
sociology of the language Scheme, its standard and its dialects
Education: approaches, experiences, curricula
Applications: industrial uses of Scheme
Scheme pearls: elegant, instructive uses of Scheme

Important dates

Submission deadline is 26 June 2021.
Authors will be notified by 12 July 2021.
Camera-ready versions are due 21 July 2021.
All deadlines are (23:59 UTC-12), “Anywhere on Earth”.
Workshop will be held online 27 August 2021, 11:00--19:30 UTC

Submission Information

Paper submissions must use the format acmart and its sub-format sigplan 
acmsmall (note the change from last year). They must be in PDF, printable 
in black and white on US Letter size. Microsoft Word and LaTeX templates 
for this format are available at:

http://www.sigplan.org/Resources/Author/

This format is in line with ACM conferences (such as ICFP with which we are 
colocated). It is recommended to use the review option when submitting a 
paper; this option enables line numbers for easy reference in reviews.

We want to encourage all kinds of submissions, including full papers, 
experience reports and lightning talks. Papers and experience reports are 
expected to be 10–24 pages in length using the single-column SIGPLAN acmart 
style. (For reference, this is about 5–12 pages of the older SIGPLAN 
2-column 9pt style.) Abstracts submitted for lightning talks should be 
limited to 192 words. Each accepted paper and report will be presented by 
its authors in a 25 minute slot including Q Each accepted lightning talk 
will be presented by its authors in a 5 minute slot, followed by 5 minutes 
of Q

The size limits above exclude references and any optional appendices. There 
are no size limits on appendices, but the papers should stand without the 
need to read them, and reviewers are not required to read them.

Authors are encouraged to publish any code associated to their papers under 
an open source license, so that reviewers may try the code and verify the 
claims.

Proceedings will be published as a Technical Report at Northeastern 
University and uploaded to arXiv.org.

Publication of a paper at this workshop is not intended to replace 
conference or journal publication, and does not preclude re-publication of 
a more complete or finished version of the paper at some later conference 
or in a journal.
Reviewing Process

Scheme 2021 will use lightweight-double-blind reviewing. Submitted papers 
must omit author names and institutions and reference the authors’ own 
related work in the third person (e.g., not “we build on our previous 
work…” but rather “we build on the work of...”).

The purpose is to help the reviewers come to an initial judgement about the 
paper without bias, not to make it impossible for them to discover the 
authors if they were to try. Nothing should be done in the name of 
anonymity that weakens the submission or makes the job of reviewing the 
paper more difficult (e.g., important background references should not be 
omitted or anonymized).
Formatting Information

Full papers and experience reports should use the sigplan acmsmall 
option to acmart.
Lightning talks can be submitted as either a text file or a PDF file.
It is recommended to use the anonymous and review options to acmart 
when submitting a paper; these options hide the author names and enable 
line numbers for easy reference in review.


Submission 

[racket-users] Cross-VM method for sending any input port to C runtime?

[Sage Gerard]

Hi all,

I have a C shared library exposing a simplified interface for computing message 
digests. Here's a `while` that reads bytes using a callback.

https://github.com/zyrolasting/xiden/blob/libcrypto/crypto/crypto.c#L46

A compatible callback provided by Racket might look like this.

(λ (buf size)
(let ([bytes-read (read-bytes! buf (sync variant))])
(if (eof-object? bytes-read) -1 bytes-read)))

I'm also unsure if jumping between the Racket and C runtimes add much overhead, 
but I did it because it looks like `unsafe-port->file-descriptor` will only 
function as expected for file ports.

Is there a cross-VM way to pass an arbitrary input port to the C runtime (e.g. 
via open-input-bytes), such that the C runtime can read bytes on its own?

--
~slg

-- 
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/ee17c05f-3c89-3094-8f9a-d634ddb1d25d%40sagegerard.com.