From lassi at lassi.io Sun Jul 5 06:28:58 2020 From: lassi at lassi.io (Lassi Kortela) Date: Sun, 5 Jul 2020 13:28:58 +0300 Subject: [gambit-list] Any research on improving Lisp/Scheme error messages? Message-ID: <4b1eb9d1-6fa5-c51d-7c59-a47db2573ae0@lassi.io> One of the shortcomings of current Scheme and Lisp implementations is that error messages can be intimidating to newcomers and confuse even experienced programmers from time to time. Has there been any academic research on friendlier error messages? A quick Google Scholar search does not turn up any papers. From hashavtech at outlook.com Wed Jul 8 11:17:00 2020 From: hashavtech at outlook.com (hashavtech at outlook.com) Date: Wed, 8 Jul 2020 15:17:00 +0000 Subject: [gambit-list] Problem building on Catalina Message-ID: For some time, I'm having trouble compiling Gambit with SMP on Mac (running Catalina 10.15.4). I've tried with the Apple's clang, I've installed several compilers through Macports, several versions of gcc and clang and I have the same problem: segmentation faults during make modules. Source is from git master, but I've tried going a few months back with no luck. I'm running configure as ./configure --enable-single-host --enable-multiple-versions --enable-multiple-threaded-vms --enable-smp --enable-targets=js (If I leave out one of the --enable-multiple-threaded-vms or --enable-smp flags then it builds ok) and after the make -j && make modules I see stuff like this (in different modules): >>>> building module _match for C >>>> building module _match/match-expand for C /bin/sh: line 7: 65949 Segmentation fault: 11 ../../gsc/gsc -:~~bin=../../bin,~~lib=../../lib,~~include=../../include -f -e "(let ((x (##build-module \"$main_mod\" (quote $target) (quote ((module-ref $modref)))))) (if (not x) (begin (println \"*** module failed to build\") (exit 1))))" or >>>> building module _test/verbose for js /bin/sh: line 7: 66835 Segmentation fault: 11 ../../gsc/gsc -:~~bin=../../bin,~~lib=../../lib,~~include=../../include -f -e "(let ((x (##build-module \"$main_mod\" (quote $target) (quote ((module-ref $modref)))))) (if (not x) (begin (println \"*** module failed to build\") (exit 1))))" Not sure how relevant this is, but if I build Gambit using --enable-smp but without --enable-multiple-threaded-vms, I get a successful build, but then I have one failed test when running make check: [226| 0] 90% ##############.. 10.3s 13-modules/prim_exception.scm *** FAILED 13-modules/prim_exception.scm WITH EXIT CODE HI=1 LO=0 (with-exception-handler ##list (lambda () (##cons 1 (##raise 123)))) in (include "~~lib/gambit/prim/exception#.scm") returned # but expected (1 123) (with-exception-handler ##list (lambda () (##cons 1 (##raise 123)))) in (namespace ("##")) returned # but expected (1 123) [250| 1] 100% ################ 11.3s FAILED 1 UNIT TESTS OUT OF 251 (.4%) gmake[2]: *** [makefile:186: ut] Error 1 gmake[2]: Leaving directory '/Users/ury/sources/gambit/tests' gmake[1]: *** [makefile:183: test11] Error 2 gmake[1]: Leaving directory '/Users/ury/sources/gambit/tests' gmake: *** [makefile:208: check] Error 2 Maybe this problem sounds familiar, or at least maybe there is something I can try to fix or at least to debug it? (This is on an old Macbook, so I would've suspected faulty hardware, but I've tried some rather significant builds such as GTK3 or TeX and they run ok) I'm attaching the full compilation log (this time with GCC 10, but I had the same results with other versions). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gambit_compile.txt URL: From Joerg.Wittenberger at softeyes.net Tue Jul 14 07:46:13 2020 From: Joerg.Wittenberger at softeyes.net (=?UTF-8?B?SsO2cmc=?= F. Wittenberger) Date: Tue, 14 Jul 2020 13:46:13 +0200 Subject: [gambit-list] using IPv6 Message-ID: <20200714134613.6e0e9d7c@devuan> Hi, has anybody an example how to successfully use open-tcp-server or open-tcp-client with IPv6 addresses? Once I tried and failed, now I forgot that I reported it already[1] and failed again. (Note: I'm using gambit 0.9.2 - but it looks to me as if there is no related change since,.) thanks so much J?rg [1]: https://github.com/gambit/gambit/issues/362 From Joerg.Wittenberger at softeyes.net Tue Jul 14 09:35:20 2020 From: Joerg.Wittenberger at softeyes.net (=?UTF-8?B?SsO2cmc=?= F. Wittenberger) Date: Tue, 14 Jul 2020 15:35:20 +0200 Subject: [gambit-list] using IPv6 In-Reply-To: <20200714134613.6e0e9d7c@devuan> References: <20200714134613.6e0e9d7c@devuan> Message-ID: <20200714153520.4c54fd08@devuan> Hi all, looks like things are a bit more strange. Maybe this issue is with lambdanative configuration. I compiled another gambit and this does not segfault. However now I get an error: "address family not supported by protocol". Am Tue, 14 Jul 2020 13:46:13 +0200 schrieb "J?rg F. Wittenberger" : > Hi, > > has anybody an example how to successfully use open-tcp-server or > open-tcp-client with IPv6 addresses? Once I tried and failed, now I > forgot that I reported it already[1] and failed again. > > (Note: I'm using gambit 0.9.2 - but it looks to me as if there is no > related change since,.) > > thanks so much > > J?rg > > [1]: https://github.com/gambit/gambit/issues/362 From feeley at iro.umontreal.ca Tue Jul 14 12:56:20 2020 From: feeley at iro.umontreal.ca (Marc Feeley) Date: Tue, 14 Jul 2020 12:56:20 -0400 Subject: [gambit-list] using IPv6 In-Reply-To: <20200714153520.4c54fd08@devuan> References: <20200714134613.6e0e9d7c@devuan> <20200714153520.4c54fd08@devuan> Message-ID: <22D796BE-53F3-465A-A561-726ECDC1E0DC@iro.umontreal.ca> I justed pushed a fix. For some reason the socket was always created with an address family of AF_INET, which is for IPv4. But I remember testing this in the past? mysterious! Marc > On Jul 14, 2020, at 9:35 AM, J?rg F. Wittenberger wrote: > > Hi all, > > looks like things are a bit more strange. Maybe this issue is with > lambdanative configuration. > > I compiled another gambit and this does not segfault. However now I > get an error: "address family not supported by protocol". > > > Am Tue, 14 Jul 2020 13:46:13 +0200 > schrieb "J?rg F. Wittenberger" : > >> Hi, >> >> has anybody an example how to successfully use open-tcp-server or >> open-tcp-client with IPv6 addresses? Once I tried and failed, now I >> forgot that I reported it already[1] and failed again. >> >> (Note: I'm using gambit 0.9.2 - but it looks to me as if there is no >> related change since,.) >> >> thanks so much >> >> J?rg >> >> [1]: https://github.com/gambit/gambit/issues/362 > > _______________________________________________ > Gambit-list mailing list > Gambit-list at iro.umontreal.ca > https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list From Joerg.Wittenberger at softeyes.net Tue Jul 14 14:25:51 2020 From: Joerg.Wittenberger at softeyes.net (=?UTF-8?B?SsO2cmc=?= F. Wittenberger) Date: Tue, 14 Jul 2020 20:25:51 +0200 Subject: [gambit-list] using IPv6 In-Reply-To: <22D796BE-53F3-465A-A561-726ECDC1E0DC@iro.umontreal.ca> References: <20200714134613.6e0e9d7c@devuan> <20200714153520.4c54fd08@devuan> <22D796BE-53F3-465A-A561-726ECDC1E0DC@iro.umontreal.ca> Message-ID: <20200714202551.74e37021@devuan> Am Tue, 14 Jul 2020 12:56:20 -0400 schrieb Marc Feeley : > I justed pushed a fix. For some reason the socket was always created > with an address family of AF_INET, which is for IPv4. But I remember > testing this in the past? mysterious! As you beat me with approximately 15'' wrt. the pull request (unbelievable; just the time it took me to dig out the issue number again) --- I wonder: is there a syntax to pass ipv6 addresses plus port numbers as a single string? Like "[::1]:80" ? Thanks J?rg From icfp.publicity at googlemail.com Tue Jul 14 15:54:49 2020 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Tue, 14 Jul 2020 15:54:49 -0400 Subject: [gambit-list] Call for Participation: ICFP 2020 Message-ID: <5f0e0d89171ca_93ca21c137d@homer.mail> ===================================================================== Call for Participation ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 23 - August 28, 2020 Online http://icfp20.sigplan.org/ Early Registration until August 8! The ICFP Programming Contest starts on July 17! ===================================================================== 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, the conference will be a virtual event. All activities will take place online. The ICFP Programming competition will be July 17th through 20th, 2020! The main conference will take place from August 24-26, 2020 during two time bands. The first band will be 9AM-5:30PM New York, and will include both technical and social activities. The second band will repeat (with some variation) the technical program and social activities 12 hours later, 9AM-5:30PM Beijing, the following day. We?re excited to announce our two invited speakers for 2020: Evan Czaplicki, covering the Elm programming language and hard lessons learned on driving adoption of new programming languages; and Audrey Tang, Haskeller and Taiwan?s Digital Minister, on how software developers can contribute to fighting the pandemic. ICFP has officially accepted 37 exciting papers, and (as a fresh experiment this year) there will also be presentations of 8 papers accepted recently to the Journal of Functional Programming. Co-located symposia and workshops will take place the day before and two days immediately after the main conference. Registration is now open. The early registration deadline is August 8th, 2020. Registration is not free, but is significantly lower than usual. Students who are ACM or SIGPLAN members may register for FREE before the early deadline. https://regmaster.com/2020conf/ICFP20/register.php New this year: Attendees will be able to sign-up for the ICFP Mentoring Program (either to be a mentor, receive mentorship or both). * Overview and affiliated events: http://icfp20.sigplan.org/home * Accepted papers: http://icfp20.sigplan.org/track/icfp-2020-papers#event-overview * JFP Talks: https://icfp20.sigplan.org/track/icfp-2020-jfp-talks#event-overview * Registration is available via: https://regmaster.com/2020conf/ICFP20/register.php Early registration ends 8 August, 2020. * Programming contest: https://icfpcontest2020.github.io/ The Programming Contest begins July 17th! * Student Research Competition: https://icfp20.sigplan.org/track/icfp-2020-Student-Research-Competition * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference This year, there are 10 events co-located with ICFP: * Erlang Workshop (8/23) * Haskell Implementors' Workshop (8/28) * Haskell Symposium (8/27-8/28) * Higher-Order Programming with Effects (8/23) * miniKanren Workshop (8/27) * ML Family Workshop (8/27) * OCaml Workshop (8/28) * Programming Languages Mentoring Workshop (8/23) * Scheme Workshop (8/28) * Type-Driven Development (8/23) ### ICFP Organizers General Chair: Stephanie Weirich (University of Pennsylvania, USA) Program Chair: Adam Chlipala (MIT, USA) Artifact Evaluation Co-Chairs: Brent Yorgey (Hendrix College, USA) Ben Lippmeier (Ghost Locomotion, Australia) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organizer: Igor Lukanin (Kontur, Russia) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Youyou Cong (Tokyo Institute of Technology, Japan) Workshops Co-Chair: Jennifer Hackett (University of Nottingham, UK) Leonidas Lampropoulos (University of Pennsylvania, USA) Video Chair: Leif Andersen (Northeastern University, USA) Student Volunteer Co-Chair: Hanneli Tavante (McGill University, Canada) Victor Lanvin (IRIF, Universit? Paris Diderot, France) From Joerg.Wittenberger at softeyes.net Wed Jul 15 05:17:33 2020 From: Joerg.Wittenberger at softeyes.net (=?UTF-8?B?SsO2cmc=?= F. Wittenberger) Date: Wed, 15 Jul 2020 11:17:33 +0200 Subject: [gambit-list] using IPv6 In-Reply-To: <22D796BE-53F3-465A-A561-726ECDC1E0DC@iro.umontreal.ca> References: <20200714134613.6e0e9d7c@devuan> <20200714153520.4c54fd08@devuan> <22D796BE-53F3-465A-A561-726ECDC1E0DC@iro.umontreal.ca> Message-ID: <20200715111733.205ace28@devuan> Hello Marc, yesterdays patch works for open-tcp-server and friends. However open-tcp-client still does not work for me. I figured out that by supplying just a destination address like so: (open-tcp-client '(address: '#16(0 0 0 0 0 0 0 1) port-number: 80)) the code would still try to set up the local address to AF_INET. Supplying a local-address: component to the settings seems a bit wierd from a usability perspective, but at least it gets me past this point. But if I do, like so: (open-tcp-client '(address: '#16(0 0 0 0 0 0 0 1) port-number: 80 local-address: '#16(0 0 0 0 0 0 0 1) port-number: 0)) I get an error "Cannot assign requested address". Likely this calls for an improvement of ##open-tcp-client in _io.scm. But I must admit that I don't grok this codes logic. Best J?rg Am Tue, 14 Jul 2020 12:56:20 -0400 schrieb Marc Feeley : > I justed pushed a fix. For some reason the socket was always created > with an address family of AF_INET, which is for IPv4. But I remember > testing this in the past? mysterious! > > Marc > > > > > On Jul 14, 2020, at 9:35 AM, J?rg F. Wittenberger > > wrote: > > > > Hi all, > > > > looks like things are a bit more strange. Maybe this issue is with > > lambdanative configuration. > > > > I compiled another gambit and this does not segfault. However now I > > get an error: "address family not supported by protocol". > > > > > > Am Tue, 14 Jul 2020 13:46:13 +0200 > > schrieb "J?rg F. Wittenberger" : > > > >> Hi, > >> > >> has anybody an example how to successfully use open-tcp-server or > >> open-tcp-client with IPv6 addresses? Once I tried and failed, now > >> I forgot that I reported it already[1] and failed again. > >> > >> (Note: I'm using gambit 0.9.2 - but it looks to me as if there is > >> no related change since,.) > >> > >> thanks so much > >> > >> J?rg > >> > >> [1]: https://github.com/gambit/gambit/issues/362 From publicityifl at gmail.com Wed Jul 15 09:35:26 2020 From: publicityifl at gmail.com (Jurriaan Hage) Date: Wed, 15 Jul 2020 09:35:26 -0400 Subject: [gambit-list] Second call for draft papers for IFL 2020 (Implementation and Application of Functional Languages) Message-ID: Hello, Please, find below the second call for draft papers for IFL 2020. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL ================================================================================ IFL 2020 32nd Symposium on Implementation and Application of Functional Languages venue: online 2nd - 4th September 2020 https://www.cs.kent.ac.uk/events/2020/ifl20/ ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2020 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialisation - run-time code generation - partial evaluation - (abstract) interpretation - meta-programming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Post-symposium peer-review Following IFL tradition, IFL 2020 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected for the formal proceedings. We plan to publish these proceedings in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. ### Important dates Submission deadline of draft papers: 17 August 2020 Notification of acceptance for presentation: 19 August 2020 Registration deadline: 31 August 2020 IFL Symposium: 2-4 September 2020 Submission of papers for proceedings: 7 December 2020 Notification of acceptance: 3 February 2021 Camera-ready version: 15 March 2021 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Programme committee Kenichi Asai, Ochanomizu University, Japan Olaf Chitil, University of Kent, United Kingdom (chair) Martin Erwig, Oregon State University,United States Daniel Horpacsi, Eotvos Lorand University, Hungary Zhenjiang Hu, Peking University, China Hans-Wolfgang Loidl, Heriot-Watt University, United Kingdom Neil Mitchell, Facebook, UK Marco T. Morazan, Seton Hall University, United States Rinus Plasmeijer, Radboud University, Netherlands Colin Runciman, University of York, United Kingdom Mary Sheeran, Chalmers University of Technology, Sweden Josep Silva, Universitat Politecnica de Valencia, Spain Jurrien Stutterheim, Standard Chartered, Singapore Josef Svenningsson, Facebook, UK Peter Thiemann, University of Freiburg, Germany Kanae Tsushima, National Institute of Informatics, Japan. Marcos Viera, Universidad de la Republica, Montevideo, Uruguay Janis Voigtlander, University of Duisburg-Essen, Germany ### Virtual symposium Because of the Covid-19 pandemic, this year IFL 2020 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Thu Jul 16 09:56:51 2020 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Thu, 16 Jul 2020 09:56:51 -0400 Subject: [gambit-list] Final Call for Tutorials, Discussions, and Social Events: ICFP 2020 Message-ID: <5f105ca32f1e1_d5ed2941345@homer.mail> FINAL CALL FOR TUTORIAL, DISCUSSION, AND SOCIAL EVENT PROPOSALS ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 23 - 28, 2020 Virtual https://icfp20.sigplan.org/ The 25th ACM SIGPLAN International Conference on Functional Programming will be held virtually on August 23-28, 2020. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". To increase social interaction on the first ICFP virtual conference, this year we invite proposals for social events on topics of broader interest to the PL community. Such events can be panels and discussions (in the lines of the successful #ShutDownPL event), focused discussions (e.g., problem identifications, retrospective analysis, technical demos), social activities (e.g., treasure hunt, bingo, problem solving, artistic challenges). The typical duration of such events ranges from 30 minutes to one hour, but can be of any length. Tutorials may occur before or after ICFP, co-located with the associated workshops, on August 23 or August 27-28. Social events may be scheduled throughout the week. ---------------------------------------------------------------------- Submission details Deadline for submission: July 17th, 2020 Notification of acceptance: July 22nd, 2020 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2020 workshop co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020 at googlegroups.com by July 17th, 2020. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by July 22nd, 2020. The proposal form is available at: http://www.icfpconference.org/icfp2020-files/icfp20-panel-form.txt http://www.icfpconference.org/icfp2020-files/icfp20-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2020 organizing committee. Tutorials Co-Chair: Jennifer Hackett (University of Nottingham) Tutorials Co-Chair: Leonidas Lampropoulos (University of Maryland) General Chair: Stephanie Weirich (University of Pennsylvania) Program Chair: Adam Chlipala (MIT) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020 at googlegroups.com From lassi at lassi.io Sat Jul 18 06:30:26 2020 From: lassi at lassi.io (Lassi Kortela) Date: Sat, 18 Jul 2020 13:30:26 +0300 Subject: [gambit-list] Returning homogeneous numeric vectors from C to Scheme Message-ID: <626bf08c-2e60-2019-a930-68455c03429d@lassi.io> How would one use the FFI to make a fresh s64vector with the same values as a C int64_t[] array? In gambit.h I can only find ___make_vector() which makes a generic vector. From gucartier at gmail.com Sat Jul 18 06:47:30 2020 From: gucartier at gmail.com (Guillaume Cartier) Date: Sat, 18 Jul 2020 06:47:30 -0400 Subject: [gambit-list] Returning homogeneous numeric vectors from C to Scheme In-Reply-To: <626bf08c-2e60-2019-a930-68455c03429d@lassi.io> References: <626bf08c-2e60-2019-a930-68455c03429d@lassi.io> Message-ID: ___SCMOBJ result = ___EXT(___alloc_scmobj) (NULL, ___sF64VECTOR, count*sizeof(___F64)); double *ptr = ___CAST(double*,___BODY(result)); ... ___EXT(___release_scmobj)(result); return result; On Sat, Jul 18, 2020 at 6:30 AM Lassi Kortela wrote: > How would one use the FFI to make a fresh s64vector with the same values > as a C int64_t[] array? In gambit.h I can only find ___make_vector() > which makes a generic vector. > > _______________________________________________ > Gambit-list mailing list > Gambit-list at iro.umontreal.ca > https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lassi at lassi.io Sat Jul 18 07:10:34 2020 From: lassi at lassi.io (Lassi Kortela) Date: Sat, 18 Jul 2020 14:10:34 +0300 Subject: [gambit-list] Returning homogeneous numeric vectors from C to Scheme In-Reply-To: References: <626bf08c-2e60-2019-a930-68455c03429d@lassi.io> Message-ID: <363315f2-4a75-15f4-cbda-5f1dccb8cea1@lassi.io> > ___SCMOBJ result = ___EXT(___alloc_scmobj) (NULL, ___sF64VECTOR, > count*sizeof(___F64)); > double *ptr = ___CAST(double*,___BODY(result)); > > ... > > ___EXT(___release_scmobj)(result); > return result; Nice. Thanks for the super-quick reply! (define get-test-s64vector (c-lambda () scheme-object #< Which of the following is the better strategy for calling C functions that fill a pre-allocated buffer but might fail? Option 1. First malloc() a temporary buffer in C, call the desired C function to fill that buffer, and if the C function succeeds then allocate a Scheme string/vector of the same size as the temp buffer and copy the temp buffer into it. If the C function fails, free() the temp buffer and return an error value to Scheme. Option 2. First allocate a Scheme string/vector of the right size, then call the desired C function to fill it directly. No temporary buffer is used. If the C function fails, free the Scheme object. (Which function in the Gambit FFI does this?) Does GC present complexities for option 2 (especially when interacting threads and/or signals)? From lassi at lassi.io Sat Jul 18 09:28:06 2020 From: lassi at lassi.io (Lassi Kortela) Date: Sat, 18 Jul 2020 16:28:06 +0300 Subject: [gambit-list] Allocate Scheme vector before or after C call? In-Reply-To: <76df14c0-3e81-9616-9ca6-fbf6ab76c94c@lassi.io> References: <76df14c0-3e81-9616-9ca6-fbf6ab76c94c@lassi.io> Message-ID: Especially thinking of the common C idiom where we don't know the right buffer size in advance, and keep trying increasing powers-of-two until we find one that works. Pseudo-code: for (n = 32; n < size_limit; n *= 2) { ___SCMOBJ vector = ___EXT(___alloc_scmobj)(NULL, ___sFooVECTOR, n * sizeof(foo_t)); foo_t *body = ___CAST(foo_t *, ___BODY(vector)); int result = get_value_from_some_c_api(body, n); ___EXT(___release_scmobj)(vector); if (result == success) { ___return(vector); } else if (result != buffer_too_small) { ___return(___FAL); } // dispose of the vector here } ___return(___FAL); Another option would be to do the above loop using standard C realloc(), but then have a Gambit API that "takes ownership" of a buffer that comes from malloc() and adds a Scheme object header to it. Does that kind of approach make any sense in Gambit? From feeley at iro.umontreal.ca Sat Jul 18 13:40:49 2020 From: feeley at iro.umontreal.ca (Marc Feeley) Date: Sat, 18 Jul 2020 13:40:49 -0400 Subject: [gambit-list] Returning homogeneous numeric vectors from C to Scheme In-Reply-To: <363315f2-4a75-15f4-cbda-5f1dccb8cea1@lassi.io> References: <626bf08c-2e60-2019-a930-68455c03429d@lassi.io> <363315f2-4a75-15f4-cbda-5f1dccb8cea1@lassi.io> Message-ID: Lassi, the first parameter of ___alloc_scmobj indicates if the object is a permanently allocated object (NULL) or a garbage collectible ?still? object (processor state pointer). Here is the documentation in lib/mem.c: /* * '___alloc_scmobj (___ps, subtype, bytes)' allocates a permanent or * still Scheme object (depending on '___ps') of subtype 'subtype' * with a body containing 'bytes' bytes, and returns it as an encoded * Scheme object. When '___ps' is NULL, a permanent object is * allocated, and when '___ps' is not NULL, a still object is * allocated in the heap of that processor's VM. The initialization * of the object's body must be done by the caller. In the case of * still objects this initialization must be done before the next * allocation is requested. The 'refcount' field of still objects is * initially 1. A fixnum error code is returned when there is an * error. */ So you probably want to pass ?___ps? (or ?___PSTATE?) as the first parameter, and check that there wasn?t a heap overflow: if (___FIXNUMP(result)) ___return(___FAL); Ideally Gambit's C-interface (FFI) should support passing Scheme homogeneous vectors to C and returning C arrays to Scheme (converted to the appropriate Scheme vector type), but this is not obvious to do because typically C arrays don?t have a statically known length, so the C-interface would need to pass Scheme homogeneous vectors to C as 2 parameters, a pointer and a size_t length (but in which order, and maybe you don?t care to pass the length). And should the array be copied (slow) or not (fast but possible problems with GC). Suggestions are welcome? Marc > On Jul 18, 2020, at 7:10 AM, Lassi Kortela wrote: > >> ___SCMOBJ result = ___EXT(___alloc_scmobj) (NULL, ___sF64VECTOR, count*sizeof(___F64)); >> double *ptr = ___CAST(double*,___BODY(result)); >> ... >> ___EXT(___release_scmobj)(result); >> return result; > > Nice. Thanks for the super-quick reply! > > (define get-test-s64vector > (c-lambda () scheme-object #< static ___S64 c_ints[32]; > size_t nbytes = sizeof(c_ints); > size_t n = nbytes / sizeof(___S64); > size_t i; > for (i = 0; i < n; i += 2) c_ints[i] = i; > for (i = 1; i < n; i += 2) c_ints[i] = -i; > ___SCMOBJ result = ___EXT(___alloc_scmobj)(NULL, ___sS64VECTOR, nbytes); > ___S64 *scheme_ints = ___CAST(___S64 *, ___BODY(result)); > for (i = 0; i < n; i++) scheme_ints[i] = c_ints[i]; > ___EXT(___release_scmobj)(result); > ___return(result); > c-lambda-end > )) > > $ gsc test.scm > $ gsi test.o1 -e "(pp (get-test-s64vector))" > #s64(0 -1 2 -3 4 -5 6 -7 8 -9 10 -11 12 -13 14 -15 16 -17 18 -19 20 -21 22 -23 24 -25 26 -27 28 -29 30 -31) > > _______________________________________________ > Gambit-list mailing list > Gambit-list at iro.umontreal.ca > https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list > From feeley at iro.umontreal.ca Sat Jul 18 14:14:20 2020 From: feeley at iro.umontreal.ca (Marc Feeley) Date: Sat, 18 Jul 2020 14:14:20 -0400 Subject: [gambit-list] Allocate Scheme vector before or after C call? In-Reply-To: <76df14c0-3e81-9616-9ca6-fbf6ab76c94c@lassi.io> References: <76df14c0-3e81-9616-9ca6-fbf6ab76c94c@lassi.io> Message-ID: <1771316B-8E0C-4111-A8DB-555CD1B5AA65@iro.umontreal.ca> Still objects are essentially allocated with malloc (with an extra header and properly aligned), but the allocated bytes are accounted as being part of the ?Scheme heap? and if this exceeds the current Scheme heap size the garbage collector is called to free some space (this may call free if some of the still objects are no longer accessible from the Scheme world and their refcount is 0). Note that the refcount counts the number of references external to the Scheme heap (typically references from the C world). When control is transferred from Scheme to C (when a c-lambda is called), the garbage collector will only be triggered when control returns to Scheme from C, or when the C code performs an allocation on the Scheme heap (using ___alloc_scmobj, ___make_vector, ___make_pair, a C to Scheme conversion function, etc). So by carefully writing the C code (avoiding Scheme object allocation) it is possible to guarantee that the GC is not triggered. When this can?t be avoided, it is important to remember that the GC can move any movable Scheme object (which is the normal allocation strategy for small Scheme objects allocated in Scheme code), but permanent and still objects will not move. This is the reason why the C allocation functions in for Scheme objects allocate non-movable objects? it makes it possible with no extra bookkeeping to store references to the objects anywhere without concern that a GC will move the objects. So concerning your question? Option 1 (malloc temporary buffer in C, and copy it into a Scheme vector) will avoid GC issues, but it is slow (double allocation and copy). Option 2 (preallocating a buffer in Scheme code and passing it to C) may be problematic when the Scheme buffer is a movable object. This will require the C code to avoid any additional Scheme object allocation. This could be circumvented by calling a Scheme allocation procedure that guarantees that the result is a still object. One way to do this is to call ##still-copy to create a still object that is a copy of its parameter, e.g. (##still-copy (u8vector 1 2 3)). The ___alloc_scmobj C function could also be called (with suitable interface code). No special code is needed to have the GC deallocate the object. Option 3 (allocating buffer in C and ?transferring ownership? to Scheme) is possible, but not the way you think. The end result won?t be a Scheme vector? it will be a foreign object that points to the C buffer. In a sense this is the cleanest solution as it separates the Scheme and C worlds. However it makes accessing the contents of the C buffer from Scheme somewhat painful (you need to define your own accessor procedures for this). I would avoid option 1 and use options 2 and 3 depending on the needs of the application (is the data shared between C and Scheme, or Scheme is just glue code to receive raw data from C and pass it to some other C function). Marc > On Jul 18, 2020, at 9:14 AM, Lassi Kortela wrote: > > Which of the following is the better strategy for calling C functions that fill a pre-allocated buffer but might fail? > > Option 1. First malloc() a temporary buffer in C, call the desired C function to fill that buffer, and if the C function succeeds then allocate a Scheme string/vector of the same size as the temp buffer and copy the temp buffer into it. If the C function fails, free() the temp buffer and return an error value to Scheme. > > Option 2. First allocate a Scheme string/vector of the right size, then call the desired C function to fill it directly. No temporary buffer is used. If the C function fails, free the Scheme object. (Which function in the Gambit FFI does this?) > > Does GC present complexities for option 2 (especially when interacting threads and/or signals)? > > _______________________________________________ > Gambit-list mailing list > Gambit-list at iro.umontreal.ca > https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list > From Joerg.Wittenberger at softeyes.net Sun Jul 19 13:08:22 2020 From: Joerg.Wittenberger at softeyes.net (=?UTF-8?B?SsO2cmc=?= F. Wittenberger) Date: Sun, 19 Jul 2020 19:08:22 +0200 Subject: [gambit-list] How to use ports created from aopen file descriptors Message-ID: <20200719190822.01ea8173@devuan> Hi, once I learned that ##open-predefined could be used to create a port from an already opened file descriptor (in addition to the standard streams). This did work for me as long as I used just one FD that way and used it until the programm terminated. However now I need to actually close the port and want the FD being closed too. However in os_io.c around line 9932ff I found: * ........... The responsibility for closing the stream is not * transferred to the runtime system because ... I obviously need the other way around. How would I transfer the ownership of an FD to the runtime system? (A second, related issue I'm looking into is that ##open-predefined will add an exit job for each writable FD. This too is not desirable in my case. However cut&paste of ##open-predefined and modification looks easy enough to get rid of the latter. What I wonder is how I would have (ab)use the C code side with preferrable non to minimal modifications.) Best J?rg From lassi at lassi.io Mon Jul 20 07:07:18 2020 From: lassi at lassi.io (Lassi Kortela) Date: Mon, 20 Jul 2020 14:07:18 +0300 Subject: [gambit-list] Allocate Scheme vector before or after C call? In-Reply-To: <1771316B-8E0C-4111-A8DB-555CD1B5AA65@iro.umontreal.ca> References: <76df14c0-3e81-9616-9ca6-fbf6ab76c94c@lassi.io> <1771316B-8E0C-4111-A8DB-555CD1B5AA65@iro.umontreal.ca> Message-ID: <5cf22e4f-ebe3-87bb-573b-f55c39570165@lassi.io> Marc, thank you once again for the excellent explanation. You have a knack for explaining complex topics clearly. We should start collecting and editing this stuff into the Gambit manual proper. Here's a Unix getgroups() wrapper that allocates increasing powers of two until the result fits. We should finish up SRFI 170 (POSIX APIs) with Harold; since the Unix syscall interface is designed such that the kernel copies data into statically-sized userland buffers, many syscalls are best wrapped by trying powers of two. The below code raises more potential problems: - I'm still not confident that I understand when and how to release objects. In the code below, __release_scmobj is used to wrap up accessing ___BODY; is this right? - getgroups() returns a gid_t array but POSIX doesn't say how many bits wide gid_t is. (In fact, it doesn't even say whether it's a signed or unsigned type.) This is the case for many/most C datatypes. An API like ___alloc_sint_vector(NULL, count, sizeof(gid_t)) would help with this. - getgroups() can return fewer entries than we allocated buffer space for. Does Gambit have a way of truncating vectors? In general, there is no way to know ahead of time the exact size needed for result buffers: some syscalls accept a NULL buffer to not copy any data and only return the right buffer size, but relying on that size can lead to race conditions between that call and the next call that supplies a non-NULL buffer to actually copy the data. Clojure transients might be a good model for Scheme FFI in situations like this. Clojure is mostly an immutable language, but a transient is a mutable collection that is "sealed" into an immutable one once it has been filled; transients were added for performance reasons. While Scheme strings and vectors are mutable, their size cannot change (at least not by RnRS means) so in that respect they are immutable. Perhaps Gambit's object header can be hacked from C code to mutate a vector to have fewer actual elements than space is allocated for. Is such a thing safe to do, and would it be workable to have an official way in the FFI to truncate a vector? ---------------------------------------------------------------------- (c-declare "#include ") (define getgroups (c-lambda () scheme-object #<= 0) ___return(vector); } ___return(___FAL); c-end )) (define (writeln x) (write x) (newline)) (let ((gs (getgroups))) (writeln gs) (writeln (s32vector-length gs))) From feeley at iro.umontreal.ca Mon Jul 20 11:59:05 2020 From: feeley at iro.umontreal.ca (Marc Feeley) Date: Mon, 20 Jul 2020 11:59:05 -0400 Subject: [gambit-list] Allocate Scheme vector before or after C call? In-Reply-To: <5cf22e4f-ebe3-87bb-573b-f55c39570165@lassi.io> References: <76df14c0-3e81-9616-9ca6-fbf6ab76c94c@lassi.io> <1771316B-8E0C-4111-A8DB-555CD1B5AA65@iro.umontreal.ca> <5cf22e4f-ebe3-87bb-573b-f55c39570165@lassi.io> Message-ID: <1C85E104-5B31-4194-BAE7-45D59706ACF6@iro.umontreal.ca> The function ___release_scmobj(obj) doesn?t free the object. Only the GC can do that. The function ___release_scmobj(obj) decrements the refcount to indicate that the C world no longer references obj, but because obj is returned from C to Scheme it is still reachable by the Scheme world and will not be reclaimed until the Scheme world is done using it. Moreover Gambit supports a vector shrinking operation: > (define v (vector 1 2 3 4 5 6)) > v #(1 2 3 4 5 6) > (vector-shrink! v 3) > v #(1 2 3) > (vector-shrink! v 42) *** ERROR IN (stdin)@5.1 -- (Argument 2) Out of range (vector-shrink! #(1 2 3) 42) The fact that the width (and sign) of gid_t is not known at Scheme compilation time can be managed with some C macros. The problem I see however is that the resulting homogeneous vector will have a type that depends on the underlying OS, so it is a leaky API. It would be better to return a normal vector of the group ids. Let me propose 2 solutions (see code below): 1) which returns a homogeneous vector and doesn?t call malloc (but that is a leaky API) 2) which returns a normal vector of fixnums and sometimes calls malloc/free Solution 2 uses a small statically allocated buffer so that malloc/free can frequently be avoided. In a quick test it is about 30% faster than solution 1. Marc (c-declare #< #include /* compute log base 2 of a power of 2 */ #define LOG2(pow2) LOG2STEP(LOG2STEP(LOG2STEP((pow2-1),1,85),2,51),4,15) #define LOG2STEP(n,shift,mask) (((n >> shift) & mask)+(n & mask)) #define LOG2_SIZEOF(type) LOG2(sizeof(type)) #define IS_UNSIGNED(type) (0<___CAST(type,-1)) #define HOMVEC_SUBTYPE(type) \ homvec_subtypes[___CAST(type,0.5) == 0 \ ? LOG2_SIZEOF(type)*2 + IS_UNSIGNED(type) \ : 8 - 2 + LOG2_SIZEOF(type)] static int homvec_subtypes[] = { ___sS8VECTOR ,___sU8VECTOR ,___sS16VECTOR,___sU16VECTOR ,___sS32VECTOR,___sU32VECTOR,___sS64VECTOR,___sU64VECTOR ,___sF32VECTOR,___sF64VECTOR }; #define HOMVEC_ALLOC_STILL(type, nb_elems) \ ___EXT(___alloc_scmobj)(___PSTATE, HOMVEC_SUBTYPE(type), sizeof(type)*nb_elems) #define HOMVEC_SHRINK(vect, type, nb_elems) \ do { \ ___SCMOBJ ___temp; \ ___U8VECTORSHRINK(vect,___FIX(sizeof(type)*nb_elems)); \ } while (0) ___SCMOBJ os_getgroups() { ___SCMOBJ result; /* homogeneous vector of group ids */ int len; /* actual length, determined later */ int cap = getgroups(0, NULL); /* first approximation of number of groups */ if (cap < 0) return ___FIX(___ERRNO_ERR(errno)); for (;;) { result = HOMVEC_ALLOC_STILL(gid_t, cap); if (___FIXNUMP(result)) return result; ___EXT(___release_scmobj)(result); if (cap == 0) /* guard against special meaning of getgroups(0,...) */ return result; len = getgroups(cap, ___CAST(gid_t*,___BODY_AS(result,___tSUBTYPED))); if (len >= 0) break; if (errno == EINVAL) { if (cap >= 1000000) { /* arbitrary implementation limit */ return ___FIX(___IMPL_LIMIT_ERR); } else { cap = cap*2; /* will try again with larger buffer */ } } else { return ___FIX(___ERRNO_ERR(errno)); } } HOMVEC_SHRINK(result, gid_t, len); /* shrink vector to actual length */ return result; } /* Alternative definition which returns a normal vector */ #include ___SCMOBJ os_getgroups2() { const int static_cap = 100; /* within this limit, no call to malloc */ gid_t buffer[static_cap]; gid_t *buf = buffer; int cap = static_cap; ___SCMOBJ result; /* homogeneous vector of group ids */ int len; /* actual length, determined later */ for (;;) { len = getgroups(cap, buf); if (len >= 0) break; if (errno == EINVAL) { if (buf != buffer) free(buf); if (cap >= 1000000) { /* arbitrary implementation limit */ return ___FIX(___IMPL_LIMIT_ERR); } else { cap = cap*2; /* will try again with larger buffer */ buf = malloc(sizeof(gid_t)*cap); if (buf == NULL) return ___FIX(___HEAP_OVERFLOW_ERR); } } else { if (buf != buffer) free(buf); return ___FIX(___ERRNO_ERR(errno)); } } result = ___EXT(___make_vector)(___PSTATE, len, ___FIX(0)); if (!___FIXNUMP(result)) { while (len-- > 0) ___VECTORSET(result, ___FIX(len), ___FIX(buf[len])) } if (buf != buffer) free(buf); return ___EXT(___release_scmobj(result)); } end-of-c-declare ) (define (getgroups) (let ((result ((c-lambda () scheme-object "os_getgroups2")))) (if (fixnum? result) (##raise-os-exception #f result getgroups) result))) (pp (getgroups)) > On Jul 20, 2020, at 7:07 AM, Lassi Kortela wrote: > > Marc, thank you once again for the excellent explanation. You have a knack for explaining complex topics clearly. We should start collecting and editing this stuff into the Gambit manual proper. > > Here's a Unix getgroups() wrapper that allocates increasing powers of two until the result fits. We should finish up SRFI 170 (POSIX APIs) with Harold; since the Unix syscall interface is designed such that the kernel copies data into statically-sized userland buffers, many syscalls are best wrapped by trying powers of two. > > The below code raises more potential problems: > > - I'm still not confident that I understand when and how to release objects. In the code below, __release_scmobj is used to wrap up accessing ___BODY; is this right? > > - getgroups() returns a gid_t array but POSIX doesn't say how many bits wide gid_t is. (In fact, it doesn't even say whether it's a signed or unsigned type.) This is the case for many/most C datatypes. An API like ___alloc_sint_vector(NULL, count, sizeof(gid_t)) would help with this. > > - getgroups() can return fewer entries than we allocated buffer space for. Does Gambit have a way of truncating vectors? In general, there is no way to know ahead of time the exact size needed for result buffers: some syscalls accept a NULL buffer to not copy any data and only return the right buffer size, but relying on that size can lead to race conditions between that call and the next call that supplies a non-NULL buffer to actually copy the data. > > Clojure transients might be a good model for Scheme FFI in situations like this. Clojure is mostly an immutable language, but a transient is a mutable collection that is "sealed" into an immutable one once it has been filled; transients were added for performance reasons. While Scheme strings and vectors are mutable, their size cannot change (at least not by RnRS means) so in that respect they are immutable. > > Perhaps Gambit's object header can be hacked from C code to mutate a vector to have fewer actual elements than space is allocated for. Is such a thing safe to do, and would it be workable to have an official way in the FFI to truncate a vector? > > ---------------------------------------------------------------------- > > (c-declare "#include ") > > (define getgroups > (c-lambda () scheme-object #< for (int cap = 2; cap <= 256; cap *= 2) { > size_t nbytes = cap * sizeof(___S32); > ___SCMOBJ vector = ___EXT(___alloc_scmobj)(NULL, ___sS32VECTOR, nbytes); > if (___FIXNUMP(vector)) ___return(___FAL); > ___S32 *gids = ___CAST(___S32 *, ___BODY(vector)); > int len = getgroups(cap, gids); > ___EXT(___release_scmobj)(vector); > if (len >= 0) ___return(vector); > } > ___return(___FAL); > c-end > )) > > (define (writeln x) (write x) (newline)) > > (let ((gs (getgroups))) > (writeln gs) > (writeln (s32vector-length gs))) > > _______________________________________________ > Gambit-list mailing list > Gambit-list at iro.umontreal.ca > https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list > From feeley at iro.umontreal.ca Mon Jul 20 12:41:32 2020 From: feeley at iro.umontreal.ca (Marc Feeley) Date: Mon, 20 Jul 2020 12:41:32 -0400 Subject: [gambit-list] Allocate Scheme vector before or after C call? In-Reply-To: <1C85E104-5B31-4194-BAE7-45D59706ACF6@iro.umontreal.ca> References: <76df14c0-3e81-9616-9ca6-fbf6ab76c94c@lassi.io> <1771316B-8E0C-4111-A8DB-555CD1B5AA65@iro.umontreal.ca> <5cf22e4f-ebe3-87bb-573b-f55c39570165@lassi.io> <1C85E104-5B31-4194-BAE7-45D59706ACF6@iro.umontreal.ca> Message-ID: <7771AC6F-C6B7-4F51-9574-CE5B071DF685@iro.umontreal.ca> > On Jul 20, 2020, at 11:59 AM, Marc Feeley wrote: > > } else { > if (buf != buffer) free(buf); > return ___FIX(___ERRNO_ERR(errno)); > } Small bug here? need to call ___ERRNO_ERR(errno) before the call to free in case free modifies errno? The error handling could also be improved to do the ?if (buf != buffer) free(buf);? in fewer places. Marc From Joerg.Wittenberger at softeyes.net Tue Jul 21 15:48:15 2020 From: Joerg.Wittenberger at softeyes.net (=?UTF-8?B?SsO2cmc=?= F. Wittenberger) Date: Tue, 21 Jul 2020 21:48:15 +0200 Subject: [gambit-list] could we have a minor release In-Reply-To: <20200719190822.01ea8173@devuan> References: <20200719190822.01ea8173@devuan> Message-ID: <20200721214815.0e5dfed2@devuan> Hi, long story short: as the subject says: I'd appreciate if there could be a minor release to gambit. Why: a) eventually I need a solution (see long story below) using lambdanative b) no way to build lambdanative from gambit-4.9.3 because of issue #384 c) #384 was closed between August 9th and December 12th 2019 d) the solution may either need changes to `lib/os_io.c` depend on internals of it and that file has changed considerably between 0.9.2 and current master. It would be a waste of time to work out an interim solution. Hence I'd love to see a 4.9.4 no matter how close this is to a 5.0 supporting all the recent additions officially. Thanks soo much J?rg Long story: after diving deeper into gambit source I'm under the impression that there is no easy way to solve the question I asked the other day under the subject "How to use ports created from an open file descriptor". By now I believe to see how this could be done. Eventually I'd like to do this in the context of a lambdanative-built application. But I understand and support the policy of lambdanative to require permanent URLs to download sources and pass a hash test. Am Sun, 19 Jul 2020 19:08:22 +0200 schrieb "J?rg F. Wittenberger" : > Hi, > > once I learned that ##open-predefined could be used to create a port > from an already opened file descriptor (in addition to the standard > streams). This did work for me as long as I used just one FD that way > and used it until the programm terminated. > > However now I need to actually close the port and want the FD being > closed too. However in os_io.c around line 9932ff I found: > > * ........... The responsibility for closing the stream is not > * transferred to the runtime system because ... > > I obviously need the other way around. How would I transfer the > ownership of an FD to the runtime system? > > (A second, related issue I'm looking into is that ##open-predefined > will add an exit job for each writable FD. This too is not desirable > in my case. However cut&paste of ##open-predefined and modification > looks easy enough to get rid of the latter. What I wonder is how I > would have (ab)use the C code side with preferrable non to minimal > modifications.) > > Best > > J?rg > > > _______________________________________________ > Gambit-list mailing list > Gambit-list at iro.umontreal.ca > https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list From lassi at lassi.io Wed Jul 29 08:36:39 2020 From: lassi at lassi.io (Lassi Kortela) Date: Wed, 29 Jul 2020 15:36:39 +0300 Subject: [gambit-list] Allocate Scheme vector before or after C call? In-Reply-To: <1C85E104-5B31-4194-BAE7-45D59706ACF6@iro.umontreal.ca> References: <76df14c0-3e81-9616-9ca6-fbf6ab76c94c@lassi.io> <1771316B-8E0C-4111-A8DB-555CD1B5AA65@iro.umontreal.ca> <5cf22e4f-ebe3-87bb-573b-f55c39570165@lassi.io> <1C85E104-5B31-4194-BAE7-45D59706ACF6@iro.umontreal.ca> Message-ID: <36c5b8e8-8691-1af0-8e00-c096ccdf8184@lassi.io> Getting back to this; sorry about the delay. Thanks for taking the time to write the detailed code examples. vector-shrink! and string-shrink! are also useful. I've explored the FFI some more. There are lots of C APIs that return a vector of some datatype that would be useful to bring over to Scheme. All of the following are useful: - collect N-bit integers into a buffer in C, possibly truncate, turn into a Scheme homogeneous numeric vector - collect N-bit integers into a buffer in C, possibly truncate, turn into a generic Scheme vector (i.e. the elements are converted from C integers into Scheme fixnums, some might become bignums instead) - collect char* string into a buffer in C, possibly truncate, turn into a Scheme string - collect WCHAR string into a buffer in C, possibly truncate, turn into a Scheme string When collecting C integers to be turned into fixnums later, would it make sense to pre-allocate a Scheme vector with space in its body for (* capacity (max size-of-that-c-integer-type size-of-a-scheme-value)) bytes? Then fill the buffer and do an in-place conversion from C integers to fixnums. If this works, we wouldn't have to allocate a separate vector for the fixnums. From Joerg.Wittenberger at softeyes.net Wed Jul 29 09:20:11 2020 From: Joerg.Wittenberger at softeyes.net (=?UTF-8?B?SsO2cmc=?= F. Wittenberger) Date: Wed, 29 Jul 2020 15:20:11 +0200 Subject: [gambit-list] build problems with current master Message-ID: <20200729152011.6f1e49e3@devuan> Hello, me trying to compile the current github master branch of gambit using the gambit 0.9.3 release fails. In order to do so I linked the gsc from the release into the checkout as gsc-boot and tried both "make from-scratch" and "make". First issue was easy to work around: in gambit.h.in ___USE_C_RTS_CHAR_OPERATIONS is never defined and used to conditionally compile ___CHARALPHABETICP and friends. I simply added a #define for it, though I wonder: how would you build the master at all? No good chance for me to work around the second issue: Compiling _num.scm fails with: ***ERROR IN c#macro-expand -- define-prim can't inline ##bignum.adigit-bitwise-andc1! How could I get around? Thanks J?rg