April 2024 - Gambit-list - mailman.iro.umontreal.ca

1st CfP: SLE 2024 - 17th ACM SIGPLAN International Conference on Software Language Engineering
by Andrei Chis 29 Apr '24

29 Apr '24

------------------------------------------------------------------------ 17th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2024) October 20-25, 2024 Pasadena, California, United States http://www.sleconf.org/2024/ https://2024.splashcon.org/track/sle-2024 Follow us on X: https://x.com/sleconf ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 17th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2024), held in conjunction with SPLASH 2024. The conference will be hosted in Pasadena, California, United States on October 20-25, 2024. --------------------------- Topics of Interest --------------------------- SLE covers software language engineering in general, rather than engineering a specific software language. Topics of interest include, but are not limited to: * Software Language Design and Implementation - Approaches to and methods for language design - Static semantics (e.g., design rules, well-formedness constraints) - Techniques for specifying behavioral/executable semantics - Generative approaches (incl. code synthesis, compilation) - Meta-languages, meta-tools, language workbenches * Validation of Software Language Tools and Implementations - Verification and formal methods for language tools and implementations - Testing techniques for language tools and implementations - Simulation techniques for language tools and implementations * Software Language Maintenance - Software language reuse - Language evolution - Language families and variability, language and software product lines * Software Language Integration and Composition - Coordination of heterogeneous languages and tools - Mappings between languages (incl. transformation languages) - Traceability between languages - Deployment of languages to different platforms * Domain-Specific Approaches for Any Aspects of SLE (analysis, design, implementation, validation, maintenance) * Empirical Studies and Experience Reports of Tools - User studies evaluating usability - Performance benchmarks - Industrial applications * Synergies between Language Engineering and Emerging/Promising Research Areas - AI and ML language engineering (e.g., ML compiler testing, code classification) - Quantum language engineering (e.g., language design for quantum machines) - Language engineering for cyber-physical systems, IoT, digital twins, etc. - Socio-technical systems and language engineering (e.g., language evolution to adapt to social requirements) - Etc. --------------------------- Types of Submissions --------------------------- SLE accepts the following types of papers: Research papers: These are “traditional” papers detailing research contributions to SLE. Papers may range from 6 to 12 pages in length and may optionally include 2 further pages of bibliography/appendices. Papers will be reviewed with an understanding that some results do not need 12 full pages and may be fully described in fewer pages. New ideas/vision papers: These papers may describe new, unconventional software language engineering research positions or approaches that depart from standard practice. They can describe well-defined research ideas that are at an early stage of investigation. They could also provide new evidence to challenge common wisdom, present new unifying theories about existing SLE research that provides novel insight or that can lead to the development of new technologies or approaches, or apply SLE technology to radically new application areas. New ideas/vision papers must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. SLE Body of Knowledge: The SLE Body of Knowledge (SLEBoK) is a community-wide effort to provide a unique and comprehensive description of the concepts, best practices, tools, and methods developed by the SLE community. These papers can focus on, but are not limited to, methods, techniques, best practices, and teaching approaches. Papers in this category can have up to 20 pages, including bibliography/appendices. Tool papers: These papers focus on the tooling aspects often forgotten or neglected in research papers. A good tool paper focuses on practical insights that will likely be useful to other implementers or users in the future. Any of the SLE topics of interest are appropriate areas for tool demonstrations. Submissions must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. They may optionally include an appendix with a demo outline/screenshots and/or a short video/screencast illustrating the tool. **Workshops**: Workshops will be organized by SPLASH. Please inform us and contact the SPLASH organizers if you would like to organize a workshop of interest to the SLE audience. Information on how to submit workshops can be found on the SPLASH 2024 Website. --------------------------- Submission --------------------------- SLE 2024 has a single submission round for papers, including a rebuttal phase, where all authors of research papers will have the possibility of responding to the reviews on their submissions. Authors of accepted research papers will be invited to submit artifacts. --------------------------- Important Dates --------------------------- All dates are Anywhere on Earth (http://en.wikipedia.org/wiki/Anywhere_on_Earth) * Abstract Submissions: Fri 14 Jun, 2024 * Paper Submissions: Mon 24 Jun, 2024 * Authors Response Period: Mon 12 Aug - Sat 17 Aug, 2024 * Authors Notification: Fri 30 Aug 2024 * Conference: Sun 20 October - Fri 25 October 2024 (co-located with SPLASH, precise dates to be announced) --------------------------- Format --------------------------- Submissions have to use the ACM SIGPLAN Conference Format “acmart” (https://sigplan.org/Resources/Author/#acmart-format) please make sure that you always use the latest ACM SIGPLAN acmart LaTeX template, and that the document class definition is `\documentclass[sigplan,anonymous,review]{acmart}`. Do not make any changes to this format! Ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes in figures and tables are legible. To increase fairness in reviewing, a double-blind review process has become standard across SIGPLAN conferences. Accordingly, SLE will follow the double-blind process. Author names and institutions must be omitted from submitted papers, and references to the authors’ own related work should be in the third person. No other changes are necessary, and authors will not be penalized if reviewers are able to infer their identities in implicit ways. All submissions must be in PDF format. The submission website is: https://sle24.hotcrp.com --------------------------- Concurrent Submissions --------------------------- Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy (https://www.sigplan.org/Resources/Policies/Republication/) Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism (https://www.acm.org/publications/policies/plagiarism-overview) Submissions that violate these policies will be desk-rejected. --------------------------- Policy on Human Participant and Subject Research --------------------------- Authors conducting research involving human participants and subjects must ensure that their research complies with their local governing laws and regulations and the ACM’s general principles, as stated in the ACM’s Publications Policy on Research Involving Human Participants and Subjects (https://www.acm.org/publications/policies/research-involving-human-particip…) If submissions are found to be violating this policy, they will be rejected. --------------------------- Reviewing Process --------------------------- All submitted papers will be reviewed by at least three members of the program committee. Research papers and tool papers will be evaluated concerning soundness, relevance, novelty, presentation, and replicability. New ideas/vision papers will be evaluated primarily concerning soundness, relevance, novelty, and presentation. SLEBoK papers will be reviewed on their soundness, relevance, originality, and presentation. Tool papers will be evaluated concerning relevance, presentation, and replicability. For fairness reasons, all submitted papers must conform to the above instructions. Submissions that violate these instructions may be rejected without review at the discretion of the PC chairs. For research papers, authors will get a chance to respond to the reviews before a final decision is made. --------------------------- Artifact Evaluation --------------------------- SLE will use an evaluation process to assess the quality of artifacts on which papers are based to foster the culture of experimental reproducibility. Authors of accepted research papers are invited to submit artifacts. For more information, please see the Artifact Evaluation (https://2024.splashcon.org/track/sle-2024#Artifact-Evaluation) page. --------------------------- Awards --------------------------- Distinguished paper: Award for the most notable paper, as determined by the PC chairs based on the recommendations of the program committee. Distinguished artifact: Award for the artifact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artifact evaluation committee. --------------------------- Publication --------------------------- All accepted papers will be published in the ACM Digital Library. **AUTHORS TAKE NOTE**: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. --------------------------- SLE and Doctoral Students --------------------------- SLE encourages students to submit to the SPLASH doctoral symposium. Authors of accepted doctoral symposium papers on SLE topics will also have the chance to present their work to the SLE audience. --------------------------- Organisation --------------------------- Chairs: * General chair: Ralf Lämmel, Universität Koblenz, Germany * PC co-chair: Peter Mosses, Swansea University and Delft University of Technology, Netherlands * PC co-chair: Juliana Alves Pereira, Pontifícia Universidade Católica do Rio de Janeiro, Brazil * Publicity chair: Andrei Chis, feenk gmbh, Switzerland --------------------------- Contact --------------------------- For additional information, clarification, or answers to questions, please get in touch with the program co-chairs (P.D.Mosses at tudelft.nl and Juliana at inf.puc-rio.br).

1 0

Next PEBCAK... maybe...
by yeti 25 Apr '24

25 Apr '24

Using [Gambit v4.9.5-131-g20d5b2dd] on Debian11/amd64 compiled to live in /opt/gambit: ------------------------------------------------------------------------ ~/wrk/gambit$ cat import-mystery0.scm ;; (import (srfi 1)) (println "ping.") ~/wrk/gambit$ cat import-mystery1.scm (import (srfi 1)) (println "ping.") ~/wrk/gambit$ gsi import-mystery0.scm ping. ~/wrk/gambit$ gsi import-mystery1.scm ping. ~/wrk/gambit$ gsc -exe import-mystery0.scm ~/wrk/gambit$ echo $? 0 ~/wrk/gambit$ ./import-mystery0 ping. ~/wrk/gambit$ gsc -exe import-mystery1.scm ~/wrk/gambit$ echo $? 0 ~/wrk/gambit$ ./import-mystery1 ~/wrk/gambit$ _ ------------------------------------------------------------------------ Adding/removing that (import ...) has some side effects. Similarly with Gambit-4.9.3 from OpenBSD7.3/amd64's ports, so in default paths: ------------------------------------------------------------------------ ~/tmp$ gsi import-mystery0.scm ping. ~/tmp$ gsi import-mystery1.scm ping. ~/tmp$ gsc -exe import-mystery0.scm ~/tmp$ gsc -exe import-mystery1.scm ~/tmp$ ./import-mystery0 ping. ~/tmp$ ./import-mystery1 ~/tmp$ _ ------------------------------------------------------------------------ Should imports be handled differently BY ME for compiled code? -- I do not bite, I just want to play.

2 2

TLS and probably a problem with self signed certificates
by yeti 22 Apr '24

22 Apr '24

Hi! I can strip down the HTTPS example in the manual to the bare minimum, turn it into accessing HTTP, NEX, NNTP and other protocols, add back TLS to e.g. access NNTPS, but with the average Gemini server I'm biting on granite. Not really understanding the error OpenSSL shows, I just assume that it fails with servers using self signed certificates and succeeds with some others because they (re)use a (sub)domain they already have registered with some authority for their HTTPS server. Similarily they seem to succeed or fail using Ncat to access them depending on using "-ssl" or "-ssl-verify" to connect. Is there a way to teach Gambit an additional option for make-tls-context to do similar? -- I do not bite, I just want to play.

3 4

Wrap data from C without copying
by Lassi Kortela 03 Apr '24

03 Apr '24

Can the Gambit FFI return a Scheme numeric vector that is a window into an existing C array? (I.e. the Scheme object header specifies the base and length of the C array but the array elements are not copied.) For example, can it wrap the following C function const void *get_some_data(size_t *size) { const char *str = "hello world"; *size = strlen(str); return str; } such that (get-some-data) returns #u8(104 101 108 108 111 32 119 111 114 108 100) and the contents of that bytevector are not a copy? There are two interesting cases to consider: one where the C array is constant, and one where its elements can be modified. (In both cases, a simple object header pointing to the array only makes sense when the array cannot shrink and cannot be freed. This is similar to slices in Go, and displaced arrays in Common Lisp.) Skimming gambit.h, there are: #define ___U8VECTORREF(v,i) \ ___FIX(___FETCH_U8(___BODY_AS(v,___tSUBTYPED),(i)>>___TB)) #define ___BODY_AS(obj,tag)___BODY0_AS(obj,tag) #define ___BODY0_AS(obj,tag)(___UNTAG_AS(obj,tag)+___REFERENCE_TO_BODY) #define ___UNTAG_AS(obj,tag)___CAST(___WORD*,(obj)-(tag)) #define ___FETCH_U8(base,i)*(___CAST(___U8*,base)+(i)) #define ___REFERENCE_TO_BODY 1 It looks to me like a vector's body is stored directly after the header, but I'm not sure I deciphered the pointer indirection correctly.

2 1