From sthilaire.david at gmail.com Wed Feb 1 17:48:26 2023 From: sthilaire.david at gmail.com (David St-Hilaire) Date: Wed, 1 Feb 2023 20:48:26 -0500 Subject: [CM] S7 integrated in TIC-80, and bug reports Message-ID: Hi! First I hope that I'm sending this to the right place! I'm working at integrating S7 into the tic-80 fantasy console (https://tic80.com/) I've been craving using scheme for these fun toys and decided to add support to this open source console. It's going very well and should be done soon! While I was texting my integration, I came across two issues that seems like S7 bugs: - if you can map inside a define-macro you get a 100% crash. Si e for instance (define-macro (test x . args) (list ,@(map car args))) (test 10 ('x 1) ('y 2)) ;; Seg fault - The second issue is the fact that macro expansion seems to happen after set! arguments are parsed. For example this works: (let ((x (cons 1 2))) (set! (car x) 3) x) ; (3 2) Yet this doesn't: (define-macro (test x) `(car ,x)) (let ((x (cons 1 2))) (set! (test x) 3) x) ; error I don't know if these are real issues or of that are known but I wanted to report them because they caused me some problems! I'm really at how easy it was to use and embed S7! It was really a breeze! Well done! ps: it seems that performance wise it runs a bit slowly though Cheers! -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Thu Feb 2 10:53:04 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 02 Feb 2023 10:53:04 -0800 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: References: Message-ID: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> Thanks for the info and bug reports. Are you catching scheme errors or using a repl? In the repl, I get: (define-macro (test x . args) (list ,@(map car args))) (test 10 ('x 1) ('y 2)) ;unquote (',') occurred outside quasiquote: (test 10 ('x 1) ('y 2)) ; (test 10 ('x 1) ('y 2)) ; test: (list (unquote (apply-values (map c... ; args: (('x 1) ('y 2)) In other words, you have ",@(...)" but there's no enclosing quasiquote. (define-macro (test x) `(car ,x)) (let ((x (cons 1 2))) (set! (test x) 3) x) ;test (a macro) does not have a setter: (set! (test x) 3) The code (set! (test...)...) only works if the test macro has a setter (a function that tells set! how to handle it as the target of set!). Your other case (let ((x (cons 1 2))) (set! (car x) 3) x) ;(3 . 2) works because car has a built-in setter in s7 (set-car! is the standard scheme equivalent). If you're using s7_eval_c_string or other C-side equivalent, you need to catch scheme-side errors. There's a section in s7.html showing one way to do this ("handling scheme errors in C" or some such title). From bil at ccrma.Stanford.EDU Thu Feb 2 12:01:45 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 02 Feb 2023 12:01:45 -0800 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> Message-ID: <0a7e9f5fc23fb03bf9205bba68b50a1a@ccrma.stanford.edu> On the first issue, it looks to me like you have your own map function -- scheme_map is not an s7 function. It is passing a null pointer to s7_integer. As s7.html explains (under "FFI notes"), the C-side functions do very little error checking. From bil at ccrma.Stanford.EDU Thu Feb 2 12:06:29 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 02 Feb 2023 12:06:29 -0800 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> Message-ID: I forgot to say that I get this from the repl: (define-macro (test x . args) `(list ,@(map car args))) (test 10 ('x 1) ('y 2)) '(x y) On the noreturn problem, I'm using this: #ifdef _MSC_VER #define noreturn _Noreturn /* deprecated in C23 */ ... which I got from somewhere online. I wonder what the correct code is. From bil at ccrma.Stanford.EDU Thu Feb 2 12:33:14 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 02 Feb 2023 12:33:14 -0800 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> Message-ID: <6f32dd6a837404a700ff197a20e1128e@ccrma.stanford.edu> I don't think standard scheme allows set! with a target that is a pair, or at least I can't find anything about it in r7rs.pdf. In s7, the target needs a setter. The jmp_bufs are needed to unwind the C stack if an error is raised. It might work to make longjmp a no-op -- the stack will grow as each error is hit, but s7 might keep chugging along until you get a stack overflow. Does Android have the other complex math functions? If so, I could add ifdefs along the lines of the existing FreeBSD cases to add those two functions in Android. From bil at ccrma.Stanford.EDU Thu Feb 2 12:53:47 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 02 Feb 2023 12:53:47 -0800 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> Message-ID: Defining noreturn to nothing is fine; in gcc it makes a measurable difference in speed, but it's just a minor optimization. I can't find a compiler feature macro to tell me I'm running C23. From bil at ccrma.Stanford.EDU Fri Feb 3 05:32:02 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 03 Feb 2023 05:32:02 -0800 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> Message-ID: <853cdf44d955f7b509d958e8f3c59be9@ccrma.stanford.edu> Do you need to disallow reading a file? If it's just creating or altering a file that needs to be blocked, you could redirect fopen and fwrite (in s7.c) to functions that raise an error. I don't think s7 uses creat, open (except with O_RDONLY), or write. Also build it with WITH_C_LOADER=0 (to disallow dynamic loading of C object code), and maybe WITH_SYSTEM_EXTRAS=0. Hmmm... as I type this, this seems interesting -- maybe I'll tackle it later today. It might be equally easy to disallow reading a file -- fread etc. Oh, and for fopen, check the mode doesn't have "w" or "x" or whatever else might change a file. I'm probably forgetting something obvious. (There's also the sandbox procedure in stuff.scm, but it's been years since I looked at it). From bil at ccrma.Stanford.EDU Fri Feb 3 06:40:51 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 03 Feb 2023 06:40:51 -0800 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> <853cdf44d955f7b509d958e8f3c59be9@ccrma.stanford.edu> Message-ID: <2bb6118a96c2b7743b86a28205535c72@ccrma.stanford.edu> Here's a first stab at it -- put this code at line 1430 or thereabouts in s7.c (after the error_nr forward declaration), then build s7 with -DDISABLE_FILE_OUTPUT=1: #ifndef DISABLE_FILE_OUTPUT #define DISABLE_FILE_OUTPUT 0 #endif #if DISABLE_FILE_OUTPUT static FILE *old_fopen(const char *pathname, const char *mode) {return(fopen(pathname, mode));} #define fwrite local_fwrite #define fopen local_fopen /* open only used for file_probe (O_RDONLY), creat and write not used */ static size_t local_fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream) { error_nr(cur_sc, cur_sc->io_error_symbol, cur_sc->nil); } static FILE *local_fopen(const char *pathname, const char *mode) { if ((mode[0] == 'w') || (mode[0] == 'a')) error_nr(cur_sc, cur_sc->io_error_symbol, cur_sc->nil); return(old_fopen(pathname, mode)); } #endif From sthilaire.david at gmail.com Thu Feb 2 11:36:11 2023 From: sthilaire.david at gmail.com (David St-Hilaire) Date: Thu, 2 Feb 2023 14:36:11 -0500 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> Message-ID: for the first issue, I apologize, I wrote the test example from my cell phone, and forgot the backquote, it should have been: (define-macro (test x . args) `(list ,@(map car args))) (test 10 ('x 1) ('y 2)) which crashes S7, when I load from c string this snippet. The bt from gdb looks like this: Thread 1 "tic80" received signal SIGSEGV, Segmentation fault. 0x00005555559bb97d in s7_integer (p=0x0) at /home/david/hacking/tic80-s7/TIC-80/vendor/s7/s7.c:13462 13462 if (is_t_integer(p)) return(integer(p)); (gdb) bt #0 0x00005555559bb97d in s7_integer (p=0x0) at /home/david/hacking/tic80-s7/TIC-80/vendor/s7/s7.c:13462 #1 0x00005555558e136b in scheme_map (sc=0x555556e456a0, args=0x55555761d9b8) at /home/david/hacking/tic80-s7/TIC-80/src/api/scheme.c:313 #2 0x0000555555b27873 in op_c_ss (sc=0x555556e456a0) at /home/david/hacking/tic80-s7/TIC-80/vendor/s7/s7.c:87854 #3 0x0000555555b340e1 in eval (sc=0x555556e456a0, first_op=420) at /home/david/hacking/tic80-s7/TIC-80/vendor/s7/s7.c:90383 #4 0x00005555559f8899 in s7_load_c_string_with_environment (sc=0x555556e456a0, content=0x7fffe69dde08 ";; title: game title\n;; author: game developer, email, etc.\n;; desc: short description\n;; site: website link\n;; license: MIT License (change this to your license of choice)\n;; version: 0.1\n;;"..., bytes=2524, e=0x5555570ae610) at /home/david/hacking/tic80-s7/TIC-80/vendor/s7/s7.c:30466 #5 0x00005555559f89fc in s7_load_c_string (sc=0x555556e456a0, content=0x7fffe69dde08 ";; title: game title\n;; author: game developer, email, etc.\n;; desc: short description\n;; site: website link\n;; license: MIT License (change this to your license of choice)\n;; version: 0.1\n;;"..., bytes=2524) at /home/david/hacking/tic80-s7/TIC-80/vendor/s7/s7.c:30482 #6 0x00005555558e3367 in initScheme For my issue 2, about having a set! only working in some circonstances, I was expecting the macro to be expanded (thus producing the "(car x)" code and since car handles the set! call properly I expected to work. Is this a deviation from the standard or that I have a misconception of how it should work? I tried it in gsi and it worked well, but guile even fails to eval "(set! (car x) 3)" so maybe it is to the implementation to decide how this works? In my endeavour to use S7 in tic-80, I faced a few roadblocks on some platforms (windows, rasberry pi and android, mostly). You can see the details here if you are interested: https://github.com/nesbox/TIC-80/pull/2113 Windows issues were related to the use of noreturn hints. I didn't know how to fix it properly so I just removed them for now and it seems fine. I had less obvious issues on Android which had issues with the cpow and clog macros being undefined. Finally on rasberry pi, the issue was related to the type sigjmp_buf being undefined, which I'm still trying to resolve. I don't know if those changes I'm doing are relevant to you but I thought I would let you know. Finally, I mentionned performance issues in my first email, but I was quite wrong. I optimized my code a bit and also did better measurements and it's actually running very smoothly ;p Apologies! Thanks! -- David On Thu, Feb 2, 2023 at 1:53 PM wrote: > Thanks for the info and bug reports. Are you catching > scheme errors or using a repl? In the repl, I get: > > > (define-macro (test x . args) (list ,@(map car args))) > (test 10 ('x 1) ('y 2)) > > ;unquote (',') occurred outside quasiquote: (test 10 ('x 1) ('y 2)) > ; (test 10 ('x 1) ('y 2)) > ; test: (list (unquote (apply-values (map c... ; args: (('x 1) ('y 2)) > > In other words, you have ",@(...)" but there's no enclosing > quasiquote. > > > (define-macro (test x) `(car ,x)) > (let ((x (cons 1 2))) (set! (test x) 3) x) > > ;test (a macro) does not have a setter: (set! (test x) 3) > > The code (set! (test...)...) only works if the test macro > has a setter (a function that tells set! how to handle it > as the target of set!). Your other case > > (let ((x (cons 1 2))) (set! (car x) 3) x) > ;(3 . 2) > > works because car has a built-in setter in s7 (set-car! is > the standard scheme equivalent). > > If you're using s7_eval_c_string or other C-side equivalent, > you need to catch scheme-side errors. There's a section in > s7.html showing one way to do this ("handling scheme errors > in C" or some such title). > > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sthilaire.david at gmail.com Thu Feb 2 12:06:27 2023 From: sthilaire.david at gmail.com (David St-Hilaire) Date: Thu, 2 Feb 2023 15:06:27 -0500 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: <0a7e9f5fc23fb03bf9205bba68b50a1a@ccrma.stanford.edu> References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> <0a7e9f5fc23fb03bf9205bba68b50a1a@ccrma.stanford.edu> Message-ID: /facepalm, I accidentally have shadowed map with an api ffi... Yes that would explain my issue! Thanks, I should have seen it coming! On Thu, Feb 2, 2023 at 3:01 PM wrote: > On the first issue, it looks to me like you have > your own map function -- scheme_map is not an s7 > function. It is passing a null pointer to s7_integer. > As s7.html explains (under "FFI notes"), the C-side > functions do very little error checking. > > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sthilaire.david at gmail.com Thu Feb 2 12:09:58 2023 From: sthilaire.david at gmail.com (David St-Hilaire) Date: Thu, 2 Feb 2023 15:09:58 -0500 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> Message-ID: About noreturn, it seems it didn't work anymore (probably because it is now using C23) so I locally defined it to nothing, but I don't know how to make it better. I'm a bit stuck with the rasberry pi baremetal compilation issues like this: /__w/TIC-80/TIC-80/vendor/s7/s7.c:375:25: error: unknown type name 'sigjmp_buf' 550 375 | #define Jmp_Buf sigjmp_buf 551 | ^~~~~~~~~~ It seems that I need to get these platforms to use the other set of "Jmp_Buf" and friends definitions but I don't know how to distinguish those platforms... Any suggestions? Thanks! On Thu, Feb 2, 2023 at 3:06 PM wrote: > I forgot to say that I get this from the repl: > > (define-macro (test x . args) `(list ,@(map car args))) > (test 10 ('x 1) ('y 2)) > '(x y) > > > On the noreturn problem, I'm using this: > > #ifdef _MSC_VER > #define noreturn _Noreturn /* deprecated in C23 */ > ... > > which I got from somewhere online. I wonder what the correct code is. > > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sthilaire.david at gmail.com Thu Feb 2 17:39:33 2023 From: sthilaire.david at gmail.com (David St-Hilaire) Date: Thu, 2 Feb 2023 20:39:33 -0500 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> Message-ID: Okay, I have quite the curveball now. My s7 integration was flagged as a serious security risk due to file I/O access. The TIC-80 allows people to download "carts" and so a downloaded game using scheme could start messing with the filesystem. Would there, by any chance, a simple way to disable all file I/O? I started to try to pry out anything that had to do with files but the concept seems woven so deeply in scheme that it did'nt seem achievable with my lack of experience. I'm hoping for a miracle here, but I just needed to ask before I throw my hopes and my integration in the thrash bin... Thanks! On Thu, Feb 2, 2023 at 3:53 PM wrote: > Defining noreturn to nothing is fine; in gcc it makes a > measurable difference in speed, but it's just a minor > optimization. I can't find a compiler feature macro > to tell me I'm running C23. > > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sthilaire.david at gmail.com Fri Feb 3 05:43:11 2023 From: sthilaire.david at gmail.com (David St-Hilaire) Date: Fri, 3 Feb 2023 08:43:11 -0500 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: <853cdf44d955f7b509d958e8f3c59be9@ccrma.stanford.edu> References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> <853cdf44d955f7b509d958e8f3c59be9@ccrma.stanford.edu> Message-ID: I think it's mostly writing to files that is dangerous but disabling reading would be important too, if not only for forbidding "breaking" the fantasy console barriers. I looked at doing some changes but I was really not sure how to do it properly. If you would be generous enough to do the needed changes, it would be really amazing! Thank you so much for your help! On Fri, Feb 3, 2023 at 8:32 AM wrote: > Do you need to disallow reading a file? If it's just > creating or altering a file that needs to be blocked, > you could redirect fopen and fwrite (in s7.c) to > functions that raise an error. I don't think s7 uses > creat, open (except with O_RDONLY), or write. Also > build it with WITH_C_LOADER=0 (to disallow dynamic > loading of C object code), and maybe WITH_SYSTEM_EXTRAS=0. > Hmmm... as I type this, this seems interesting -- > maybe I'll tackle it later today. It might be > equally easy to disallow reading a file -- fread etc. > Oh, and for fopen, check the mode doesn't have "w" or "x" > or whatever else might change a file. I'm probably > forgetting something obvious. > > (There's also the sandbox procedure in stuff.scm, but > it's been years since I looked at it). > > > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.gubinelli at gmail.com Fri Feb 3 10:22:51 2023 From: m.gubinelli at gmail.com (Massimiliano Gubinelli) Date: Fri, 3 Feb 2023 18:22:51 +0000 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> <853cdf44d955f7b509d958e8f3c59be9@ccrma.stanford.edu> Message-ID: <6AD6192D-11C4-4AFB-8287-F47FC1843763@gmail.com> What about implementing a fake filesystem instead of allowing s7 to access the real one? In this way it will be effectively sandboxed. This is the approach used by emscripten to have ports work in webasm. Max > On 3 Feb 2023, at 13:43, David St-Hilaire wrote: > > I think it's mostly writing to files that is dangerous but disabling reading would be important too, if not only for forbidding "breaking" the fantasy console barriers. I looked at doing some changes but I was really not sure how to do it properly. If you would be generous enough to do the needed changes, it would be really amazing! > > Thank you so much for your help! > > On Fri, Feb 3, 2023 at 8:32 AM > wrote: >> Do you need to disallow reading a file? If it's just >> creating or altering a file that needs to be blocked, >> you could redirect fopen and fwrite (in s7.c) to >> functions that raise an error. I don't think s7 uses >> creat, open (except with O_RDONLY), or write. Also >> build it with WITH_C_LOADER=0 (to disallow dynamic >> loading of C object code), and maybe WITH_SYSTEM_EXTRAS=0. >> Hmmm... as I type this, this seems interesting -- >> maybe I'll tackle it later today. It might be >> equally easy to disallow reading a file -- fread etc. >> Oh, and for fopen, check the mode doesn't have "w" or "x" >> or whatever else might change a file. I'm probably >> forgetting something obvious. >> >> (There's also the sandbox procedure in stuff.scm, but >> it's been years since I looked at it). >> >> > > > -- > David > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Fri Feb 3 10:56:21 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 03 Feb 2023 10:56:21 -0800 Subject: [CM] Fwd: Re: S7 integrated in TIC-80, and bug reports Message-ID: <488d31ca6c1883bc2697a7668b8b39e6@ccrma.stanford.edu> (sorry about the chaotic state of cmdist -- all my fault). -------- Original Message -------- Subject: Re: [CM] S7 integrated in TIC-80, and bug reports Date: 2023-02-03 10:10 From: David St-Hilaire To: bil at ccrma.Stanford.EDU Hi bil! I implemented your changes and it's working very well. I also took the liberty to shadow fread and fopen completely to kill any IO. Thanks for your help! The only issue is that the error given has nothing to the with the actual fact that the IO is forbidden. Would there be a way to give a better error message? On Fri, Feb 3, 2023 at 10:10 AM wrote: > and similarly at line 95227 (the cur_sc = sc; line). > I'll leave this code in for tomorrow's ccrma versions. -- David From sthilaire.david at gmail.com Fri Feb 3 10:42:58 2023 From: sthilaire.david at gmail.com (David St-Hilaire) Date: Fri, 3 Feb 2023 13:42:58 -0500 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: <6AD6192D-11C4-4AFB-8287-F47FC1843763@gmail.com> References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> <853cdf44d955f7b509d958e8f3c59be9@ccrma.stanford.edu> <6AD6192D-11C4-4AFB-8287-F47FC1843763@gmail.com> Message-ID: I think it would be a good idea in another context. I think that forbidding IO completely is better aligned with the intentional use of the TIC-80 which is meant to be a fantasy console. The scheme code runs directly on the fictionnal hardware (a bit like your assembly would run from a NES cartridge). There shouldn't be any persistent file systems / storage accessible to users using that premise. On Fri, Feb 3, 2023 at 1:23 PM Massimiliano Gubinelli wrote: > What about implementing a fake filesystem instead of allowing s7 to access > the real one? In this way it will be effectively sandboxed. This is the > approach used by emscripten to have ports work in webasm. > > Max > > > On 3 Feb 2023, at 13:43, David St-Hilaire > wrote: > > I think it's mostly writing to files that is dangerous but disabling > reading would be important too, if not only for forbidding "breaking" the > fantasy console barriers. I looked at doing some changes but I was really > not sure how to do it properly. If you would be generous enough to do > the needed changes, it would be really amazing! > > Thank you so much for your help! > > On Fri, Feb 3, 2023 at 8:32 AM wrote: > >> Do you need to disallow reading a file? If it's just >> creating or altering a file that needs to be blocked, >> you could redirect fopen and fwrite (in s7.c) to >> functions that raise an error. I don't think s7 uses >> creat, open (except with O_RDONLY), or write. Also >> build it with WITH_C_LOADER=0 (to disallow dynamic >> loading of C object code), and maybe WITH_SYSTEM_EXTRAS=0. >> Hmmm... as I type this, this seems interesting -- >> maybe I'll tackle it later today. It might be >> equally easy to disallow reading a file -- fread etc. >> Oh, and for fopen, check the mode doesn't have "w" or "x" >> or whatever else might change a file. I'm probably >> forgetting something obvious. >> >> (There's also the sandbox procedure in stuff.scm, but >> it's been years since I looked at it). >> >> >> > > -- > David > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > > > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Fri Feb 3 11:01:12 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 03 Feb 2023 11:01:12 -0800 Subject: [CM] Fwd: Re: S7 integrated in TIC-80, and bug reports Message-ID: -------- Original Message -------- Subject: Re: [CM] S7 integrated in TIC-80, and bug reports Date: 2023-02-03 10:52 From: bil at ccrma.stanford.edu To: David St-Hilaire > Would there be a way to give a better error message? The error message is the third argument to error_nr. One simple change might be to forward declare wrap_string and set_elist_1, static s7_pointer set_elist_1(s7_scheme *sc, s7_pointer x1); static s7_pointer wrap_string(s7_scheme *sc, const char *str, s7_int len); then static size_t local_fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream) { error_nr(cur_sc, cur_sc->io_error_symbol, set_elist_1(cur_sc, wrap_string(cur_sc, "writing a file is not allowed in this version of s7", 51))); } and similarly for local_fopen. The integer (51 above) is the length of the error message string. From sthilaire.david at gmail.com Sun Feb 5 11:01:52 2023 From: sthilaire.david at gmail.com (David St-Hilaire) Date: Sun, 5 Feb 2023 14:01:52 -0500 Subject: [CM] S7 integrated in TIC-80, and bug reports In-Reply-To: <4b64c6a8edf183358af020aa700ce513@ccrma.stanford.edu> References: <57632241a054e615320f141eac19f437@ccrma.stanford.edu> <853cdf44d955f7b509d958e8f3c59be9@ccrma.stanford.edu> <73b2ba79cd321916d0cf004c2e9e090d@ccrma.stanford.edu> <4b64c6a8edf183358af020aa700ce513@ccrma.stanford.edu> Message-ID: I have good news! The S7 integration I've been working on has been accepted and pulled into the main branch of the TIC-80 and is flagged to be integrated in the next version release (version 1.1). I have no idea when this will be actually released but... we made it! Thanks for your support, it was really appreciated! I'm attaching the diff from s7.c that I got from your tarball with the one that got integrated, in case you want some of those changes. The main maintainer of the tic80 repo was asking me if we could add s7 as a submodule to the tic80 repo, like most other languages were setup to be. To achieve this though, we would need a good coordination of my changes into your s7 repo but also, I think that we don't have the access rights to your repo. When I try to clone it externally, it doesn't work with this error: "fatal: unable to access 'https://cm-gitlab.stanford.edu/bil/s7/': SSL certificate problem: unable to get local issuer certificate" I noticed that there is a work around but if this is to be a tic-80 submodule, then it would need to work directly I think. Anyways, thanks again for your great scheme implementation and your support! -- David On Fri, Feb 3, 2023 at 1:52 PM wrote: > > Would there be a way to give a better error message? > > The error message is the third argument to error_nr. > One simple change might be to forward declare wrap_string > and set_elist_1, > > static s7_pointer set_elist_1(s7_scheme *sc, s7_pointer x1); > static s7_pointer wrap_string(s7_scheme *sc, const char *str, s7_int > len); > > then > > static size_t local_fwrite(const void *ptr, size_t size, size_t nmemb, > FILE *stream) > { > error_nr(cur_sc, cur_sc->io_error_symbol, > set_elist_1(cur_sc, wrap_string(cur_sc, "writing a file is > not allowed in this version of s7", 51))); > } > > and similarly for local_fopen. The integer (51 above) is the length of > the > error message string. > > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s7-tic80.diff Type: text/x-patch Size: 7463 bytes Desc: not available URL: From bil at ccrma.Stanford.EDU Fri Feb 10 06:09:18 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 10 Feb 2023 06:09:18 -0800 Subject: [CM] Snd 23.1 Message-ID: <5946ee8664f594148383ffec1661d36b@ccrma.stanford.edu> Snd 23.1: clm: Michael Edwards fixed a bug in scentroid.ins. s7: David St-Hilaire integrated s7 into tic-80. checked: FC 37, sbcl 2.3.1 Thanks!: David St-Hilaire, Michael Edwards From iainduncanlists at gmail.com Fri Feb 24 07:41:20 2023 From: iainduncanlists at gmail.com (Iain Duncan) Date: Fri, 24 Feb 2023 07:41:20 -0800 Subject: [CM] How are people handling modules/imports? Message-ID: Hi all, just curious to hear how others are making a module/import system in s7. I have a project now that would really benefit from some better protection against name collisions if I am to share it. thanks! iain -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at eggheadgames.com Fri Feb 24 11:03:46 2023 From: mike at eggheadgames.com (Michael Mee) Date: Fri, 24 Feb 2023 11:03:46 -0800 Subject: [CM] How are people handling modules/imports? In-Reply-To: References: Message-ID: FWIW, we have several modules that we include using r7rs syntax (using a subset of the s7 r7rs shim). I?m not sure that we tested for name collisions explicitly, but it worked fine for basic code organisation mapping to directory/subdirectory (see thread subject: ?R7RS support?, Jan 2022). The only other caveat we saw was previously mentioned on this list with subject: ?Variables in R7RS libraries?. Cheers, Michael On 24 Feb 2023, at 7:41, Iain Duncan wrote: > Hi all, just curious to hear how others are making a module/import > system > in s7. I have a project now that would really benefit from some better > protection against name collisions if I am to share it. > > thanks! > iain > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist From iainduncanlists at gmail.com Fri Feb 24 13:48:10 2023 From: iainduncanlists at gmail.com (Iain Duncan) Date: Fri, 24 Feb 2023 13:48:10 -0800 Subject: [CM] How are people handling modules/imports? In-Reply-To: References: Message-ID: Thanks Michael. Do you have any links to code one could look at? (understand if not!) iain On Fri, Feb 24, 2023 at 11:03 AM Michael Mee wrote: > FWIW, we have several modules that we include using r7rs syntax (using a > subset of the s7 r7rs shim). I?m not sure that we tested for name > collisions explicitly, but it worked fine for basic code organisation > mapping to directory/subdirectory (see thread subject: ?R7RS > support?, Jan 2022). The only other caveat we saw was previously > mentioned on this list with subject: ?Variables in R7RS libraries?. > > Cheers, Michael > > On 24 Feb 2023, at 7:41, Iain Duncan wrote: > > > Hi all, just curious to hear how others are making a module/import > > system > > in s7. I have a project now that would really benefit from some better > > protection against name collisions if I am to share it. > > > > thanks! > > iain > > _______________________________________________ > > Cmdist mailing list > > Cmdist at ccrma.stanford.edu > > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: