* Re: SRFI-64 module and SRFI-78 module -- archive file attached [not found] ` <CA+U71=PEZd2OpLc6iWSFJ1jVbQVVpubwfdm4fiauXi9gVmS0PQ@mail.gmail.com> @ 2012-05-10 9:49 ` Sunjoong Lee 2012-05-12 17:30 ` Noah Lavine 0 siblings, 1 reply; 4+ messages in thread From: Sunjoong Lee @ 2012-05-10 9:49 UTC (permalink / raw) To: Noah Lavine; +Cc: guile-devel Hi, Noah; I'd felt afraid of guile-devel@gnu.org because I'm just a newbie and a poor enghlish reader/writer; especially of language problem. Noah Lavine <noah.b.lavine@gmail.com> writes: > Hello, > > I'd just like to ask what your goal is for these modules. Are you just > telling Guile users about these modules, or would you like them > included with Guile itself? > My goal? Hum... Like other people, I'd googled when I'd needed a test suite. I'd heard the SRFI 64 and SRFI 78 but not been able to use it then. So, I'd tried with unit-test in guile-lib. unit-test is good but my concern was abnormal case, i.e., error or exception. unit-test supports assert-exception macro but I feel insufficient when unexpected exception occur. So, I was back to SRFI 64 and made it work on Guile. I think there are people googling for test suite like me. If Guile include SRFI 64 in bundle, it would be helpful to them. > If it's the first one, thank you very much. If it's the second, could > you send this email again to guile-devel@gnu.org? We'd be happy to > talk about it there. > > Thanks a lot for writing Guile code, > Noah Lavine > Talking about the original SRFI 64 implementation of Per's, i.e., reference or upstream, there was a bug and laked functionalities unless on Kawa or MzScheme. I'm a newbie of scheme and begined at Guile but might expand to Chicken and/or Gambit. Portability of test suite might be important, I think. Test code using my implementation will work on Chicken and Gambit too. Of course, it will work on Kawa or MzScheme with the reference implementation. I think a porting for Guile 2.0 is finished. There is one functionality issue, a source code line numbering support, for Guile 1.8, Chicken and Gambit. > On Thu, May 3, 2012 at 2:45 AM, Sunjoong Lee <sunjoong@gmail.com> wrote: >> Hello, >> >> SRFI-64 - https://gitorious.org/srfi-64-guile/ >> SRFI-78 - https://gitorious.org/srfi-78-guile/ >> Thanks. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: SRFI-64 module and SRFI-78 module -- archive file attached 2012-05-10 9:49 ` SRFI-64 module and SRFI-78 module -- archive file attached Sunjoong Lee @ 2012-05-12 17:30 ` Noah Lavine 2012-05-13 21:22 ` Sunjoong Lee 0 siblings, 1 reply; 4+ messages in thread From: Noah Lavine @ 2012-05-12 17:30 UTC (permalink / raw) To: Sunjoong Lee; +Cc: guile-devel Hello, > I'd felt afraid of guile-devel@gnu.org because I'm just a newbie and a > poor enghlish reader/writer; especially of language problem. That's fine. I am sure that you will get used to it if you contribute a lot. > My goal? Hum... Like other people, I'd googled when I'd needed a test > suite. I'd heard the SRFI 64 and SRFI 78 but not been able to use it > then. So, I'd tried with unit-test in guile-lib. > > unit-test is good but my concern was abnormal case, i.e., error or > exception. unit-test supports assert-exception macro but I feel > insufficient when unexpected exception occur. So, I was back to SRFI 64 > and made it work on Guile. > > I think there are people googling for test suite like me. If Guile > include SRFI 64 in bundle, it would be helpful to them. Thanks for doing that! I have only read SRFI-64 yet, but I have a few comments. First of all, it would be nice you had tests for it. You might be able to use SRFI-64 to test itself, which would be cool. Second, since your changes add compatibility for several Scheme implementations, have you thought about trying to make them part of the reference implementation? You would probably have to email Per Bothner to ask him, but that might be the best way to make your changes available to all of the implementations you are making it for. If not, I hope Guile would like to have it, but I think you are targeting more than just Guile. Noah ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: SRFI-64 module and SRFI-78 module -- archive file attached 2012-05-12 17:30 ` Noah Lavine @ 2012-05-13 21:22 ` Sunjoong Lee 0 siblings, 0 replies; 4+ messages in thread From: Sunjoong Lee @ 2012-05-13 21:22 UTC (permalink / raw) To: Noah Lavine; +Cc: guile-devel Hi, Noah; Thanks for comments. On 05/13/2012 Noah Lavine <noah.b.lavine@gmail.com> writes: > Second, since your changes add compatibility for several Scheme > implementations, have you thought about trying to make them part of > the reference implementation? You would probably have to email Per > Bothner to ask him, but that might be the best way to make your > changes available to all of the implementations you are making it for. > If not, I hope Guile would like to have it, but I think you are > targeting more than just Guile. When I'd made my srfi-64.scm to pass srfi-64-test.scm, a test suite for the SRFI 64 itself, on Guile 2.0.0, I felt happy and remembered my googling to search a SRFI 64 implementation working on Guile. Now, the filename of srfi-64.scm is srfi-64-port.scm and the new srfi-64.scm file uses it with include-from-path. Hum... I use Guile 2.0.5 now. Anyway, I'd sent a email to Per Bothner and he had commented on it. On 04/13/2012 Per Bothner <per@bothner.com> writes: > This is nice. It would be great if the Guile port would be merged > into the reference implementation, presumably using cond-expand. > That way bug-fixes or changes in one could be more easily be > merged into the other. I'd misunderstood his words then. In the reply for you, Per wrote: On 04/20/2012 Per Bothner <per@bothner.com> writes: > My suggestion was that it would be nice (but not essential) > if the Guile implementation could be based on and merged back into > the reference implementation, perhaps using cond-expand to > encapsulate the Guile-specific changes. > > Unfortunately, this Guile port seems like a complete rewrite: > The diff (relative to the reference implementation) is over twice as big > as than the original reference implementation! This makes it difficult > to evaluate the changes, which makes it difficult to accept it as an > update to the reference implementation. I was hoping the Guile port would > be a modest set of changes to the reference implementation; this is > not. After his first comments, I'd misunderstood it of course, I found the reference implementation does not pass srfi-64-test.scm on Chicken and Gambit either. I fixed it with my srfi-64.scm. After his second comments, a reply for you of course, I understood his first comments and made a patch file for the reference implementation. That patch was just for Guile and not included fix for Chicken and Gambit. On 04/21/2012 Per Bothner <per@bothner.com> writes: > Much better. I applied your patch to the reference implementation, > and that seems to work. I source file name and line numbers, which > makes things much more pleasant. I'm waiting Per publish a new version of the reference implementation. In the mean while, I had realized my srfi-64.scm had a bug; I'd used cond-expand-provide within cond-expand and that made a problem. So, I renamed srfi-64.scm to srfi-64-port.scm and wrote a new srfi-64.scm using it with include-from-path. Talking about Gambit, there are a Black Hole, a moudle system for Gambit, module called srfi; srfi moudle has test.scm and it's a almost testing.scm, a Per's reference implementation. So, it would fail to srfi-64-test.scm, I think. Talking about Chicken, there a egg, a module system for Chicken, moudle called test; test moudle is very similar to SRFI 64 but not is. I'd failed to compile the reference implementation on Chicken. Of course, srfi-64-port.scm can be compiled. On Kawa and Rocket, the reference implementation would work well. My point is SRFI 64 support on Guile would be helpful to people want to write a portable test code. For me, I'm contented with Guile 2.0 now but might want to write a Gambit or Chicken code someday and want not to study syntax for writing a test code itself again. Is SRFI 64 perfect? Of course not, but I would re-use my own test codes if it's based on SRFI 64, I think. So, I'd avoid making srfi-64-port.scm go from SRFI 64 specification. SRFI 78 module is a bonus; I'm not sure that be a right expression, a bonus. SRFI 78 is a very simple application of SRFI 42 and Guile supports SRFI 42 already. Thanks. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: SRFI-64 module and SRFI-78 module -- archive file attached [not found] ` <CAK93xhqT--JGaQfkdX8k_=X2PZJpw1g_XqhRPcjCAdk=MSHzuw@mail.gmail.com> [not found] ` <CA+U71=PEZd2OpLc6iWSFJ1jVbQVVpubwfdm4fiauXi9gVmS0PQ@mail.gmail.com> @ 2012-05-14 14:07 ` Sunjoong Lee 1 sibling, 0 replies; 4+ messages in thread From: Sunjoong Lee @ 2012-05-14 14:07 UTC (permalink / raw) To: guile-user; +Cc: guile-devel [-- Attachment #1: Type: text/plain, Size: 454 bytes --] URL changed: SRFI 64: "A Scheme API for test suites by Per Bothner" Guile implementation - https://gitorious.org/srfi-64-port/srfi-64-guile SRFI 78: "Lightweight testing by Sebastian Egner" Guile module - https://gitorious.org/srfi-78-guile Test code added: Modified test suite for the testing SRFI 64 to use (test-suite lib) module of Guile source archive - https://gitorious.org/srfi-64-port/srfi-64-guile/blobs/master/test-suite/tests/srfi-64.test [-- Attachment #2: Type: text/html, Size: 835 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-05-14 14:07 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <CAK93xho3cVcXZe0o9_PeLXx1DdvcYt-oEzMmvTBVqpKJMBUpyQ@mail.gmail.com> [not found] ` <CAK93xhqT--JGaQfkdX8k_=X2PZJpw1g_XqhRPcjCAdk=MSHzuw@mail.gmail.com> [not found] ` <CA+U71=PEZd2OpLc6iWSFJ1jVbQVVpubwfdm4fiauXi9gVmS0PQ@mail.gmail.com> 2012-05-10 9:49 ` SRFI-64 module and SRFI-78 module -- archive file attached Sunjoong Lee 2012-05-12 17:30 ` Noah Lavine 2012-05-13 21:22 ` Sunjoong Lee 2012-05-14 14:07 ` Sunjoong Lee
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).