* 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).