Hi, We'll release Ruby 1.9.0-2 (next snapshot of Ruby 1.9.0) before (or in) next RubyKaigi (20th to 22th, June 2008). 1st target date is 19th June. To release it, we'll empt KNOWNBUGS.rb, or move bugs to PENDING list at that date. Please don't add any new features from 16th June to release day of Ruby 1.9.0-2 (maybe 19th June, but it can be postponed). I'll battle with KNOWNBUGS.rb. Regards,
on 09.06.2008 15:24
on 15.06.2008 19:10
Hi, Do you have/know any task to release 1.9.0-2? * critical bugs * new features I'll fix bugs about global jump with lambda today.
on 15.06.2008 19:56
SASADA Koichi wrote:
> * critical bugs
it depend what you call critical bugs,
for example Class#dup don't work
and look at
[ruby-core:17019]
critical or not ?
Guy Decoux
on 15.06.2008 23:20
ts wrote: > it depend what you call critical bugs, > for example Class#dup don't work > and look at > > [ruby-core:17019] > > critical or not ? I recognize this bug now. it's critical, but maybe pending bug. I'll fix it at 1.9.0-3. copying iseq is bad idea....
on 15.06.2008 23:36
On Jun 9, 2008, at 06:20 AM, SASADA Koichi wrote: > Hi, > > We'll release Ruby 1.9.0-2 (next snapshot of Ruby 1.9.0) before (or > in) next RubyKaigi (20th to 22th, June 2008). 1st target date is > 19th June. I will import a new RubyGems to trunk before June 19th.
on 16.06.2008 07:56
On Jun 15, 2008, at 10:05 , SASADA Koichi wrote: > Do you have/know any task to release 1.9.0-2? > > * critical bugs > * new features I have not heard from Matz wrt miniunit. I'd really like to get it into 1.9 in order to improve the features, speed things up, and ease maintenance.
on 16.06.2008 12:31
Hi,
In message "Re: [ruby-core:17273] Re: Release Plan: Ruby 1.9.0-2"
on Mon, 16 Jun 2008 14:54:55 +0900, Ryan Davis
<ryand-ruby@zenspider.com> writes:
|On Jun 15, 2008, at 10:05 , SASADA Koichi wrote:
|
|> Do you have/know any task to release 1.9.0-2?
|>
|> * critical bugs
|> * new features
|
|I have not heard from Matz wrt miniunit. I'd really like to get it
|into 1.9 in order to improve the features, speed things up, and ease
|maintenance.
I didn't know I was asked for a decision on miniunit. If it would not
raise serious compatibility issues, I have no objection.
matz.
on 16.06.2008 13:43
Hi, In <F732B60B-DA6E-452A-8EB6-8E2B071294F2@zenspider.com> "[ruby-core:17273] Re: Release Plan: Ruby 1.9.0-2" on Mon, 16 Jun 2008 14:54:55 +0900, Ryan Davis <ryand-ruby@zenspider.com> wrote: > > Do you have/know any task to release 1.9.0-2? > > > > * critical bugs > > * new features > > I have not heard from Matz wrt miniunit. I'd really like to get it > into 1.9 in order to improve the features, speed things up, and ease > maintenance. I can understand that 'speed things up' but can't others. Can I hear about your 'improve the features' and 'ease maintenance'? What are the features? Mock? On the other hand, miniunit reduce some features. e.g. miniunit don't handle most of options that are accepted by Test::Unit even if --help. Is it OK? It's not good thing for me. I'm using --name=XXX form, -v v and so on. What is the maintenance? Improve miniunit? Keep fixing bugs? It seems that you want users to improve miniunit by a gem. So it seems that you don't want to improve miniunit itself. If the maintenance means that you keep fixing bugs, I can't understand why it breaks the current Test::Unit API. We are using Test::Unit features that miniunit doesn't support. e.g. option parsing, Test::Case#run isn't defined and so on. Are you thinking that it's too high cost for you that you maintain (not improve features, just only bug fixes) Test::Unit with the current code base? Thanks,
on 17.06.2008 16:11
I propose to hold comit miniunit. It seems that we need more discussion.
on 18.06.2008 06:38
On Jun 16, 2008, at 04:39 , Kouhei Sutou wrote: >>> * new features >> >> I have not heard from Matz wrt miniunit. I'd really like to get it >> into 1.9 in order to improve the features, speed things up, and ease >> maintenance. > > I can understand that 'speed things up' but can't others. > Can I hear about your 'improve the features' and 'ease > maintenance'? I've already detailed this in [ruby-core:17200]. > What are the features? Mock? On the other hand, miniunit > reduce some features. e.g. miniunit don't handle most of > options that are accepted by Test::Unit even if --help. Is > it OK? It's not good thing for me. I'm using --name=XXX > form, -v v and so on. "[miniunit] increases the number of assertions and adds mini/spec (an rspec-like extension) and mini/mock (a very clean and simple mock framework). Providing spec and mock extensions round out the functionality quite nicely and allow people to test however they work best." I support -n and -v. --name is too much typing. I didn't see the point of dragging in an option parser that was larger than my impl+test. I like simple. It supports everything that autotest requires and all my other daily usage patterns. I can add -h. > What is the maintenance? Improve miniunit? Keep fixing bugs? miniunit is: + 1/3rd the complexity of test/unit, but provides the same functionality. + 1/5th the implementation size of test/unit + 1/3rd the test size of test/unit. + or 1/4th the size overall. and that is with additional functionality. It'd be even more if I just stuck to unit testing. The code is simple and fairly clean. That is the maintainability I refer to. Certainly I will fix bugs if they are found. > It seems that you want users to improve miniunit by a > gem. So it seems that you don't want to improve miniunit > itself. I don't know what you mean by this. I certainly intend to improve miniunit (although it seems very good already :D). I would also love to see more people extending it through gems and have designed it specifically to make extending it easy... something I found incredibly hard to do with test/unit (and why I wrote miniunit to begin with). > If the maintenance means that you keep fixing bugs, I can't > understand why it breaks the current Test::Unit API. We are > using Test::Unit features that miniunit doesn't > support. e.g. option parsing, Test::Case#run isn't defined > and so on. Are you thinking that it's too high cost for you > that you maintain (not improve features, just only bug > fixes) Test::Unit with the current code base? I certainly think that maintaining Test::Unit is too high a burden. I broke Test::Unit (again, INTERNAL) API because there was no method to the madness. I find the code to be incredibly complex for very little gain. For those that need test/unit internal API (like IDEs or graphical test UIs), we released as a gem, but for ruby itself? I don't see the point of having all the pain. I've spent less than an hour (ie, a small and reasonable amount of time) running 1.9 tests with both test/unit and miniunit and got the results within a reasonable level of sameness. Unfortunately, ruby testing on OSX seems to be very inconsistent, so I can't tell what's because of miniunit (if anything) and what isn't. 505 % tail -2 tests.before.txt tests.after.txt ==> tests.before.txt <== 4650 tests, 1659634 assertions, 37 failures, 79 errors ==> tests.after.txt <== 4610 tests, 1689855 assertions, 49 failures, 134 errors Given this, is there any reason NOT to switch? As an aside, I'm don't understand why you're questioning switching 1.9 to miniunit. I thought I detailed all of this to you back when you expressed interest in working on test/unit (feb/mar?). None of this should be new (except for specs and mocks).
on 18.06.2008 06:42
On Jun 17, 2008, at 07:09 , SASADA Koichi wrote: > I propose to hold comit miniunit. It seems that we need more > discussion. OK. :(
on 18.06.2008 15:24
On Jun 17, 2008, at 11:38 PM, Ryan Davis wrote: > On Jun 17, 2008, at 07:09 , SASADA Koichi wrote: > >> I propose to hold comit miniunit. It seems that we need more >> discussion. > > OK. :( I realize I don't have any say here, but I'm for the miniunit switch. It's my opinion that we switched to FasterCSV for very similar reasons and it sounds like the CSV change had more compatibility issues than we are facing here. We gain simpler code plus new features. I call that a win. James Edward Gray II
on 19.06.2008 04:59
SASADA Koichi wrote:
> I'll battle with KNOWNBUGS.rb.
Do you have any other issues on 1.9.0-2?
Could you try on your environment? I have tried on Linux
(i386/amd64), and trying on mswin32, cygwin.
on 19.06.2008 09:56
SASADA Koichi wrote: > Could you try on your environment? I have tried on Linux > (i386/amd64), and trying on mswin32, cygwin. We'll release 1.9.0-2 on next morning (JST). We have 12 hours to try it. Regards,
on 19.06.2008 11:16
SASADA Koichi wrote: > We'll release 1.9.0-2 on next morning (JST). We have 12 hours to > try it. Well 2 cases that I think are easy to fix. 1) The second example in [ruby-15711] vgs% cat b.rb class Foo def call_it p = Proc.new p.call end end def give_it lambda { puts 'bar' } end f = Foo.new a_proc = give_it f.call_it(&a_proc) vgs% 1.9 search on the stack frame something that it can't find and worst it don't need to look on the stack. 2) [ruby-core:15719] I think that it just need to call method_missing rather than saying that it can't find super Guy Decoux
on 19.06.2008 12:32
From: "SASADA Koichi" <ko1@atdot.net> > SASADA Koichi wrote: >> Could you try on your environment? I have tried on Linux >> (i386/amd64), and trying on mswin32, cygwin. > > We'll release 1.9.0-2 on next morning (JST). We have 12 hours to > try it. Hi, I updated to revision 17425 in trunk, and built on WinXP using Visual Studio .NET 2003. I did `nmake clean`, then: .\win32\configure.bat --prefix=m:/dev/ruby-build/trunk Then `nmake`, then `nmake test`. I'm getting a crash on `make test` in: test_thread.rb ... 4652 rb_thread_execute_interrupts _getptd Normal 0 5524 timer_thread_func timer_thread_func Normal 0 > 5080 Win32 Thread 00000000 Normal 0 4248 thread_start_func_1 native_mutex_lock Normal 0 EAX = 00000000 EBX = 009E2ED0 ECX = 009E4008 EDX = 009E4008 ESI = 00B4A1B0 EDI = 7C911538 EIP = 00000000 ESP = 012AFED0 EBP = 012AFED8 EFL = 00000202 CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 003B GS = 0000 OV = 0 UP = 0 EI = 1 PL = 0 ZR = 0 AC = 0 PE = 0 CY = 0 It seems "Win32 Thread" has jumped to address 0x00000000. Unfortuantely, the debugger displays an empty call stack for "Win32 Thread". However, [ESP] is 0x004e1677, which is: --- p:\code\ruby-svn\trunk\thread.c -------------------------------------------- static void rb_thread_interrupt(rb_thread_t *th) { 004E1640 push ebp 004E1641 mov ebp,esp native_mutex_lock(&th->interrupt_lock); 004E1643 mov eax,dword ptr [th] 004E1646 add eax,60h 004E1649 push eax 004E164A call native_mutex_lock (4E12A0h) 004E164F add esp,4 RUBY_VM_SET_INTERRUPT(th); 004E1652 mov ecx,dword ptr [th] 004E1655 mov edx,dword ptr [ecx+5Ch] 004E1658 or edx,2 004E165B mov eax,dword ptr [th] 004E165E mov dword ptr [eax+5Ch],edx if (th->unblock.func) { 004E1661 mov ecx,dword ptr [th] 004E1664 cmp dword ptr [ecx+78h],0 004E1668 je rb_thread_interrupt+3Ah (4E167Ah) (th->unblock.func)(th->unblock.arg); 004E166A mov edx,dword ptr [th] 004E166D mov eax,dword ptr [edx+7Ch] 004E1670 push eax 004E1671 mov ecx,dword ptr [th] 004E1674 call dword ptr [ecx+78h] > 004E1677 add esp,4 } else { /* none */ } native_mutex_unlock(&th->interrupt_lock); 004E167A mov edx,dword ptr [th] 004E167D add edx,60h 004E1680 push edx 004E1681 call native_mutex_unlock (4E12C0h) 004E1686 add esp,4 } 004E1689 pop ebp 004E168A ret The memory at ECX is: (ecx+78h marked with [00000000]) 0x009E4008 00ae9994 009e2df0 00a50020 00020000 00acfdf0 00000000 00000000 00000000 0x009E4028 00000000 00b05964 00000000 00000000 00000000 00000000 000007ac 00000003 0x009E4048 00000000 000007a8 00ae8aa8 00000000 00000004 00000000 00000000 00000002 0x009E4068 00145758 00000000 00000001 000013d8 00000000 00000000[00000000]00000000 0x009E4088 00000000 00000000 0012d32c 00000000 00000000 00000000 00000000 00000000 0x009E40A8 00000000 00000000 00000000 0012fffc 0012d2ac 000ccccd 0012d2bc 7ffde000 0x009E40C8 00000000 0012e2ac 0012d2b0 004e3205 0012ffb0 00000000 56433230 00000000 0x009E40E8 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 So it appears th->unblock.func was cleared, in between: 004E1664 cmp dword ptr [ecx+78h],0 and 004E1674 call dword ptr [ecx+78h] ?? Either that or something stomped on [th] which is really [ebp+8] ... but it doesn't look like garbage, to me: 0x012AFED8 012aff64 004e1ce3[009e4008]00000000 00000000 00b38b40 00bd0448 012aff64 0x012AFEF8 009e2ed0 7c911538 00b4a1b0 012afed8 004e1ac5 012affa4 00000000 56433230 0x012AFF18 00000000 012aff3c 012aff3c 0000001c 012aff68 004e16c6 012aff3c 00000000 The other threads are at: thread 4652 rb_thread_execute_interrupts _getptd Normal 0 ---- [...] msvcr71.dll!_getptd() Line 319 C miniruby.exe!rb_thread_schedule() Line 783 + 0x5 C miniruby.exe!rb_thread_execute_interrupts(rb_thread_struct * th=) Line 890 C void rb_thread_schedule(void) { 004E2140 push ebp 004E2141 mov ebp,esp 004E2143 push ecx thread_debug("rb_thread_schedule\n"); 004E2144 xor eax,eax 004E2146 je rb_thread_schedule+16h (4E2156h) 004E2148 push offset string "rb_thread_schedule\n" (50D060h) 004E214D call dword ptr [__imp__printf (4F12B8h)] 004E2153 add esp,4 if (!rb_thread_alone()) { 004E2156 call rb_thread_alone (4E2AC0h) > 004E215B test eax,eax 004E215D jne rb_thread_schedule+0BFh (4E21FFh) rb_thread_t *th = GET_THREAD(); thread 5524 timer_thread_func timer_thread_func Normal 0 ---- [...] ntdll.dll!7c90eb94() ntdll.dll!7c90d85c() kernel32.dll!7c8023ed() kernel32.dll!7c802451() miniruby.exe!timer_thread_func(void * dummy=0x00000000) Line 546 C msvcr71.dll!_threadstartex(void * ptd=0x00b3a780) Line 241 + 0x6 C static unsigned long _stdcall timer_thread_func(void *dummy) { 004E13A0 push ebp 004E13A1 mov ebp,esp thread_debug("timer_thread\n"); 004E13A3 xor eax,eax 004E13A5 je timer_thread_func+15h (4E13B5h) 004E13A7 push offset string "timer_thread\n" (50CD74h) 004E13AC call dword ptr [__imp__printf (4F12B8h)] 004E13B2 add esp,4 while (system_working) { 004E13B5 cmp dword ptr [system_working (52AC24h)],0 004E13BC je timer_thread_func+2Dh (4E13CDh) Sleep(WIN32_WAIT_TIMEOUT); 004E13BE push 0Ah 004E13C0 call dword ptr [__imp__Sleep@4 (4F10E8h)] timer_thread_function(); > 004E13C6 call timer_thread_function (4E3210h) } 004E13CB jmp timer_thread_func+15h (4E13B5h) thread_debug("timer killed\n"); thread 4248 thread_start_func_1 native_mutex_lock Normal 0 ---- [...] ntdll.dll!7c90104b() miniruby.exe!native_mutex_lock(_RTL_CRITICAL_SECTION * lock=0x009e2df4) Line 285 C miniruby.exe!thread_start_func_2(rb_thread_struct * th=0x00b80818, unsigned long * stack_start=0x013aff7c) Line 334 + 0xf C miniruby.exe!thread_start_func_1(void * th_ptr=0x00b80818) Line 476 + 0xd C msvcr71.dll!_threadstartex(void * ptd=0x00b4a338) Line 241 + 0x6 C static int thread_start_func_2(rb_thread_t *th, VALUE *stack_start, VALUE *register_stack_start) { 004E1A10 push ebp 004E1A11 mov ebp,esp 004E1A13 sub esp,80h int state; VALUE args = th->first_args; 004E1A19 mov eax,dword ptr [th] 004E1A1C mov ecx,dword ptr [eax+0A4h] 004E1A22 mov dword ptr [args],ecx rb_proc_t *proc; rb_thread_t *join_th; rb_thread_t *main_th; VALUE errinfo = Qnil; 004E1A25 mov dword ptr [errinfo],4 th->machine_stack_start = stack_start; 004E1A2C mov edx,dword ptr [th] 004E1A2F mov eax,dword ptr [stack_start] 004E1A32 mov dword ptr [edx+0ACh],eax #ifdef __ia64 th->machine_register_stack_start = register_stack_start; #endif thread_debug("thread start: %p\n", th); 004E1A38 xor ecx,ecx 004E1A3A je thread_start_func_2+3Eh (4E1A4Eh) 004E1A3C mov edx,dword ptr [th] 004E1A3F push edx 004E1A40 push offset string "thread start: %p\n" (50CF90h) 004E1A45 call dword ptr [__imp__printf (4F12B8h)] 004E1A4B add esp,8 native_mutex_lock(&th->vm->global_vm_lock); 004E1A4E mov eax,dword ptr [th] 004E1A51 mov ecx,dword ptr [eax+4] 004E1A54 add ecx,4 004E1A57 push ecx 004E1A58 call native_mutex_lock (4E12A0h) > 004E1A5D add esp,4 { thread_debug("thread start (get lock): %p\n", th); 004E1A60 xor edx,edx Here's the [th] structure from the crashed Win32 Thread: - th 0x009e4008 self 11442580 unsigned long - vm 0x009e2df0 self 11442600 unsigned long - global_vm_lock + DebugInfo 0x00145730 LockCount 2 long RecursionCount 1 long OwningThread 0x000013d8 void * LockSemaphore 0x00000774 void * SpinCount 0 unsigned long + main_thread 0x009e4008 {self=11442580 vm=0x009e2df0 [...] + running_thread 0x00b80558 {self=12387400 vm=0x009e2df0 [...] + living_threads 0x00b38b40 {type=0x00508b58 type_numhash num_bins=11 entries_packed=1 ...} st_table * thgroup_default 11438760 unsigned long last_status 0 unsigned long running 1 int thread_abort_on_exception 0 int trace_flag 0 unsigned long sleeper 4419 volatile int mark_object_ary 11539260 unsigned long + special_exceptions 0x009e2e34 unsigned long [3] top_self 11557220 unsigned long load_path 11456220 unsigned long loaded_features 11456160 unsigned long + loading_table 0x00000000 {type=??? num_bins=??? entries_packed=??? ...} st_table * + signal_buff 0x009e2e50 long [23] buffered_signal_size 0 long + event_hooks 0x00000000 {flag=??? func=??? data=??? ...} rb_event_hook_struct * src_encoding_index -1 int verbose 4 unsigned long debug 0 unsigned long progname 11429980 unsigned long + stack 0x00a50020 unsigned long * stack_size 131072 unsigned long + cfp 0x00acfdf0 {pc=0x00000000 sp=0x00a5007c bp=0x00a5007c ...} rb_control_frame_t * safe_level 0 int raised_flag 0 int state 0 int + passed_block 0x00000000 {self=??? lfp=??? dfp=??? ...} rb_block_struct * top_self 11557220 unsigned long top_wrapper 0 unsigned long + base_block 0x00000000 {self=??? lfp=??? dfp=??? ...} rb_block_struct * + local_lfp 0x00000000 unsigned long * local_svar 0 unsigned long thread_id 0x000007ac void * status THREAD_STOPPED_FOREVER rb_thread_status priority 0 int + native_thread_data {interrupt_event=0x000007a8 } native_thread_data_struct thgroup 11438760 unsigned long value 0 unsigned long errinfo 4 unsigned long thrown_errinfo 0 unsigned long exec_signal 0 int interrupt_flag 2 int + interrupt_lock {DebugInfo=0x00145758 {Type=0 CreatorBackTraceIndex=0 CriticalSection=0x009e4068 {DebugInfo=0x00145758 {Type=0 CreatorBackTraceIndex=0 CriticalSection=0x009e4068 ...} LockCount=0 RecursionCount=1 ...} ...} LockCount=0 RecursionCount=1 ...} _RTL_CRITICAL_SECTION + unblock {func=0x00000000 arg=0x00000000 } rb_unblock_callback locking_mutex 0 unsigned long keeping_mutexes 0 unsigned long + tag 0x0012d32c {buf=0x0012d32c tag=0 retval=1 ...} rb_vm_tag * + trap_tag 0x00000000 {prev=??? } rb_vm_trap_tag * parse_in_eval 0 int + local_storage 0x00000000 {type=??? num_bins=??? entries_packed=??? ...} st_table * + join_list_next 0x00000000 {self=??? vm=??? stack=??? ...} rb_thread_struct * + join_list_head 0x00000000 {self=??? vm=??? stack=??? ...} rb_thread_struct * first_proc 0 unsigned long first_args 0 unsigned long first_func 0x00000000 unsigned long (void)* + machine_stack_start 0x0012fffc unsigned long * + machine_stack_end 0x0012d2ac unsigned long * machine_stack_maxsize 838861 unsigned int + machine_regs 0x009e40c0 int [16] mark_stack_len 0 int stat_insn_usage 0 unsigned long + event_hooks 0x00000000 {flag=??? func=??? data=??? ...} rb_event_hook_struct * event_flags 0 unsigned int tracing 0 int fiber 0 unsigned long root_fiber 0 unsigned long + root_jmpbuf 0x009e411c int [16] method_missing_reason 0 int abort_on_exception 0 int . . . I fixed up the stack, and let the program continue. It appeared to exit cleanly, however the "test_thread.rb ...." did not continue, so I hit ^C. The tests completed with: #822 test_thread.rb: FAIL 1/861 tests failed I ran `nmake test` again, but it did not crash this time. I will try a few more times to see if it might happen again. Hope this helps... Please let me know if there's any additional information I should provide if it happens again. Regards, Bill
on 19.06.2008 12:50
From: "Bill Kelly" <billk@cts.com> > > I ran `nmake test` again, but it did not crash this time. > > I will try a few more times to see if it might happen again. $ while [ true ] ; do nmake test ; done ...crashed after a few repetitions. However, it's in a slightly different place this time, but again a field in the [th] structure is zero: 1140 rb_thread_execute_interrupts native_mutex_lock Normal 0 3344 timer_thread_func timer_thread_func Normal 0 > 3588 thread_start_func_1 ubf_handle Normal 0 EAX = 00000000 EBX = 00B3A838 ECX = 00000000 EDX = 009E4118 ESI = 009E2EE8 EDI = 7C911538 EIP = 004E1303 ESP = 0101FEC8 EBP = 0101FECC EFL = 00000246 CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 003B GS = 0000 OV = 0 UP = 0 EI = 1 PL = 0 ZR = 1 AC = 0 PE = 1 CY = 0 --- p:\code\ruby-svn\trunk\thread_win32.c -------------------------------------- static void ubf_handle(void *ptr) { 004E12E0 push ebp 004E12E1 mov ebp,esp 004E12E3 push ecx rb_thread_t *th = (rb_thread_t *)ptr; 004E12E4 mov eax,dword ptr [ptr] 004E12E7 mov dword ptr [th],eax thread_debug("ubf_handle: %p\n", th); 004E12EA xor ecx,ecx 004E12EC je ubf_handle+20h (4E1300h) 004E12EE mov edx,dword ptr [th] 004E12F1 push edx 004E12F2 push offset string "ubf_handle: %p\n" (50CD54h) 004E12F7 call dword ptr [__imp__printf (4F12B8h)] 004E12FD add esp,8 w32_set_event(th->native_thread_data.interrupt_event); 004E1300 mov eax,dword ptr [th] > 004E1303 mov ecx,dword ptr [eax+44h] 004E1306 push ecx 004E1307 call w32_set_event (4E1200h) 004E130C add esp,4 } 004E130F mov esp,ebp 004E1311 pop ebp 004E1312 ret If nobody else is getting these crashes, I would begin to worry my build is corrupted or misconfigured somehow... I'll try a fresh checkout from svn and start from scratch... Regards, Bill
on 19.06.2008 13:11
From: "Bill Kelly" <billk@cts.com> > > If nobody else is getting these crashes, I would begin to worry my build > is corrupted or misconfigured somehow... > > I'll try a fresh checkout from svn and start from scratch... From a fresh svn checkout, it still crashes (not every time, maybe 25% of the time.) This was in the exact same way as my first email: 5628 rb_thread_execute_interrupts _getptd Normal 0 5584 timer_thread_func timer_thread_func Normal 0 > 3904 Win32 Thread 00000000 Normal 0 2932 thread_start_func_1 native_mutex_lock Normal 0 Maybe we should see if anyone else can reproduce this? I don't want to waste everyone's time if it turns out something is wrong with my system. (My system is normally very stable... but who knows...) Regards, Bill
on 19.06.2008 17:50
Hi,
First, it's OK for me that replacing Test::Unit with
miniunit if miniunit provides high extensibility and will be
well maintained. (e.g. accept new extension API request if
it's needed) But it seems that high extensibility conflicts
with simple implementation.
I make a summary of Ryan's opinion. Ryan, could you confirm
it?
---
= From the maintainer(Ryan)'s point of view
== What is the Test::Unit's problem?
Test::Unit is too complex to maintain.
== Solution
Replace Test::Unit with miniunit.
miniunit is a simple, mini and clean unit testing
framework. And miniunit has Test::Unit compatible layer.
== Benefit
* ease maintenance.
* fast.
* more features rather than Test::Unit.
e.g.:
* additional assertions.
* small spec implementation.
* small mock implementation.
== Problem
None because miniunit provides Test::Unit compatible layer.
---
Here is my opinion against the maintainer's solution:
---
= From a Test::Unit user(me)'s point of view
== Problem
* miniunit isn't extensible.
* miniunit just only provides public API (*1) compatible
layer. It doesn't provide internal API (*2) compatible
layer.
(*1) TestCase#assert_*, TestCase#setup/teardown and
TestCase#run
(*2) e.g.: command line option,AutoRunner, TestCase#run
implementation, TestCase#add_{failure,error,...},
and so on
* miniunit just provides minimal features
=== miniunit isn't extensible
Unfortunately Test::Unit doesn't keep improving itself for a
few years. But there are many improvements in the
world. e.g.: RSpec provides BDD style syntax, multiple
setup/teardown (before/after) mechanism, new test (example)
status (pending) and so on. RSpec and Mocha provides a mock
system.
Some advanced users (like ActiveSupport, Mocha and so on)
extend Test::Unit by overriding existing methods and/or with
Test::Unit's internal API because Test::Unit doesn't provide
extensible interface. It causes ugly hacks.
miniunit doesn't provide extensible interface because it
introduces complex mechanism. But we need it to avoid
ugly hacks.(*) If miniunit keep simple, we will be dirty.
I want users to be simple rather than testing framework is
simple.
(*) How do we add new command line option? How do we get
colorized output? How do we get diff between expected
and actual values? Need another filter command? Need to
overriding existing methods? It doesn't conflict with
other extension?
=== miniunit just provides a public Test::Unit API compatible layer
There are some advanced users that uses Test::Unit's private
API as I mentioned in the above section. They are more users
that use tools developed by some advanced users.
Some advanced users need to implement their extended
features for miniunit and Test::Unit (for backward
compatibility) because miniunit just provides a public
Test::Unit API compatible layer. It means that miniunit will
be simple but tools developed by some advanced users may be
dirty.
Some or many tests may not worked. It's too uneasy
situation. We usually don't have tests for tests.
=== miniunit just provides minimal features
miniunit provides some advanced features: mock system and
BDD style syntax. But they just provides limited
functions. e.g. Mini::Mock can't handle multi expects for
the same name.
Most of users prefer to useful system rather than simple
system but limited features because they want to write their
tests simply like Ryan wants miniunit to be simple.
Most of users will use RSpec rather than Mini::Spec if they
want to use BDD style syntax.
Most of users will use Mocha or RSpec rather than Mini::Mock
if they want to use a mock system.
Yes, I think that miniunit is very good solution for Ruby
implementation developers because it has very small
dependencies. It doesn't use standard libraries like
OptionParser. But users doesn't require very small
dependencies. They want useful tools rather than very small
dependencies.
---
Here is a solution against the maintainer's problem proposed
by me:
---
= From my point of view
== Solution
I maintain Test::Unit.
== Benefit
* Test::Unit's API isn't broken.
* Test::Unit extension libraries are kept working.
* miniunit doesn't need to provide Test::Unit compatible
API. miniunit will be more simple.
* Ryan doesn't need to be burdened.
== Problem
* no dramatic speed up.
* no dramatic simplification.
* not trusted maintainer.
---
Here is my opinion about Test::Unit:
---
= From my point of view
== What is the Test::Unit's problem?
Extending Test::Unit causes ugly hacks.
* Test::Unit isn't extensible.
* Test::Unit has poor features under present circumstances.
The details of them are mentioned in the above sections.
== Solution
Extending Test::Unit to make it extensible.
Sample implementation:
http://rubyforge.org/projects/test-unit/
== Benefit
* reduce ugly hacks.
* some advanced users will be able to write their
extensions more simply.
* provide useful (not limited) features.
* users will be able to write their test more simply.
* keep high backward compatibility rather than miniunit.
== Problem
* will not be as simple as miniunit.
* will not be as fast as miniunit.
---
In <EC94A19D-D642-42B7-998E-748264329AFB@zenspider.com>
"[ruby-core:17312] Re: Release Plan: Ruby 1.9.0-2" on Wed, 18 Jun 2008
13:36:19 +0900,
Ryan Davis <ryand-ruby@zenspider.com> wrote:
> I support -n and -v. --name is too much typing.
I prefer to short option name on command line. But I prefer
to long option name in script because it's self-describing.
> I would also love to see more people extending it through
> gems and have designed it specifically to make extending it easy...
> something I found incredibly hard to do with test/unit (and why I
> wrote miniunit to begin with).
In my point of view, miniunit still less
extensibility. e.g. I want to add a feature that C-c
interrupt running test and show result but it seems that I
need to do ugly hack.
> 4610 tests, 1689855 assertions, 49 failures, 134 errors
>
> Given this, is there any reason NOT to switch?
Yes.
It seems that replacing in the status causes some
confusions. What is wrong? Test? Implementation? Testing
system?
What about the following work flow if we replace Test::Unit
with miniunit?
* all tests are passed with Test::Unit
* replace Test::Unit with miniunit without implementation
and test changes
* confirm all tests are still passed
* miniunit may need to more Test::Unit compatibility
features temporarily
* migrate to miniunit API?
> As an aside, I'm don't understand why you're questioning switching 1.9
> to miniunit. I thought I detailed all of this to you back when you
> expressed interest in working on test/unit (feb/mar?). None of this
> should be new (except for specs and mocks).
I'm sorry... It seems that I've misunderstood...
I understood that we do the following work flow:
* release the current Test::Unit as a gem for backward
compatibility (done)
* extend Test::Unit
* release it as a gem for preview
* update Test::Unit in the Ruby repository to the extended
Test::Unit
Thanks,
on 19.06.2008 18:33
Kouhei Sutou <kou@cozmixng.org> writes: > First, it's OK for me that replacing Test::Unit with > miniunit if miniunit provides high extensibility and will be > well maintained. (e.g. accept new extension API request if > it's needed) > But it seems that high extensibility conflicts with simple > implementation. Not necessarily. I've written a tool[1] to help track test failures over time (among other things), and I've found miniunit much, much easier to extend than test/unit. Because it's so readable, it's very easy to find at what point you should insert your modifications. Trying to do so with test/unit is still possible I'm sure, but it involves reading an order of magnitude more code before you can start. It's impossible to keep it all in your head at once. Of course this is only my experience from writing a single library. Perhaps other needs will not mesh as well with miniunit, but I would rather hear from people who have tried than speculate about it. Phil Hagelberg http://technomancy.us [1] - http://augment.rubyforge.org
on 19.06.2008 20:45
On Thu, Jun 19, 2008 at 9:31 AM, Phil Hagelberg <phil@hagelb.org> wrote: > Not necessarily. I've written a tool[1] to help track test failures over > time (among other things), and I've found miniunit much, much easier to > extend than test/unit. Because it's so readable, it's very easy to find > at what point you should insert your modifications. Trying to do so with > test/unit is still possible I'm sure, but it involves reading an order > of magnitude more code before you can start. It's impossible to keep it > all in your head at once. > > Of course this is only my experience from writing a single > library. Perhaps other needs will not mesh as well with miniunit, but I > would rather hear from people who have tried than speculate about it. Readability and understandability are important, but they do not imply extensibility. I looked at your code but didn't see any test/unit extension to compare with miniunit. I found miniunit more difficult to extend, at first, since it collapsed some methods that used to be available for override. But I gave my concerns to Ryan and he refactored to make my job easy again. So +1 for maintainability. All authors of mocking libraries should try miniunit immediately to help guide its compatibility and extensibility BEFORE it's merged with 1.9. jeremy
on 19.06.2008 23:06
Jeremy Kemper wrote: > All authors of mocking libraries should try miniunit immediately to > help guide its compatibility and extensibility BEFORE it's merged with > 1.9. +1
on 21.06.2008 06:37
Hello,
In message "[ruby-core:17341] Re: Release Plan: Ruby 1.9.0-2"
on Jun.19,2008 19:28:11, <billk@cts.com> wrote:
> I ran `nmake test` again, but it did not crash this time.
>
> I will try a few more times to see if it might happen again.
>
> Hope this helps... Please let me know if there's any additional information
> I should provide if it happens again.
I succeed to reproduce this problem on my box.
Nobu, ko1 and I will debug it tonight (JST).
Thank you for report!
Regards,
on 21.06.2008 07:53
From: "U.Nakamura" <usa@garbagecollect.jp> > Nobu, ko1 and I will debug it tonight (JST). That is some heavy firepower. That bug doesn't stand a chance. :) > Thank you for report! Thank YOU (all) for ruby! :D Regards, Bill
on 21.06.2008 09:50
Hello,
In message "[ruby-core:17359] Re: Release Plan: Ruby 1.9.0-2"
on Jun.21,2008 14:51:01, <billk@cts.com> wrote:
> > I succeed to reproduce this problem on my box.
> > Nobu, ko1 and I will debug it tonight (JST).
>
> That is some heavy firepower. That bug doesn't stand a chance. :)
Ya! Probably fixed at r17500!
Test it, please.
Regards,
on 21.06.2008 11:29
Hi, From: "U.Nakamura" <usa@garbagecollect.jp> > > Ya! Probably fixed at r17500! > Test it, please. Looks good! `nmake test` has looped for over 60 minutes. (Used to crash in less than 4 minutes.) Thanks !!! Bill
on 21.06.2008 12:26
From: "Bill Kelly" <billk@cts.com> > `nmake test` has looped for over 60 minutes. > (Used to crash in less than 4 minutes.) Still OK after 120 minutes... I'll leave it running the rest of the night (it's 3:22 AM here now...) Regards, Bill (thanks again :D)
on 24.06.2008 03:24
On Jun 19, 2008, at 08:48 , Kouhei Sutou wrote: > I make a summary of Ryan's opinion. Ryan, could you confirm > it? sure. being on the same page is a GoodThing(tm). > = From the maintainer(Ryan)'s point of view > > == What is the Test::Unit's problem? > > Test::Unit is too complex to maintain. to maintain or use/extend the internals. > == Solution > > Replace Test::Unit with miniunit. > > miniunit is a simple, mini and clean unit testing > framework. And miniunit has Test::Unit compatible layer. yes > == Benefit > > * ease maintenance. > * fast. > * more features rather than Test::Unit. > e.g.: > * additional assertions. > * small spec implementation. > * small mock implementation. yes > == Problem > > None because miniunit provides Test::Unit compatible layer. > --- for TestCase API, yes. > Here is my opinion against the maintainer's solution: > > --- > = From a Test::Unit user(me)'s point of view > > == Problem > > * miniunit isn't extensible. false. it is ruby. it is just as extendable as test/unit, if not more, since it is cleaner. > * miniunit just only provides public API (*1) compatible > layer. It doesn't provide internal API (*2) compatible > layer. > > (*1) TestCase#assert_*, TestCase#setup/teardown and > TestCase#run > (*2) e.g.: command line option,AutoRunner, TestCase#run > implementation, TestCase#add_{failure,error,...}, > and so on true > * miniunit just provides minimal features it provides all features of test/unit's TestCase. It doesn't provide GUI runners. I think this is a GoodThing(tm). For those that don't (and I think they are VERY few and far between), we've released test/ unit classic as a gem. I can imagine that providing a GUI interface to miniunit isn't that hard. I don't code GUIs much, but I can imagine something working much the same way as miniunit's tests: @tu = Mini::Test.new @output = StringIO.new("") Mini::Test.output = @output So again, I don't think this is a problem. I should probably also point out that miniunit is much better tested than test/unit can ever be: lib/mini/mock.rb | 31 | 27 | 100.0% lib/mini/spec.rb | 82 | 66 | 87.9% lib/mini/test.rb | 436 | 344 | 96.8% The only parts not covered are compatibility conditionals for 1.8/1.9/ rubinius. > extend Test::Unit by overriding existing methods and/or with > Test::Unit's internal API because Test::Unit doesn't provide > extensible interface. It causes ugly hacks. miniunit is compatible with ActiveSupport already. Chad Fowler did two 1-line changes to make miniunit work with flexmock. I'm sure mocha will take a change or two, but it won't be much. The ugly hacks are required for test/unit, not for miniunit. Making miniunit work with these hacks has been ugly and painful, but it is something we can address with the library authors and clean up over time. > miniunit doesn't provide extensible interface because it > introduces complex mechanism. But we need it to avoid > ugly hacks.(*) If miniunit keep simple, we will be dirty. I disagree. I've found a number of people (besides just me) that find extending miniunit to be MUCH MUCH easier than test/unit. I rely on basic idiomatic ruby to make miniunit much more approachable. See Phil Hagelberg's previous email as evidence. Here is a real world (idiomatic) example of test/unit extension vs miniunit: def assert_sorted(actual, message=nil, &block) expected = actual.sort(&block) message ||= "Expected order:\n#{expected.inspect}\nbut got order: \n#{actual.inspect}\n" assert_block(message) { expected == actual } end vs: def assert_sorted(actual, message=nil, &block) expected = actual.sort(&block) assert_equal expected, actual, "Order is wrong:" end And that is without using the ridiculous build_message/template. I should also add that despite miniunit not being extensible, when you define assert_sorted as above, you also extend mini/spec as well: my_array.must_be_sorted { ... } > I want users to be simple rather than testing framework is > simple. I want both to be simple. These aren't mutually exclusive. > (*) How do we add new command line option? How do we get > colorized output? How do we get diff between expected > and actual values? Need another filter command? Need to > overriding existing methods? It doesn't conflict with > other extension? And you think that these are addressed better in test/unit? Tell me... where in the files below does colorized output go? How about commandline options? Filtering? % find . -name \*.rb | xargs grep -l Filter ./unit/assertions.rb ./unit/error.rb ./unit/testcase.rb ./unit/util/backtracefilter.rb % find lib/test -name \*.rb | xargs wc -l 14 lib/test/unit/assertionfailederror.rb 622 lib/test/unit/assertions.rb # HERE? 220 lib/test/unit/autorunner.rb 107 lib/test/unit/collector/dir.rb 34 lib/test/unit/collector/objectspace.rb 43 lib/test/unit/collector.rb 56 lib/test/unit/error.rb # HERE? 51 lib/test/unit/failure.rb 160 lib/test/unit/testcase.rb # HERE? 80 lib/test/unit/testresult.rb 76 lib/test/unit/testsuite.rb 127 lib/test/unit/ui/console/testrunner.rb 268 lib/test/unit/ui/fox/testrunner.rb 416 lib/test/unit/ui/gtk/testrunner.rb 465 lib/test/unit/ui/gtk2/testrunner.rb 68 lib/test/unit/ui/testrunnermediator.rb 46 lib/test/unit/ui/testrunnerutilities.rb 260 lib/test/unit/ui/tk/testrunner.rb 40 lib/test/unit/util/backtracefilter.rb # HERE? 90 lib/test/unit/util/observable.rb 48 lib/test/unit/util/procwrapper.rb 280 lib/test/unit.rb 3571 total % find lib/mini -name \*.rb | xargs wc -l 31 lib/mini/mock.rb 82 lib/mini/spec.rb 436 lib/mini/test.rb # ALL HERE 549 total > be simple but tools developed by some advanced users may be > dirty. > > Some or many tests may not worked. It's too uneasy > situation. We usually don't have tests for tests. It took me less than an hour to make things work for rails apps... Mocha and other gems that rely on internal API can simply bypass by requiring test/unit as a gem. They do NOT have to have anything changed for them as they have test/unit available already. > === miniunit just provides minimal features > > miniunit provides some advanced features: mock system and > BDD style syntax. But they just provides limited > functions. e.g. Mini::Mock can't handle multi expects for > the same name. I don't really see how mini/spec is limited. I talked to David Chelimsky at railsconf only feature it is really lacking from rspec is nested contexts. > Most of users prefer to useful system rather than simple > system but limited features because they want to write their > tests simply like Ryan wants miniunit to be simple. again... I'm not seeing this as a problem. miniunit is simple. it also supports nearly every project out there already. For those that require test/unit internals, things are actually cleaner now. They can either require test/unit as a gem, or miniunit... it'll still work on 1.8 and 1.9. > Most of users will use RSpec rather than Mini::Spec if they > want to use BDD style syntax. yup. how is this a problem? This is only 82 lines of overhead. > Most of users will use Mocha or RSpec rather than Mini::Mock > if they want to use a mock system. yup. how is this a problem? This is only 31 lines of overhead. I find it odd that you're calling entire featuresets that test/unit doesn't bother to address at all as "minimal features". miniunit provides a nice middle ground for those who might want to experiment with BDD vs TDD. It'll let them drive both styles side-by-side. It'll let them pick up mocking and if they need more, move to something else. I have converted an m/rspec style project to mini/spec with simple replacements in emacs. This is a feature, not a bug. > Yes, I think that miniunit is very good solution for Ruby > implementation developers because it has very small > dependencies. It doesn't use standard libraries like > OptionParser. But users doesn't require very small > dependencies. They want useful tools rather than very small > dependencies. again... I don't see small as bad. In fact, I don't really see mini/ test as small, so much as I see it as clean. No more junk. No more cruft. No more obfuscation. I've been coding in ruby since 2000. I shouldn't have a problem adding stuff to test/unit but I do. Why? Because it is a mess. Why? It isn't because it provides that much more than mini/unit, that's for sure. I could certainly make miniunit smaller and provide less features/ flexibility... but I went for what felt right: compatibility and usability. > == Benefit > > * Test::Unit's API isn't broken. > * Test::Unit extension libraries are kept working. > * miniunit doesn't need to provide Test::Unit compatible > API. miniunit will be more simple. Yes it does. miniunit has already taken over for rubinius. > * Ryan doesn't need to be burdened. I wasn't burdened. I was terrified. :P > == Problem > > * no dramatic speed up. > * no dramatic simplification. > * not trusted maintainer. * a PITA to extend. > > > > * will not be as simple as miniunit. > * will not be as fast as miniunit. * modified/clean API will still break users (since they're relying on those hacks) and still have the same adoption/learning curve as miniunit... if not worse, since it will always be more code.
on 24.06.2008 03:35
On Jun 19, 2008, at 11:42 , Jeremy Kemper wrote: > I found miniunit more difficult to extend, at first, since it > collapsed some methods that used to be available for override. But I > gave my concerns to Ryan and he refactored to make my job easy again. > So +1 for maintainability. Yeah... and I foresee a few more issues as more people get on board, and most of them will probably be small clean refactorings like what we had to do. > All authors of mocking libraries should try miniunit immediately to > help guide its compatibility and extensibility BEFORE it's merged with > 1.9. I can totally agree with that.
on 24.06.2008 16:56
On Jun 23, 2008, at 9:33 PM, Ryan Davis wrote: >> All authors of mocking libraries should try miniunit immediately to >> help guide its compatibility and extensibility BEFORE it's merged >> with >> 1.9. > > I can totally agree with that. Based on this, I started working with flexmock under miniunit. I have a question with regard to that: Is there a way to detect if a particular test has passed or failed from within the teardown method? Flexmock tries to avoid reporting an error during teardown if the test has already failed. Teardown mock errors are usually of the form "You didn't call this method the number of times you said you would". Failing the test because of that will usually hide the REAL cause of the test failure. TestUnit has a :passed? method on the TestCase object. Replicating that would make it easy, but we have hooks to do something custom as well.
on 13.07.2008 04:03
Hi, I stop to object that Test::Unit is replaced with miniunit. Because nobody objects it except me. It will mean that my opinion doesn't make sense. If Matz says 'go', Test::Unit will be replaced with miniunit. I'll write my opinions in this mail below. I'm happy if my opinions are considered a bit in the future. It's OK for me if they aren't considered. In <6F321A58-07AD-4CD1-90A1-D555991A05AD@zenspider.com> "[ruby-core:17389] Re: Release Plan: Ruby 1.9.0-2" on Tue, 24 Jun 2008 10:21:45 +0900, Ryan Davis <ryand-ruby@zenspider.com> wrote: > > * miniunit isn't extensible. > > false. it is ruby. it is just as extendable as test/unit, if not more, > since it is cleaner. It seems that test/unit isn't easy to extend. So miniunit isn't easy to extend. An example is below. > > extend Test::Unit by overriding existing methods and/or with > time. e.g. active_support/testing/setup_and_teardown.rb: For test/unit: def run_with_callbacks_and_testunit(result) #:nodoc: return if @method_name.to_s == "default_test" yield(Test::Unit::TestCase::STARTED, name) @_result = result begin run_callbacks :setup setup __send__(@method_name) rescue Test::Unit::AssertionFailedError => e add_failure(e.message, e.backtrace) rescue *PASSTHROUGH_EXCEPTIONS raise rescue Exception add_error($!) ensure begin teardown run_callbacks :teardown, :enumerator => :reverse_each rescue Test::Unit::AssertionFailedError => e add_failure(e.message, e.backtrace) rescue *PASSTHROUGH_EXCEPTIONS raise rescue Exception add_error($!) end end result.add_run yield(Test::Unit::TestCase::FINISHED, name) end alias_method :run, :run_with_callbacks_and_testunit For miniunit: def run_with_callbacks_and_miniunit(runner) result = '.' begin run_callbacks :setup result = super rescue Exception => e result = runner.puke(self.class, self.name, e) ensure begin teardown run_callbacks :teardown, :enumerator => :reverse_each rescue Exception => e result = runner.puke(self.class, self.name, e) end end result end alias_method :run, :run_with_callbacks_and_miniunit "ugly hacks" as I said means that overriding existing method with using internal API and aliasing it. Example internal API is add_failure for test/unit case, runner.puke for miniunit. If test/unit and/or miniunit are/is easy to extend, active_support/testing/setup_and_teardown.rb doesn't need to overriding existing run method. > miniunit: > def assert_sorted(actual, message=nil, &block) > expected = actual.sort(&block) > assert_equal expected, actual, "Order is wrong:" > end I couldn't understand why test/unit version is: > def assert_sorted(actual, message=nil, &block) > expected = actual.sort(&block) > message ||= "Expected order:\n#{expected.inspect}\nbut got order:\n#{actual.inspect}\n" > assert_block(message) { expected == actual } > end We can write it same as miniunit version: > def assert_sorted(actual, message=nil, &block) > expected = actual.sort(&block) > assert_equal expected, actual, "Order is wrong:" > end > > I want users to be simple rather than testing framework is > > simple. > > I want both to be simple. These aren't mutually exclusive. I don't think so in many cases. It may be true in some cases. > % find . -name \*.rb | xargs grep -l Filter > 43 lib/test/unit/collector.rb > 46 lib/test/unit/ui/testrunnerutilities.rb > 436 lib/mini/test.rb # ALL HERE > 549 total colorized output: 127 lib/test/unit/ui/console/testrunner.rb # ALL HERE commandline options: 220 lib/test/unit/autorunner.rb # ALL HERE IMHO, putting all features in a large file isn't related to easy to extend. > > === miniunit just provides minimal features > > > > miniunit provides some advanced features: mock system and > > BDD style syntax. But they just provides limited > > functions. e.g. Mini::Mock can't handle multi expects for > > the same name. > > I don't really see how mini/spec is limited. I talked to David > Chelimsky at railsconf only feature it is really lacking from rspec is > nested contexts. I can't find a feature that is corresponding should_receive. IMHO, powerful mock support is the very useful feature in RSpec. And it seems that defining custom must_* method is a bother. Should we use Object.infect_with_assertions? > > Most of users will use RSpec rather than Mini::Spec if they > > want to use BDD style syntax. > > yup. how is this a problem? This is only 82 lines of overhead. > > > Most of users will use Mocha or RSpec rather than Mini::Mock > > if they want to use a mock system. > > yup. how is this a problem? This is only 31 lines of overhead. I want said that: Their only has limited features. So their are not miniunit's benefits. They are needless features in the standard testing framework. They are just simple. > > Yes, I think that miniunit is very good solution for Ruby > > implementation developers because it has very small > > dependencies. It doesn't use standard libraries like > > OptionParser. But users doesn't require very small > > dependencies. They want useful tools rather than very small > > dependencies. > > again... I don't see small as bad. I didn't say that small is bad. I just said that too minimal is bad for users convenience. Thanks,
on 14.07.2008 01:12
On Jul 12, 2008, at 18:59 PM, Kouhei Sutou wrote: > In <6F321A58-07AD-4CD1-90A1-D555991A05AD@zenspider.com> > It seems that test/unit isn't easy to extend. So miniunit > > If test/unit and/or miniunit are/is easy to extend, > active_support/testing/setup_and_teardown.rb doesn't need to > overriding existing run method. I think this is a poor example. The ugly hacks Rails makes for test/unit and miniunit would not be necessary if they would create a Rails::TestCase. This would be very pretty in both test/unit and minunit if they would switch to a subclass and modules to add additional setup and teardown for whatever extras they need. Rails has an unhealthy and unnatural fetish of aliasing methods and replacing them instead of using the more-natural inheritance mechanisms ruby provides. (I believe there would be no difference between miniunit ugly hacks and test/unit ugly hacks using subclassing and modules.) >> Here is a real world (idiomatic) example of test/unit extension vs >> [...] Perhaps the example was too simplistic. I have found making a good, user-friendly custom assertion failure message awkward in test/unit. >> > > commandline options: > 220 lib/test/unit/autorunner.rb # ALL HERE > > IMHO, putting all features in a large file isn't related to > easy to extend. There's 347 lines of output and commandline option handling in test/ unit. That's 80% the line count of miniunit's entire functionality.
on 14.07.2008 05:16
Hi,
In message "Re: [ruby-core:17753] Re: Release Plan: Ruby 1.9.0-2"
on Sun, 13 Jul 2008 10:59:00 +0900, Kouhei Sutou <kou@cozmixng.org>
writes:
|I stop to object that Test::Unit is replaced with miniunit.
|Because nobody objects it except me. It will mean that my
|opinion doesn't make sense. If Matz says 'go', Test::Unit
|will be replaced with miniunit.
|
|I'll write my opinions in this mail below. I'm happy if my
|opinions are considered a bit in the future. It's OK for me
|if they aren't considered.
If I understand you correctly, lack of full compatibility is
the primary reason of your objection to minitest, right?
If so, how do you feel making Test::Unit into a gem, and ask
users who need full compatibility to type:
gem install testunit
once? If no one opposes, you can be a maintainer of the
gem. Or you really feel it's important that Test::Unit to
be bundled with standard distribution?
matz.
on 14.07.2008 18:41
Hi-- my objection to miniunit it mini/spec. a spec library has the potential for being extremely light weight (rspec is over done imho); wrapping a spec interface around a unit test lib is not light weight and is kind of hacky. plus, we should consider the effects of ruby shipping with a standard spec dsl. are we ready to standardize around mini/spec's? i'm not even sure what the syntax is yet since I have found no documentation on it (is there any?). maybe minunit would be better considered once the lib is well documented. T.
on 14.07.2008 22:51
On Jul 13, 2008, at 20:11 , Yukihiro Matsumoto wrote: > If so, how do you feel making Test::Unit into a gem, and ask > users who need full compatibility to type: > > gem install testunit > > once? If no one opposes, you can be a maintainer of the > gem. Or you really feel it's important that Test::Unit to > be bundled with standard distribution? That's already been done. I released 1.0 (cut straight from ruby's SVN) and added Kouhei to the project. Kouhei has already released an expanded 2.0.
on 16.07.2008 03:38
I have to agree, on the documentation side. miniunit is said to be a 'drop-in' replacement for Test::Unit. Having a short description of how exactly to do the replacement would be extremely helpful just for testing out whether it indeed works. We have to consider that Test::Unit, whatever its problems may be, is documented well in various books. If we replace it, we have to think about the documentation side, too. Regards, Martin. At 01:36 08/07/15, Trans wrote: > >T. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
on 16.07.2008 04:24
On Jul 15, 2008, at 01:30 AM, Martin Duerst wrote: > miniunit is said to be a 'drop-in' replacement for Test::Unit. > Having a short description of how exactly to do the replacement > would be extremely helpful just for testing out whether it indeed > works. require 'test/unit' is all you need to do.
on 16.07.2008 04:25
At 02:48 08/07/16, Eric Hodel wrote: >On Jul 15, 2008, at 01:30 AM, Martin Duerst wrote: > >> miniunit is said to be a 'drop-in' replacement for Test::Unit. >> Having a short description of how exactly to do the replacement >> would be extremely helpful just for testing out whether it indeed >> works. > >require 'test/unit' is all you need to do. Hello Eric, Many thanks for trying to help me. But require 'test/unit' is what I use for Test::Unit. So it must be something else, or not? I tried with require 'mini/test' but that didn't work. I think I gleaned that from some of miniunit's own tests, but obviously, something must be wrong. Anyway, even if (or actually, especially if) it turns out that 'drop-in replacement' means just changing a line or two, it is very important that the instructions of how to do that are easily findable. People may bother to do an hour of research for some serious work, but they want to get the instructions for a 'drop-in replacement' without having to search even for a minute. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp