You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2008 |
Jan
(33) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(20) |
Jul
|
Aug
(4) |
Sep
(10) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
(4) |
May
(4) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
2013 |
Jan
|
Feb
|
Mar
(5) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2014 |
Jan
(19) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(18) |
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Andy K. <and...@gm...> - 2022-03-21 03:57:34
|
The 2022 Scheme and Functional Programming Workshop is calling for submissions. We invite high-quality papers and talk proposals about novel research results, lessons learned from practical experience in an industrial or educational setting, and even new insights on old ideas. We welcome and encourage submissions that apply to any dynamic functional language, especially those that can be considered a 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 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 Dates Submission deadline is 2022-07-22. Authors will be notified by 2022-08-15. Camera-ready versions are due 2022-09-02. Workshop will be held in Ljubljana, Slovenia on 2022-09-16. All deadlines are 23:59 UTC-12, anywhere on Earth. Submission Information We 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. Authors of each accepted submission are invited to attend and be available for the presentation of that paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. 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 uploaded to arXiv.org <https://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. Please submit papers through the workshop's HotCRP site <https://scheme2022.hotcrp.com/>. Lightweight double-blind reviewing Scheme 2022 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 judgment 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. We recommend using 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. LaTeX and Microsoft Word templates for this format are available through SIGPLAN <https://www.sigplan.org/Resources/Author/>. Lightning talks can be submitted as either a text file or a PDF file. International Conference on Functional Programming The Scheme Workshop 2022 is being held as part of this year's International Conference on Functional Programming. Here is the ICFP site <https://icfp22.sigplan.org/home/scheme-2022> for the workshop. Sincerely, Andy Keep, General Co-chair Arthur A. Gleckler, General Co-chair |
From: Aydar Z. <ayd...@gm...> - 2020-05-31 20:16:51
|
Oh, I made such a stupid mistake. *Thank you for replying*. вт, 26 мая 2020 г., 18:39 Kevin Cozens <ke...@ve...>: > On 2020-03-28 9:14 a.m., Aydar Zarifullin wrote: > > Hello everyone. I played a little with tinyscheme and wrote a simple > code > > https://github.com/iZarif/ts-bug/blob/master/qscm.c > > When running a binary compiled from this code a segmentation fault > occurs. > > The second argument to scheme_load_named_file() is expected to be an open > file pointer (created by fopen) for the file you want to load. > > I'll make a note that the load functions should check for a NULL pointer > and > report on it instead of a program tossing a seg fault some time later. > > -- > Cheers! > > Kevin. > > http://www.ve3syb.ca/ | "Nerds make the shiny things that > https://www.patreon.com/KevinCozens | distract the mouth-breathers, and > | that's why we're powerful" > Owner of Elecraft K2 #2172 | > #include <disclaimer/favourite> | --Chris Hardwick > > > _______________________________________________ > Tinyscheme-issues mailing list > Tin...@li... > https://lists.sourceforge.net/lists/listinfo/tinyscheme-issues > |
From: Kevin C. <ke...@ve...> - 2020-05-26 14:39:53
|
On 2020-03-28 9:14 a.m., Aydar Zarifullin wrote: > Hello everyone. I played a little with tinyscheme and wrote a simple code > https://github.com/iZarif/ts-bug/blob/master/qscm.c > When running a binary compiled from this code a segmentation fault occurs. The second argument to scheme_load_named_file() is expected to be an open file pointer (created by fopen) for the file you want to load. I'll make a note that the load functions should check for a NULL pointer and report on it instead of a program tossing a seg fault some time later. -- Cheers! Kevin. http://www.ve3syb.ca/ | "Nerds make the shiny things that https://www.patreon.com/KevinCozens | distract the mouth-breathers, and | that's why we're powerful" Owner of Elecraft K2 #2172 | #include <disclaimer/favourite> | --Chris Hardwick |
From: Jason H. <jas...@gm...> - 2020-05-17 18:14:55
|
Hello, Thank you for your attention, and my apologies for any duplication you receive. Please find below the Call for Papers for the *2020 Scheme and Functional Programming Workshop*. The deadline has been extended to *May 31*. Please also note that the workshop is now to be held *virtual*ly; hopefully the silver lining is more and wider participation. We look forward to your submissions. *Call for Papers*The 2020 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 31 May 2020. Authors will be notified by 12 June 2020. Camera-ready versions are due 30 June 2020. All deadlines are (23:59 UTC-12), “Anywhere on Earth”. Submission Information Paper submissions must use the format acmart and its sub-format acmlarge. 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/ <https://jason-hemann-dot-yamm-track.appspot.com/Redirect?ukey=1hySDOusaj9Sw1-Dfr_V_rW6365QnkXJwLSigmgTSWPE-0&key=YAMMID-39286667&link=http%3A%2F%2Fwww.sigplan.org%2FResources%2FAuthor%2F> 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 limited to 14 pages, but we encourage submitting smaller papers. Lightning talks are limited to 192 words. Each accepted paper and report will be presented by its authors in a 25 minute slot including Q&A. Each accepted lightning talk will be presented by its authors in a 5 minute slot, followed by 5 minutes of Q&A. 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 printed as a Technical Report at the University of Michigan and uploaded to arXiv.org <https://jason-hemann-dot-yamm-track.appspot.com/Redirect?ukey=1hySDOusaj9Sw1-Dfr_V_rW6365QnkXJwLSigmgTSWPE-0&key=YAMMID-39286667&link=http%3A%2F%2Farxiv.org%2F> . 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. Sincerely, Jason Hemann, Northeastern University *Organizing Committee*Michael D. Adams (Program Co-Chair), University of Michigan Baptiste Saleil (Program Co-Chair), IBM Canada Jason Hemann (Publicity Chair), Northeastern University *Program Committee*Michael D. Adams (Program Co-Chair), University of Michigan Baptiste Saleil (Program Co-Chair), IBM Canada Maxime Chevalier-Boisvert, Université de Montréal Ryan Culpepper, Czech Technical University Kimball Germane, University of Utah Yukiyoshi Kameyama, University of Tsukuba Andy Keep, Cisco Systems, Inc Julien Pagès, Université de Montréal Alexey Radul *Steering Committee*Will Byrd, University of Alabama at Birmingham Will Clinger, The Larceny Project Marc Feeley, Université de Montréal Dan Friedman, Indiana University Olin Shivers, Northeastern University [image: beacon] |
From: Jason H. <jh...@no...> - 2020-03-30 23:02:55
|
Hello, Thank you for your attention, and my apologies for any duplication you receive. Please find below the Call for Papers for the *2020 Scheme and Functional Programming Workshop*. We look forward to your submissions. *Call for Papers*The 2020 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 15 May 2020. Authors will be notified by 12 June 2020. Camera-ready versions are due 30 June 2020. All deadlines are (23:59 UTC-12), “Anywhere on Earth”. Submission Information Paper submissions must use the format acmart and its sub-format acmlarge. 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/ <https://jason-hemann-dot-yamm-track.appspot.com/Redirect?ukey=1hySDOusaj9Sw1-Dfr_V_rW6365QnkXJwLSigmgTSWPE-0&key=YAMMID-03759584&link=http%3A%2F%2Fwww.sigplan.org%2FResources%2FAuthor%2F> 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 limited to 14 pages, but we encourage submitting smaller papers. Lightning talks are limited to 192 words. Each accepted paper and report will be presented by its authors in a 25 minute slot including Q&A. Each accepted lightning talk will be presented by its authors in a 5 minute slot, followed by 5 minutes of Q&A. 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 printed as a Technical Report at the University of Michigan and uploaded to arXiv.org <https://jason-hemann-dot-yamm-track.appspot.com/Redirect?ukey=1hySDOusaj9Sw1-Dfr_V_rW6365QnkXJwLSigmgTSWPE-0&key=YAMMID-03759584&link=http%3A%2F%2FarXiv.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. Sincerely, Jason Hemann, Northeastern University *Organizing Committee* Michael D. Adams (Program Co-Chair), University of Michigan Baptiste Saleil (Program Co-Chair), IBM Canada Jason Hemann (Publicity Chair), Northeastern University *Program Committee*Michael D. Adams (Program Co-Chair), University of Michigan Baptiste Saleil (Program Co-Chair), IBM Canada Maxime Chevalier-Boisvert, Université de Montréal Ryan Culpepper, Czech Technical University Kimball Germane, University of Utah Yukiyoshi Kameyama, University of Tsukuba Andy Keep, Cisco Systems, Inc Julien Pagès, Université de Montréal Alexey Radul *Steering Committee*Will Byrd, University of Alabama at Birmingham Will Clinger, The Larceny Project Marc Feeley, Université de Montréal Dan Friedman, Indiana University Olin Shivers, Northeastern University [image: beacon] |
From: Aydar Z. <ayd...@gm...> - 2020-03-28 13:15:33
|
Hello everyone. I played a little with tinyscheme and wrote a simple code https://github.com/iZarif/ts-bug/blob/master/qscm.c When running a binary compiled from this code a segmentation fault occurs. My environment: OS: Void Linux x86_64 MUSL edition Compiler: GCC 9.3.0 Tinyscheme version: revision 110 |
From: Sanel Z. <sa...@gm...> - 2016-06-20 14:31:55
|
Hi, Justus Winter <ju...@gn...> writes: > Hi, > > the GnuPG project is now using TinySCHEME-based tests replacing the old > Bourne-shell-based ones. The reason for this is portability. GnuPG > runs on a wide variety of platforms, including some non-POSIX ones, like > Windows, which lack a Bourne-compatible shell. Furthermore, writing > portable Bourne scripts has proven to be problematic as well. Cool!! > Sadly, our code has already diverged despite my best efforts to bring > the patches upstream prior to us merging it into our master branch. I > fear that this will only get worse over time. How hard would be to populate patches section on sf.net site? I jump there from time to time to pick up interesting patches, integrating them in my own projects; I presume other does that too. Also, this is a nice chance to call maintainers to consider better tooling - github/gitlab/whatever so at least we can have visible patches/PR section; not saying that submitting or applying them will be much easier. > Justus Best, Sanel |
From: Justus W. <ju...@gn...> - 2016-06-20 12:14:21
|
Hi, the GnuPG project is now using TinySCHEME-based tests replacing the old Bourne-shell-based ones. The reason for this is portability. GnuPG runs on a wide variety of platforms, including some non-POSIX ones, like Windows, which lack a Bourne-compatible shell. Furthermore, writing portable Bourne scripts has proven to be problematic as well. Sadly, our code has already diverged despite my best efforts to bring the patches upstream prior to us merging it into our master branch. I fear that this will only get worse over time. Justus |
From: Justus W. <ju...@g1...> - 2016-03-14 16:37:11
|
Hello, it has been a month now since I posted patches, and several of them have neither received any criticism nor have been merged. I'd love to know what's up. Context: I have written a TinySCHEME based test framework for GnuPG, and before merging it I wanted to get in contact with you and bring the number of patches we apply on top of TinySCHEME down. At the same time I wanted to evaluate how susceptible the TinySCHEME project is to contributions, because any code we merge has a maintenance cost, even more so if we have a stack of patches on top of the upstream code. I'm a little lost, not sure how to proceed and what to make of it. Cheers, Justus |
From: Justus W. <ju...@g1...> - 2016-02-29 13:27:13
|
Quoting Justus Winter (2016-02-04 16:49:17) > * scheme.c (vtbl): Add 'port_from_file' to the vtable. > * scheme.h (struct scheme_interface): New field 'mk_port_from_file'. This patch makes it possible to create scheme ports for streams, e.g. to allow one to print to stderr. Thanks, Justus |
From: Justus W. <ju...@g1...> - 2016-02-29 13:25:14
|
Quoting Justus Winter (2016-02-04 16:49:16) > * scheme.c (opexe_0): Include the value that we tried to evaluate as > function-like in the error message. Without this patch, the error message TinySCHEME prints when one calles something non-callable is not very helpful: % ./scheme <<< '(1)' TinyScheme 1.41 ts> Error: illegal function ts> #<EOF> Locating the error in a non-trivial piece of code is impossible. So short of displaying the location of the error I believe TinySCHEME should at least print out what the user tried to evaluate. Thanks for considering, Justus |
From: Justus W. <ju...@g1...> - 2016-02-29 13:20:38
|
Quoting Justus Winter (2016-02-04 16:49:13) > * init.scm (*error-hook*): Fix error hook so that the whole error > message is displayed. Without this patch, if you do define USE_ERROR_HOOK, only the first elements of the error messages are displayed: % grep USE_ERROR_HOOK ../tests/gpgscm/scheme-config.h #define USE_ERROR_HOOK 0 % tests/gpgscm/gpgscm <<< foo gpgscm/TinyScheme 1.41. gpgscm > foo built-in Error: eval: unbound variable: foo (note that I patched scheme.c so that we can distinguish how the error message is printed.) % grep USE_ERROR_HOOK ../tests/gpgscm/scheme-config.h #define USE_ERROR_HOOK 1 % tests/gpgscm/gpgscm <<< foo gpgscm/TinyScheme 1.41. gpgscm > foo Error: eval: unbound variable: gpgscm > I have trouble making the standalone version of TinySCHEME use the error hook, I don't know why: % head -n1 SConstruct DEFINES='' % ./scheme <<< foo TinyScheme 1.41 ts> built-in Error: eval: unbound variable: foo ts> #<EOF> vs. % head -n1 SConstruct DEFINES='-DUSE_ERROR_HOOK=1' % ./scheme <<< foo TinyScheme 1.41 ts> built-in Error: eval: unbound variable: foo ts> #<EOF> Thanks for considering, Justus |
From: Justus W. <ju...@g1...> - 2016-02-29 12:35:25
|
Quoting Justus Winter (2016-02-04 16:49:12) > * scheme.c (opexe_{3,4}): Handle unhandled enumeration values in the > opcode dispatching code. This commit fixes 625 instances of the following warning: .../scheme.c:3726:6: warning: enumeration value ‘OP_MAXDEFINE’ not handled in switch [-Wswitch] Justus |
From: Kevin C. <ke...@ve...> - 2016-02-25 17:32:40
|
On 16-02-04 10:49 AM, Justus Winter wrote: > * scheme-private.h: Make various limits configurable. Change applied to SVN. It is in revision 109. -- Cheers! Kevin. http://www.ve3syb.ca/ |"Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful!" #include <disclaimer/favourite> | --Chris Hardwick |
From: Justus W. <ju...@g1...> - 2016-02-22 14:54:51
|
Quoting Kevin Cozens (2016-02-10 22:13:32) > On 16-02-08 04:55 AM, Justus Winter wrote: > > Quoting Kevin Cozens (2016-02-05 18:25:14) > >> I didn't notice a macro called package mentioned in either the R5RS or R6RS. > >> Which manual has the package macro and what is its purpose? > > > > Sorry if that wasn't clear. The TinySCHEME manual, and it is an > > implementation of object oriented programming for Scheme as described > > here: http://tinyscheme.sourceforge.net/oo.txt > > > > The other half of it (the colon hook) was already present in init.scm. > > Adding OOP features for TinyScheme has been mentioned but it isn't something > I have any interest in at this time. If someone else thinks it is worth > adding the package macro they can do add it. I still like to see this added for two reasons. 1/ the TinySCHEME website and the TinySCHEME manual both give the impression that this feature is supported by TinySCHEME out of the box. 2/ init.scm contains half of the functionality and refers to the other half in a comment. Manual.txt says: (current-environment) The environment in effect at the time of the call. An example of its use and its utility can be found in the sample code that implements packages in "init.scm": [... here follows the definition of 'package' that I propose to (re-)add ...] [...] Colon Qualifiers - Packages --------------------------- [...] "Init.scm" defines a new syntantic form, PACKAGE, as a simple example. It is used like this: And init.scm says: ; Redefine this if you install another package infrastructure ; Also redefine 'package' (define *colon-hook* eval) And what about my other patches? Cheers, Justus |
From: Kevin C. <ke...@ve...> - 2016-02-10 21:13:45
|
On 16-02-08 04:55 AM, Justus Winter wrote: > Quoting Kevin Cozens (2016-02-05 18:25:14) >> I didn't notice a macro called package mentioned in either the R5RS or R6RS. >> Which manual has the package macro and what is its purpose? > > Sorry if that wasn't clear. The TinySCHEME manual, and it is an > implementation of object oriented programming for Scheme as described > here: http://tinyscheme.sourceforge.net/oo.txt > > The other half of it (the colon hook) was already present in init.scm. Adding OOP features for TinyScheme has been mentioned but it isn't something I have any interest in at this time. If someone else thinks it is worth adding the package macro they can do add it. -- Cheers! Kevin. http://www.ve3syb.ca/ |"Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful!" #include <disclaimer/favourite> | --Chris Hardwick |
From: Justus W. <ju...@g1...> - 2016-02-08 09:55:25
|
Quoting Kevin Cozens (2016-02-05 18:25:14) > On 16-02-04 10:49 AM, Justus Winter wrote: > > * init.scm: Add package macro from manual. > > I didn't notice a macro called package mentioned in either the R5RS or R6RS. > Which manual has the package macro and what is its purpose? Sorry if that wasn't clear. The TinySCHEME manual, and it is an implementation of object oriented programming for Scheme as described here: http://tinyscheme.sourceforge.net/oo.txt The other half of it (the colon hook) was already present in init.scm. Justus |
From: Justus W. <ju...@g1...> - 2016-02-08 09:50:46
|
Hi Kevin :) Quoting Kevin Cozens (2016-02-05 18:16:06) > On 16-02-04 10:49 AM, Justus Winter wrote: > > * scheme.h (scheme_init_new): Fix prototype. > > Thanks for spotting this. Fixed in SVN revision 108. Cool. > BTW, patches should be provided as attachments to issue reports in > Sourceforge instead of included in the body of an email message. I get a lot > of email every day so patches in email messages could get lost. Well, I've looked at the patch tracker and decided I'd rather take my chances with the mailing list. That, and 'git send-email' works nicely with mailing lists, and not so much with web sites. Justus |
From: Kevin C. <ke...@ve...> - 2016-02-05 19:07:19
|
On 16-02-04 10:49 AM, Justus Winter wrote: > * init.scm: Add package macro from manual. I didn't notice a macro called package mentioned in either the R5RS or R6RS. Which manual has the package macro and what is its purpose? -- Cheers! Kevin. http://www.ve3syb.ca/ |"Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful!" #include <disclaimer/favourite> | --Chris Hardwick |
From: Kevin C. <ke...@ve...> - 2016-02-05 17:29:37
|
On 16-02-04 10:49 AM, Justus Winter wrote: > * scheme.h (scheme_init_new): Fix prototype. Thanks for spotting this. Fixed in SVN revision 108. BTW, patches should be provided as attachments to issue reports in Sourceforge instead of included in the body of an email message. I get a lot of email every day so patches in email messages could get lost. -- Cheers! Kevin. http://www.ve3syb.ca/ |"Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful!" #include <disclaimer/favourite> | --Chris Hardwick |
From: Justus W. <ju...@g1...> - 2016-02-04 15:49:57
|
* init.scm: Add package macro from manual. Signed-off-by: Justus Winter <ju...@g1...> --- init.scm | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/init.scm b/init.scm index 3c0ee7d..630f27a 100644 --- a/init.scm +++ b/init.scm @@ -600,6 +600,11 @@ ; Also redefine 'package' (define *colon-hook* eval) +(macro (package form) + `(apply (lambda () + ,@(cdr form) + (current-environment)))) + ;;;;; I/O (define (input-output-port? p) -- 2.1.4 |
From: Justus W. <ju...@g1...> - 2016-02-04 15:49:56
|
* scheme.c (opexe_{3,4}): Handle unhandled enumeration values in the opcode dispatching code. Signed-off-by: Justus Winter <ju...@g1...> --- scheme.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/scheme.c b/scheme.c index 06ac585..d6396a6 100644 --- a/scheme.c +++ b/scheme.c @@ -27,6 +27,7 @@ # include <math.h> #endif +#include <assert.h> #include <limits.h> #include <float.h> #include <ctype.h> @@ -3650,6 +3651,7 @@ static pointer opexe_3(scheme *sc, enum scheme_opcodes op) { case OP_GRE: comp_func=num_gt; break; case OP_LEQ: comp_func=num_le; break; case OP_GEQ: comp_func=num_ge; break; + default: assert (! "reached"); } x=sc->args; v=nvalue(car(x)); @@ -3894,12 +3896,15 @@ static pointer opexe_4(scheme *sc, enum scheme_opcodes op) { case OP_OPEN_INFILE: prop=port_input; break; case OP_OPEN_OUTFILE: prop=port_output; break; case OP_OPEN_INOUTFILE: prop=port_input|port_output; break; + default: assert (! "reached"); } p=port_from_filename(sc,strvalue(car(sc->args)),prop); if(p==sc->NIL) { s_return(sc,sc->F); } s_return(sc,p); + break; + default: assert (! "reached"); } #if USE_STRING_PORTS @@ -3910,6 +3915,7 @@ static pointer opexe_4(scheme *sc, enum scheme_opcodes op) { switch(op) { case OP_OPEN_INSTRING: prop=port_input; break; case OP_OPEN_INOUTSTRING: prop=port_input|port_output; break; + default: assert (! "reached"); } p=port_from_string(sc, strvalue(car(sc->args)), strvalue(car(sc->args))+strlength(car(sc->args)), prop); -- 2.1.4 |
From: Justus W. <ju...@g1...> - 2016-02-04 15:49:54
|
* scheme.h (scheme_init_new): Fix prototype. Signed-off-by: Justus Winter <ju...@g1...> --- scheme.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scheme.h b/scheme.h index fbc542b..05ae7fe 100644 --- a/scheme.h +++ b/scheme.h @@ -127,7 +127,7 @@ typedef struct num { } value; } num; -SCHEME_EXPORT scheme *scheme_init_new(); +SCHEME_EXPORT scheme *scheme_init_new(void); SCHEME_EXPORT scheme *scheme_init_new_custom_alloc(func_alloc malloc, func_dealloc free); SCHEME_EXPORT int scheme_init(scheme *sc); SCHEME_EXPORT int scheme_init_custom_alloc(scheme *sc, func_alloc, func_dealloc); -- 2.1.4 |
From: Justus W. <ju...@g1...> - 2016-02-04 15:49:53
|
* scheme.c (opexe_0): Include the value that we tried to evaluate as function-like in the error message. Signed-off-by: Justus Winter <ju...@g1...> --- scheme.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scheme.c b/scheme.c index d6396a6..2cd1774 100644 --- a/scheme.c +++ b/scheme.c @@ -2679,7 +2679,7 @@ static pointer opexe_0(scheme *sc, enum scheme_opcodes op) { sc->dump = cont_dump(sc->code); s_return(sc,sc->args != sc->NIL ? car(sc->args) : sc->NIL); } else { - Error_0(sc,"illegal function"); + Error_1(sc,"illegal function",sc->code); } case OP_DOMACRO: /* do macro */ -- 2.1.4 |
From: Justus W. <ju...@g1...> - 2016-02-04 15:49:53
|
* scheme.c (vtbl): Add 'port_from_file' to the vtable. * scheme.h (struct scheme_interface): New field 'mk_port_from_file'. Signed-off-by: Justus Winter <ju...@g1...> --- scheme.c | 3 ++- scheme.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/scheme.c b/scheme.c index 2cd1774..2c9fd02 100644 --- a/scheme.c +++ b/scheme.c @@ -4610,7 +4610,8 @@ static struct scheme_interface vtbl ={ setimmutable, scheme_load_file, - scheme_load_string + scheme_load_string, + port_from_file }; #endif diff --git a/scheme.h b/scheme.h index 05ae7fe..4ba2daa 100644 --- a/scheme.h +++ b/scheme.h @@ -224,6 +224,7 @@ struct scheme_interface { void (*setimmutable)(pointer p); void (*load_file)(scheme *sc, FILE *fin); void (*load_string)(scheme *sc, const char *input); + pointer (*mk_port_from_file)(scheme *sc, FILE *f, int kind); }; #endif -- 2.1.4 |