Menu
▾
▴
cdw-devel — Mailing list of cdw developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(5) |
Feb
(4) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(48) |
Jun
(26) |
Jul
(85) |
Aug
(16) |
Sep
(4) |
Oct
|
Nov
(27) |
Dec
(47) |
| 2011 |
Jan
(16) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(18) |
Nov
(3) |
Dec
|
| 2012 |
Jan
|
Feb
(10) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
(2) |
| 2014 |
Jan
(10) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Roger <rog...@gm...> - 2011-10-21 07:36:08
|
I'm noticing it's quite awkward to select files and try to decide whether to use ESC or 'q' to quit. The cdw menus and cdw application seem to be diverse as to which key it requires to exit/quit and leave a menu. Personally, I'm for specifying both. Make it easy for the user! ;-) -- Roger http://rogerx.freeshell.org/ |
|
From: Roger <rog...@gm...> - 2011-10-21 06:08:30
|
I can provide a list of packages I've upgraded, unfortunately it'll be about 60+ packages and none of them are immediate depends of cdw, so I don't think this will help much. However, I did go from sys-kernel/gentoo-sources-3.0.4-r2 to sys-kernel/gentoo-sources-3.0.6 on Oct 16 as well. So if you think this bug was memory related, could be a bug in 3.0.4 kernel and fixed in 3.0.6 kernel. <shrugs> -- Roger http://rogerx.freeshell.org/ |
|
From: Roger <rog...@gm...> - 2011-10-21 04:54:26
|
> On Sun, Oct 16, 2011 at 11:48:51PM +0200, Kamil Ignacak wrote: >On 16.10.2011 04:28, Roger wrote: >>> On Sat, Oct 15, 2011 at 02:31:43PM -0800, Roger wrote: >>>> On Sat, Oct 15, 2011 at 10:31:20PM +0200, Kamil Ignacak wrote: >>>> On 15.10.2011 11:54, Roger wrote: >>>>> *** glibc detected *** cdw: double free or corruption (!prev): 0x08893e50 *** >>>>> ======= Backtrace: ========= │ >>>>> /lib/libc.so.6[0x433eb0ef] │ >>>>> /lib/libc.so.6[0x433eca20] │ ││ >>>>> /lib/libc.so.6(cfree+0x6d)[0x433eff6d] ││ ││ >>>>> /usr/lib/libformw.so.5(set_field_buffer+0x1c3)[0x43582b13] >>>>> >>>>> (Most I could legibely copy/paste from the corrupted ncursed display. :-/) >>>>> >>>> Thank you for the report. Could you please let me know three things? >>>> - what system do you use (distro/version)? >>> Gentoo (All source based distro with most current (stable) packages installed.) >>> >>>> - which version of libform do you have installed? >>> /usr/lib/libform.so >>> =sys-libs/ncurses-5.7-r7 (5.7) >>> >>>> - when did this happen? i.e. what were you attempting to do? >>> Think I previously stated, I was trying to Create an Image (from files). >>> >>> Sorry. It took forever for my original post to reach the mailing list and, as I >>> was waiting to follow-up with some version information. :-/ >>> >>> >>> Affected versions of CDW are 0.7.0 and CVS only. Reverting to cdw-0.6.0 >>> doesn't show this problem. >>> >>> I further worked around this further last night, and just skipped creating the >>> image and wrote the cd-r directly from files. >OK, thank you for the details, I will try to look into it after this >weekend. Time to brush up my knowledge of Valgrind... I just tried the latest CVS today and this bug looks gone. Looking at system package compile times, and ncurses here still has a compile time date from months ago. Is this fixed, or did it magically disappear? (My system did have several other package recompiles last Sunday.) -- Roger http://rogerx.freeshell.org/ |
|
From: Kamil I. <ac...@wp...> - 2011-10-16 21:53:53
|
On 16.10.2011 04:28, Roger wrote: >> On Sat, Oct 15, 2011 at 02:31:43PM -0800, Roger wrote: >>> On Sat, Oct 15, 2011 at 10:31:20PM +0200, Kamil Ignacak wrote: >>> On 15.10.2011 11:54, Roger wrote: >>>> *** glibc detected *** cdw: double free or corruption (!prev): 0x08893e50 *** >>>> ======= Backtrace: ========= │ >>>> /lib/libc.so.6[0x433eb0ef] │ >>>> /lib/libc.so.6[0x433eca20] │ ││ >>>> /lib/libc.so.6(cfree+0x6d)[0x433eff6d] ││ ││ >>>> /usr/lib/libformw.so.5(set_field_buffer+0x1c3)[0x43582b13] >>>> >>>> (Most I could legibely copy/paste from the corrupted ncursed display. :-/) >>>> >>> Thank you for the report. Could you please let me know three things? >>> - what system do you use (distro/version)? >> Gentoo (All source based distro with most current (stable) packages installed.) >> >>> - which version of libform do you have installed? >> /usr/lib/libform.so >> =sys-libs/ncurses-5.7-r7 (5.7) >> >>> - when did this happen? i.e. what were you attempting to do? >> Think I previously stated, I was trying to Create an Image (from files). >> >> Sorry. It took forever for my original post to reach the mailing list and, as I >> was waiting to follow-up with some version information. :-/ >> >> >> Affected versions of CDW are 0.7.0 and CVS only. Reverting to cdw-0.6.0 >> doesn't show this problem. >> >> I further worked around this further last night, and just skipped creating the >> image and wrote the cd-r directly from files. OK, thank you for the details, I will try to look into it after this weekend. Time to brush up my knowledge of Valgrind... I'm not sure if I convince myself to installing Gentoo though... I'll do my best :) > > > BTW. CC'd this to your email address and the email got bounced back here. > Strange, my email address seems to be working just fine, but thanks for the information. I will keep an eye for any problems in future. Best regards, Kamil |
|
From: Roger <rog...@gm...> - 2011-10-16 02:28:29
|
> On Sat, Oct 15, 2011 at 02:31:43PM -0800, Roger wrote: >> On Sat, Oct 15, 2011 at 10:31:20PM +0200, Kamil Ignacak wrote: >>On 15.10.2011 11:54, Roger wrote: >>> *** glibc detected *** cdw: double free or corruption (!prev): 0x08893e50 *** >>> ======= Backtrace: ========= │ >>> /lib/libc.so.6[0x433eb0ef] │ >>> /lib/libc.so.6[0x433eca20] │ ││ >>> /lib/libc.so.6(cfree+0x6d)[0x433eff6d] ││ ││ >>> /usr/lib/libformw.so.5(set_field_buffer+0x1c3)[0x43582b13] >>> >>> (Most I could legibely copy/paste from the corrupted ncursed display. :-/) >>> >>Thank you for the report. Could you please let me know three things? >> - what system do you use (distro/version)? >Gentoo (All source based distro with most current (stable) packages installed.) > >> - which version of libform do you have installed? >/usr/lib/libform.so >=sys-libs/ncurses-5.7-r7 (5.7) > >> - when did this happen? i.e. what were you attempting to do? >Think I previously stated, I was trying to Create an Image (from files). > >Sorry. It took forever for my original post to reach the mailing list and, as I >was waiting to follow-up with some version information. :-/ > > >Affected versions of CDW are 0.7.0 and CVS only. Reverting to cdw-0.6.0 >doesn't show this problem. > >I further worked around this further last night, and just skipped creating the >image and wrote the cd-r directly from files. BTW. CC'd this to your email address and the email got bounced back here. -- Roger http://rogerx.freeshell.org/ |
|
From: Roger <rog...@gm...> - 2011-10-15 22:31:52
|
> On Sat, Oct 15, 2011 at 10:31:20PM +0200, Kamil Ignacak wrote: >On 15.10.2011 11:54, Roger wrote: >> *** glibc detected *** cdw: double free or corruption (!prev): 0x08893e50 *** >> ======= Backtrace: ========= │ >> /lib/libc.so.6[0x433eb0ef] │ >> /lib/libc.so.6[0x433eca20] │ ││ >> /lib/libc.so.6(cfree+0x6d)[0x433eff6d] ││ ││ >> /usr/lib/libformw.so.5(set_field_buffer+0x1c3)[0x43582b13] >> >> (Most I could legibely copy/paste from the corrupted ncursed display. :-/) >> >Thank you for the report. Could you please let me know three things? > - what system do you use (distro/version)? Gentoo (All source based distro with most current (stable) packages installed.) > - which version of libform do you have installed? /usr/lib/libform.so =sys-libs/ncurses-5.7-r7 (5.7) > - when did this happen? i.e. what were you attempting to do? Think I previously stated, I was trying to Create an Image (from files). Sorry. It took forever for my original post to reach the mailing list and, as I was waiting to follow-up with some version information. :-/ Affected versions of CDW are 0.7.0 and CVS only. Reverting to cdw-0.6.0 doesn't show this problem. I further worked around this further last night, and just skipped creating the image and wrote the cd-r directly from files. -- Roger http://rogerx.freeshell.org/ |
|
From: Kamil I. <ac...@wp...> - 2011-10-15 20:30:15
|
On 15.10.2011 11:54, Roger wrote: > *** glibc detected *** cdw: double free or corruption (!prev): 0x08893e50 *** > ======= Backtrace: ========= │ > /lib/libc.so.6[0x433eb0ef] │ > /lib/libc.so.6[0x433eca20] │ ││ > /lib/libc.so.6(cfree+0x6d)[0x433eff6d] ││ ││ > /usr/lib/libformw.so.5(set_field_buffer+0x1c3)[0x43582b13] > > (Most I could legibely copy/paste from the corrupted ncursed display. :-/) > Thank you for the report. Could you please let me know three things? - what system do you use (distro/version)? - which version of libform do you have installed? - when did this happen? i.e. what were you attempting to do? Best regards, Kamil |
|
From: Roger <rog...@gm...> - 2011-10-15 13:55:42
|
*** glibc detected *** cdw: double free or corruption (!prev): 0x08893e50 *** ======= Backtrace: ========= │ /lib/libc.so.6[0x433eb0ef] │ /lib/libc.so.6[0x433eca20] │ ││ /lib/libc.so.6(cfree+0x6d)[0x433eff6d] ││ ││ /usr/lib/libformw.so.5(set_field_buffer+0x1c3)[0x43582b13] (Most I could legibely copy/paste from the corrupted ncursed display. :-/) -- Roger http://rogerx.freeshell.org/ |
|
From: Kamil I. <ac...@wp...> - 2011-02-02 17:41:42
|
On 01.02.2011 23:49, Roger wrote: > > Ditto concerning keep cdw.conf& cdw.colors separate. 108 lines in cdw.conf > currently. Anymore lines, and people will start loosing track. Although it > could be merged and doubt anybody would complain. > It should be a bit less than 108 in 0.7.0. I'm thinking about removing some options from config file: - Volume ID - it's different for every disc, no need to store it in config file; - dummy burn/erase - how many people constantly do dummy burns? it will be off by default; - speed range - there are currently two widgets controlling burning speed: "speed" and "speed range"; I understand that "speed range" may have some limited use, but I want to simplify cdw by removing this option altogether; - ask for volume ID - thanks to new wizards this option will become obsolete; There will be probably other changes, but I don't want to look them up. Anyway, the main config file will be shorter, but cdw.conf and cdw.colors will be separate files. Kind regards, Kamil |
|
From: Roger <rog...@gm...> - 2011-02-01 22:49:44
|
>---------------------------------------------------------------------- > >>Comment By: acerion (acerion) >Date: 2011-02-01 21:28 > >Message: >Thank you for this suggestion, I like it. I'm for moving all cdw config >files into ~/.cdw dir, and for keeping .cdw.conf and .cdw.colors separate. >Merging the two files may complicate managing them a bit too much. > >I will try to implement this in 0.7.0, this shouldn't be hard. I like it too. >---------------------------------------------------------------------- > >Comment By: Nobody/Anonymous (nobody) >Date: 2011-01-30 18:54 > >Message: >Alternatively or additionally, ~/.cdw.conf and ~/.cdw.colors could merge >into one configuration file. >Thanks > >---------------------------------------------------------------------- Ditto concerning keep cdw.conf & cdw.colors separate. 108 lines in cdw.conf currently. Anymore lines, and people will start loosing track. Although it could be merged and doubt anybody would complain. -- Roger http://rogerx.freeshell.org/ |
|
From: Roger <rog...@gm...> - 2011-01-22 23:56:11
|
> On Sat, Jan 22, 2011 at 12:08:53PM -0900, Roger wrote: > >This is a funny one. > >I have a CD-R and DVD+R devices (two cd/dvd recording devices) here. > >On finish (write image && check md5sum), I found both trays open. > >Is it just me? > >(Using CVS grabbed within the past few days/week.) oops. my bag. It was a fluke. I must've somehow pressed the eject button sometime. |
|
From: Roger <rog...@gm...> - 2011-01-22 21:09:04
|
This is a funny one. I have a CD-R and DVD+R devices (two cd/dvd recording devices) here. On finish (write image && check md5sum), I found both trays open. Is it just me? (Using CVS grabbed within the past few days/week.) |
|
From: Kamil I. <ac...@wp...> - 2011-01-17 23:15:20
|
On 17.01.2011 06:57, Roger wrote:
> Using a recent CVS snapshot, I just opened up the $HOME/.cdw.log file and
> found it blank before and after CDW execution and found it blank. I then
> ran tail -f and executed CDW and found this:
>
> $ tail -f /home/roger/.cdw.log
> aaaaaaaaaaaaaaaaaaaaaaaaa
I can see this too. I told you that CVS code may be broken :)
Right now I'm guessing that the "aaa" string comes from this function:
cdw_rv_t cdw_logging_check_available_space(). It's expected behavior, I
just didn't think that someone will discover it and treat as a bug :)
But why the log is blank after closing cdw - I don't know yet. This
looks like a real bug.
I'll be able to look into it over the weekend, this week at work will be
a bit busy for me :(
>On the same note of logging:
>
> Here's an idea, why not just debug_file=fopen(HOME/.cdw.log,w) and
> just replace
> fprintf(stderr"OK\n");
>
> with
> fprintf(debug_file,"OK\n");
>
> ?
>
> ... shouldn't the current stuff put into .cdw.log be combined with
> more verbose debugging?
>
> Lot's of options here.
$HOME/.cdw.log is intended rather for regular data that is printed by
cdw or by cdrecord/growisofs/mkisofs during regular work, not for debug
data. I think that it would be wiser to keep these two things ("normal"
information and debug information) separate, in separate files.
If user wants to check what is printed by cdrecord/growisofs/mkisofs,
then he will look into cdw.log file - he may find there e.g. some
information about disc, that is not processed by cdw. Or he may find
there an error message an description printed by mkisofs, that is not
captured by cdw, and interpret it himself.
cdw does print some of its data to the cdw.log file, but its mostly:
- date and time stamps
- commands issued to shell (invocations of
cdrecord/growisofs/mkisofs), so that user can study and inspect them;
Adding cdw debug information ("debug information" as in "low level
information about what went wrong in cdw code") to the same file would
decrease readability of the file.
You may want to print there some high-level debug information, more
readable to regular user (e.g. "cdw encountered error and will close",
or "cdw reports not enough disc space"), but you can already achieve
this with cdw_logging_write().
What's your opinion on this? Am I thinking right?
Kind regards,
Kamil
|
|
From: Roger <rog...@gm...> - 2011-01-17 06:05:23
|
> On Sun, Jan 16, 2011 at 08:57:53PM -0900, Roger wrote: >Using a recent CVS snapshot, I just opened up the $HOME/.cdw.log file and >found it blank before and after CDW execution and found it blank. I then >ran tail -f and executed CDW and found this: > >$ tail -f /home/roger/.cdw.log >aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > > I should also note, after CDW is started and settled down, the following is sent to .cdw.log: aaaaaaaaaaaatail: /home/roger/.cdw.log: file truncated I'm thinking this is were the log file is blanked, and checking the log file after quitting CDW, the log file is blank. |
|
From: Roger <rog...@gm...> - 2011-01-17 05:58:14
|
Using a recent CVS snapshot, I just opened up the $HOME/.cdw.log file and
found it blank before and after CDW execution and found it blank. I then
ran tail -f and executed CDW and found this:
$ tail -f /home/roger/.cdw.log
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
On the same note of logging:
Here's an idea, why not just debug_file=fopen(HOME/.cdw.log,w) and just replace
fprintf(stderr"OK\n");
with fprintf(debug_file,"OK\n");
?
... shouldn't the current stuff put into .cdw.log be combined with more verbose debugging?
Lot's of options here.
--
Roger
http://rogerx.freeshell.org/
|
|
From: Kamil I. <ac...@wp...> - 2011-01-12 21:15:49
|
On 12.01.2011 09:43, Roger wrote: >> Done. It turns out that ncurses provides this nice function >> set_escdelay(), which modifies global variable ESCDELAY. This ESCDELAY >> global variable exists in addition to shell variable ESCDELAY. Using the >> function cdw sets the delay to 50 milliseconds. User can override this >> using "--escdelay=X" command line argument. I don't think that this >> argument will be used to make the delay even smaller (50 ms seems to be >> unnoticeable), but to decrease it for slow terminals. >> >> Code with the changes described above are in CVS HEAD. > > I tested the -escdelay= with 600,1000,2000 values and works here. I wasn't > sure if ESCDELAY was redefined here to a smaller value, I don't think so > because bash completion on $ESC isn't showing anything defined for this var. > I think that set_escdelay() modifies variable exported by ncurses library (i.e. made visible to code using ncurses). I'm not very familiar with the trick, but this definitely is something else than shell variable. Kind regards, Kamil |
|
From: Roger <rog...@gm...> - 2011-01-12 08:43:37
|
On Sun, Jan 09, 2011 at 03:13:07PM +0100, Kamil Ignacak wrote: >On 06.01.2011 14:13, Kamil Ignacak wrote: >> This leaves me with the only viable solution: modify delay >> programmatically. I will investigate this in few next days. > >Done. It turns out that ncurses provides this nice function >set_escdelay(), which modifies global variable ESCDELAY. This ESCDELAY >global variable exists in addition to shell variable ESCDELAY. Using the >function cdw sets the delay to 50 milliseconds. User can override this >using "--escdelay=X" command line argument. I don't think that this >argument will be used to make the delay even smaller (50 ms seems to be >unnoticeable), but to decrease it for slow terminals. > >Code with the changes described above are in CVS HEAD. I tested the -escdelay= with 600,1000,2000 values and works here. I wasn't sure if ESCDELAY was redefined here to a smaller value, I don't think so because bash completion on $ESC isn't showing anything defined for this var. -- Roger http://rogerx.freeshell.org/ |
|
From: Kamil I. <ac...@wp...> - 2011-01-09 14:15:50
|
On 06.01.2011 14:13, Kamil Ignacak wrote: > This leaves me with the only viable solution: modify delay > programmatically. I will investigate this in few next days. Done. It turns out that ncurses provides this nice function set_escdelay(), which modifies global variable ESCDELAY. This ESCDELAY global variable exists in addition to shell variable ESCDELAY. Using the function cdw sets the delay to 50 milliseconds. User can override this using "--escdelay=X" command line argument. I don't think that this argument will be used to make the delay even smaller (50 ms seems to be unnoticeable), but to decrease it for slow terminals. Code with the changes described above are in CVS HEAD. Kind regards, Kamil |
|
From: Kamil I. <ac...@wp...> - 2011-01-08 21:50:12
|
On 12.07.2010 09:03, cdw...@li... wrote: > Dnia 12-07-2010 o godz. 0:11 cdw...@li... napisał(a): >> 1) My current size of media stated at the bottom does not update to the CD >> media in the drive after pressing 'R'. Although 'R' updates the far >> bottom >> left info window, the one next to it still remains at the size of a DVD >> media >> and never updates. >> >> This window is "Approximate size of selected files:" >> 0.0/8152 MB in 0 items, 8152 MB free >> >> The configuration: >> Maximal ISO volume size = Generic DVD (4.7 GB) >> Custom ISO Size = 8152 >> >> Or, should there be an "Auto (size)" option within the menu? >> "Maximal" is kind of vague term isn't it? Do you mean, "Maximum ISO >> volume >> size"? > > You would see current size of media updated in bottom right area of UI > only if "Auto" option was selected in Configuration window -> Log and > other -> Maximal ISO volume size. "Auto" option is in the code, but it > is disabled by default. Even if it was enabled, it wouldn't work, > because currently there is no code (yet) that would check disc type, > look up disc size, and update information in UI. But the fact that there > is "Auto" in the code hints that there are plans to make it work in one > of future releases :) > > So currently you can only see maximum ISO volume size which was > configured in configuration window, but the value isn't automatically > updated. Today's commit to CVS adds this "Auto" option: every time you refresh disc information, and the option is enabled, cdw displays correct disc capacity in the bottom-right area. There are some limitations to this "every time": - wodim (cdrecord fork) can't recognize DVDs capacity, so this doesn't work for DVD+wodim combination; - even though the disc information is auto-refreshed during and after erasing a disc, the information in bottom-right area isn't automatically updated. This is just a matter of simple change in code, so this will be fixed soon. Kind regards, Kamil |
|
From: Kamil I. <ac...@wp...> - 2011-01-06 13:16:07
|
On 03.01.2011 23:52, Roger wrote: >> Global mapping of the 'q' key will most probably cause closing >> Configuration window every time user enters 'q' letter into text field. >> It's not a behavior that user expects :) > > I didn't realize this. However, I would believe NCurses should recognize when > a key is pressed within a text field, and when it's just pressed. I've tried to map 'q' key to ESC in cdw, but it's not that simple, or it can't be done, or I can't figure how to do this :( There is one more problem with idea of mapping 'q' to ESC: delay. If it turns out that it's impossible to get rid of delay between pressing ESC key and reaction by cdw/ncurses, then the delay will occur when pressing 'q' key as well. And since the delay is a bad thing, then the mapping wouldn't make too much sense. We have to get rid of the delay first. So for now I'm abandoning the idea of globally mapping 'q' to ESC, and I will explicitly add 'q' key to widgets instead. >> What I will/what I am doing instead: I'm adding 'q'/'Q' key in functions >> handling key events in specific widgets e.g. in write wizard (the >> functions are called "drivers"). >> >> About redefining value of ESCDELAY: there is a reason why the delay >> exists in the first place, and why it's so long (1 second, I think). The >> reason is explained in these two posts (the second one hints at network >> delays): >> http://lists.gnu.org/archive/html/bug-ncurses/2004-05/msg00025.html >> http://lists.gnu.org/archive/html/bug-ncurses/2004-05/msg00028.html >> This is an additional reason for which I would like to avoid redefining >> ESCDELAY value, and leave it to the user. > > This delay is not used within many programs such as VI/VIM. Other programs, > such as Irssi, don't use it. > > The reason for the delay that they're talking within the above links is, when > somebody might use a screen multiplexer (or other terminal based app) that > uses the ESC key as an escape char. I suspect that other programs are smarter than cdw. ESC key (or rather a byte corresponding to ESC) may be used as first part of more complicated key sequences - multi-byte sequences. I suspect that other applications set a delay to zero (or bypass this problem of delay in some other way), read stream from keyboard byte by byte, and interpret byte sequences on their own. This is definitely not my level. > Really, I think the main solution is just avoiding using the ESC key, but when > things were first programed, it likely wasn't on their mind at the time. The ESC delay never bothered me much, but I understand that this may be a problem for users. Possible solutions I can see now are: - modify ESCDELAY shell variable: but I want to avoid messing with shell variables if possible - modify delay programmatically: I would like this more than solution 1 - implement my own byte reader/interpreter: no way :) This leaves me with the only viable solution: modify delay programmatically. I will investigate this in few next days. Kind regards, Kamil |
|
From: Roger <rog...@gm...> - 2011-01-03 22:53:09
|
On Mon, Jan 03, 2011 at 10:45:38PM +0100, Kamil Ignacak wrote:
>On 26.12.2010 02:53, Roger wrote:
>> On Sat, Dec 25, 2010 at 04:48:11PM -0900, Roger wrote:
>>> if (getenv ("ESCDELAY") == NULL)
>>> ESCDELAY = 25;
>>
>> Also, wouldn't it be keen to also map the "q" key to the ESC key?
>>
>> ie... just guessing:
>>
>> DEFINE "ESC" "q"
>>
>> It's kind of funny to have to press ESC to escape/quit the add/delete file
>> window, but require "q" to quit CDW.
>>
>About mapping 'q' to 'ESC' globally: this won't be done, as I'm afraid
>that this might cause more trouble than it's worth. Example: currently
>Configuration window can be closes with ESC key, but the same
>Configuration window has text input fields, in which user can enter 'q'
>key. Global mapping of the 'q' key will most probably cause closing
>Configuration window every time user enters 'q' letter into text field.
>It's not a behavior that user expects :)
I didn't realize this. However, I would believe NCurses should recognize when
a key is pressed within a text field, and when it's just pressed.
>What I will/what I am doing instead: I'm adding 'q'/'Q' key in functions
>handling key events in specific widgets e.g. in write wizard (the
>functions are called "drivers").
>
>About redefining value of ESCDELAY: there is a reason why the delay
>exists in the first place, and why it's so long (1 second, I think). The
>reason is explained in these two posts (the second one hints at network
>delays):
>http://lists.gnu.org/archive/html/bug-ncurses/2004-05/msg00025.html
>http://lists.gnu.org/archive/html/bug-ncurses/2004-05/msg00028.html
>This is an additional reason for which I would like to avoid redefining
>ESCDELAY value, and leave it to the user.
This delay is not used within many programs such as VI/VIM. Other programs,
such as Irssi, don't use it.
The reason for the delay that they're talking within the above links is, when
somebody might use a screen multiplexer (or other terminal based app) that
uses the ESC key as an escape char.
Really, I think the main solution is just avoiding using the ESC key, but when
things were first programed, it likely wasn't on their mind at the time.
When I get some time, I'll post a question to the NCurses mailing list as I'm
already subscribed to it.
--
Roger
http://rogerx.freeshell.org/
|
|
From: Kamil I. <ac...@wp...> - 2011-01-03 21:48:14
|
On 26.12.2010 02:53, Roger wrote:
> On Sat, Dec 25, 2010 at 04:48:11PM -0900, Roger wrote:
>> if (getenv ("ESCDELAY") == NULL)
>> ESCDELAY = 25;
>
> Also, wouldn't it be keen to also map the "q" key to the ESC key?
>
> ie... just guessing:
>
> DEFINE "ESC" "q"
>
> It's kind of funny to have to press ESC to escape/quit the add/delete file
> window, but require "q" to quit CDW.
>
About mapping 'q' to 'ESC' globally: this won't be done, as I'm afraid
that this might cause more trouble than it's worth. Example: currently
Configuration window can be closes with ESC key, but the same
Configuration window has text input fields, in which user can enter 'q'
key. Global mapping of the 'q' key will most probably cause closing
Configuration window every time user enters 'q' letter into text field.
It's not a behavior that user expects :)
What I will/what I am doing instead: I'm adding 'q'/'Q' key in functions
handling key events in specific widgets e.g. in write wizard (the
functions are called "drivers").
About redefining value of ESCDELAY: there is a reason why the delay
exists in the first place, and why it's so long (1 second, I think). The
reason is explained in these two posts (the second one hints at network
delays):
http://lists.gnu.org/archive/html/bug-ncurses/2004-05/msg00025.html
http://lists.gnu.org/archive/html/bug-ncurses/2004-05/msg00028.html
This is an additional reason for which I would like to avoid redefining
ESCDELAY value, and leave it to the user.
Kind regards,
Kamil
|
|
From: Kamil I. <ac...@wp...> - 2011-01-02 12:43:35
|
On 02.01.2011 06:27, Roger wrote: > Just tested with DVD+R/RW media, and then a CD-RW media and the dummy option > only presented itself with the CD-RW media inserted. I did a closer inspection of source code for growisofs and cdrecord. I haven't noticed a clear definition of which discs support "dummy" option and which don't, but I have inferred that DVD+R/RW don't support it (when writing with both cdrecord and growisofs). You will see the option in much less cases than so far. > The additional 'q' for quit is a blessing. But the 'q' (for quit) isn't > available within the pop-up windows. (ie. pop-up window just prior to writing) It will take some time before I will implement it. It may be possible to map 'q' to 'ESC' globally, I haven't checked this yet. If not, then I will do this for every window separately. > Things are looking really good here. Finding I'm really starting to enjoy > writing to CD/DVD media. I'm glad to hear this :) Kind regards, Kamil |
|
From: Roger <rog...@gm...> - 2011-01-02 05:27:33
|
On Thu, Dec 30, 2010 at 09:15:49PM +0100, Kamil Ignacak wrote: >On 30.12.2010 00:14, Roger wrote: >> On Wed, Dec 29, 2010 at 11:41:16PM +0100, Kamil Ignacak wrote: >>> Now the algorithm looks like this: >>> >>> burn >>> eject tray >> >> At this point, instead of ejecting and then closing for verification, isn't >> there a call to the CD libs to just recheck disc info rather then doing a >> complete tray eject routine? >But the CD libs will have to use OS calls, or use information provided >by drive's firmware. In both cases the information may be out of date, >because the disc has been written to, but the disc has not been reloaded. > >Reloading tray before verification is required - withouth that cdw might >be unable to get current, real inforamtion about a disc. Just tested with DVD+R/RW media, and then a CD-RW media and the dummy option only presented itself with the CD-RW media inserted. The additional 'q' for quit is a blessing. But the 'q' (for quit) isn't available within the pop-up windows. (ie. pop-up window just prior to writing) Things are looking really good here. Finding I'm really starting to enjoy writing to CD/DVD media. -- Roger http://rogerx.freeshell.org/ |
|
From: Roger <rog...@gm...> - 2011-01-01 00:53:02
|
On Fri, Dec 31, 2010 at 05:34:31PM +0100, Kamil Ignacak wrote: >On 26.12.2010 02:48, Roger wrote: >> Just found a work around via Google with "ncurses ESC delay". >> >> export ESCDELAY=25 >> >> (25ms) >> >> (I've *never* had to do this shell variable export with any other ncurses >> based application. Never!) >> >> >> There's this solution as well as C code at the following url: >> http://en.chys.info/2009/09/esdelay-ncurses/ >> >> if (getenv ("ESCDELAY") == NULL) >> ESCDELAY = 25; >> >The code that configures ncurses usage in cdw was coded/reviewed by me >long time ago. I didn't get all things right then, the Esc delay is one >of signs of this. Perhaps I didn't read the documentation properly, or >maybe there was some bug in ncurses at that time, and, hunting for >solution, I have messed things even more. >I will revisit the code again, read the documentation again and try to >fix this in C code. I would like to avoid setting shell variables to fix >the issue, as there is always this problem with altering and then proper >restoring user's environment - this is a problem at least for me. Fixing >this in C code of cdw seems to be a "cleaner" solution. > >In other words: I will check the ncurses configuration code and try to >get it right. You're correct about redefining environmental variables. I even grepped the vim/vim-core sources for ESCDELAY and found none. Even grepping "esc delay" returned pretty much null. So they're using something else. Another likely place to get tips on ESC delay is emacs or vim IRC/mailing list. |