Re: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal

[Nasser M. Abbasi]

On 6/7/2010 7:03 PM, Charles Wilson wrote:

On 6/7/2010 8:49 PM, Nasser M. Abbasi wrote:


$ make test

   0 [main] perl 5308 C:\cygwin\bin\perl.exe: *** fatal error -
Internal error: TP_NUM_W_BUFS too small.

Error while converting image: No such file or directory

Error: Cannot read 'img2.png': No such file or directory
Converting image #1
   0 [main] perl 4824 C:\cygwin\bin\perl.exe: *** fatal error -
Internal error: TP_NUM_W_BUFS too small.






I wonder if the 'test' procedure for latex2hmtl sets the $PATH to your
installed LaTeX implementation.

Or worse, somehow sets a PERL5_INCPATH variable to point at the
perl/lib/ directory under G:\LATEX\.  If THAT happened, then your
cygwin-perl would be trying to use native-perl's libraries (including
binary extensions)...

Try, temporarily, moving G:/LATEX/perl out of the way.

--
Chuck



Ok, I did. I renamed my windows perl folder, but I still get the same error.

May be someone can try to install Latex2html on their cygwin as I did 
and try this? May be this has nothing to do with windows 64 bit or 
windows 7, so any windows version might show this problem as well?


Installation of l2h is easy on cygwin, just need to download l2h and 
untar and type  ./configure, make, make install, make test


Instructions how to install l2h on cygwin are on my page below:

http://12000.org/my_notes/l2hwin/index.htm

(need to edit one file, to make sure to tell l2h is under Unix)

Not many people use l2h under cygwin, may be I am the first to try to do 
this on cygwin 1.7?


==

$ ls /cygdrive/G/LATEX | grep -i perl
perl_NOT_USED_FOR_MINUTE

$ echo $PATH
/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem

$ which perl
/usr/bin/perl

$ perl -v

This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int
(with 12 registered patches, see perl -V for more detail)

$ make test

Converting image #2
  0 [main] perl 4396 C:\cygwin\bin\perl.exe: *** fatal error - 
Internal error: TP_NUM_W_BUFS too small.


Error while converting image: No such file or directory

Error: Cannot read 'img2.png': No such file or directory
Converting image #1
  0 [main] perl 712 C:\cygwin\bin\perl.exe: *** fatal error - 
Internal error: TP_NUM_W_BUFS too small.


==

--Nasser

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal

[Charles Wilson]

On 6/7/2010 8:49 PM, Nasser M. Abbasi wrote:
> 
> $ make test
> 
>   0 [main] perl 5308 C:\cygwin\bin\perl.exe: *** fatal error -
> Internal error: TP_NUM_W_BUFS too small.
> 
> Error while converting image: No such file or directory
> 
> Error: Cannot read 'img2.png': No such file or directory
> Converting image #1
>   0 [main] perl 4824 C:\cygwin\bin\perl.exe: *** fatal error -
> Internal error: TP_NUM_W_BUFS too small.

I wonder if the 'test' procedure for latex2hmtl sets the $PATH to your
installed LaTeX implementation.

Or worse, somehow sets a PERL5_INCPATH variable to point at the
perl/lib/ directory under G:\LATEX\.  If THAT happened, then your
cygwin-perl would be trying to use native-perl's libraries (including
binary extensions)...

Try, temporarily, moving G:/LATEX/perl out of the way.

--
Chuck

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal

[Nasser M. Abbasi]

On 6/7/2010 2:13 PM, Larry Hall (Cygwin) wrote:



Chris wasn't asking you to try this to see if the cygcheck warnings would
go away.  He was asking you to try this to see if it made any difference
with your original problem.



OK, I just did.  The perl crash is still there.
Please let me know if anything else I can try.


===
$ echo $PATH
/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem

$ ./configure
creating cache ./config.cache
checking for perl... /usr/bin/perl
checking whether #! works in shell scripts... yes
.

$ make
$ make install
/usr/bin/perl config/install.pl
install.pl (Revision 1.12)

Info: Installed /usr/local/share/lib/latex2html/icons/blueball.gif
Info: Installed /usr/local/share/lib/latex2html/icons/blueball.png

mktexlsr: Updating /var/cache/fonts/ls-R...
mktexlsr: Updating /var/lib/texmf/ls-R...
mktexlsr: Done.
Done. Have a lot of fun with LaTeX2HTML!
$

$ make test

  0 [main] perl 5308 C:\cygwin\bin\perl.exe: *** fatal error - 
Internal error: TP_NUM_W_BUFS too small.


Error while converting image: No such file or directory

Error: Cannot read 'img2.png': No such file or directory
Converting image #1
  0 [main] perl 4824 C:\cygwin\bin\perl.exe: *** fatal error - 
Internal error: TP_NUM_W_BUFS too small.

...

===

Also tried with adding sleep(3) as was earlier suggested, and repated 
all the above, same problem.


--Nasser


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim

[Michael Ludwig]

Andy Koppe schrieb am 07.06.2010 um 19:17 (+0100):
> On 7 June 2010 13:44, Michael Ludwig wrote:

> > As you say, Vim works fine with UTF-8. It's just that until very
> > recently, I've been using the rxvt terminal emulator, which lacks
> > Unicode support; so Vim being compiled against ncurses (*without*
> > wide characters) was a good match.
> >
> > Now that I'm switching to the MinTTY terminal, which supports
> > Unicode/UTF-8, I need a Vim compiled against ncursesw (*with*
> > wide characters) if my assessment of the situation is correct.

My assessment was incorrect.

> If vim works fine with UTF-8 already, what does it matter which
> ncurses it's linked against? I don't know vim's internals, but I'd
> guess it works without ncursesw because it does its own screen
> buffering and displaying, using ncurses only for accessing the
> terminfo database.

I don't have much of an idea of what ncurses is actually used for,
nor how Unicode support works in Vim. I simply "assessed" the two
were somehow connected. :-)

The truth is rather trivial and refreshing. My ~/.vimrc contained
some hard-coded configuration for Latin1 on Cygwin (win32unix):

  " MiLu: Cygwin/rxvt kann nur Latin1.
  if has('win32unix')
set termencoding=latin1
  endif

That setting applied on a UTF-8 terminal garbled input, output and
display for non-ASCII characters. After eliminating that it all works
fine. Thanks for not letting my "assessment" pass!

-- 
Michael Ludwig

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Why does /etc/profile include /bin and /usr/bin in the PATH?

[Christopher Faylor]

Maybe this has been discussed and I just don't remember but why are /bin
and /usr/bin included in the default path in /etc/profile?  Since they
point to the same directory that just slows bash down a little when
finding files not in /bin.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal

[Christopher Faylor]

On Mon, Jun 07, 2010 at 01:34:21PM -0700, Nasser M. Abbasi wrote:
>On 6/7/2010 1:15 PM, Christopher Faylor wrote:
>> Rather than express amazement that I raised the issue why not just prove
>> that this doesn't mean anything by simplifying your path and trying
>> again?
>
>I am not expressing amazement, I was asking a simple question, if one 
>can't install windows perl if they have cygwin also.
>
>btw, I did NOT touch the $PATH. This is how it is "out of the box".

So it is.  I'm pretty dense for never noticing this after all of
these years.

>cygwin by default post-append windows PATH to "/usr/bin:/bin:".
>
>In my $HOME/.barc I only add /usr/loca/bin to PATH
>
>
>>I would try just doing something like:
>>
>> c:\>set 
>> PATH=c:\cygwin\bin;c:\windows;c:\windows\system32;c:\windows\system32\Wbem
>> bash$ ...
>>
>
>Ok, I just did, and those warnings are still there:
>
>$ uname -a
>CYGWIN_NT-6.1-WOW64 me-PC 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin
>
>$ echo $PATH
>/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem
>
>$ cygcheck -s -v -r>  cygcheck.out
>/usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32 
>error 5
>Access is denied.
>/usr/bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5
>Access is denied.
>/usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5
>Access is denied.
>/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper': 
>Win32 error 5
>Access is denied.
>/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5
>Access is denied.
>$

As Larry suggests, I wasn't referring to the cygcheck warnings.  I was
referring to your bug report.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal

[Larry Hall (Cygwin)]

On 6/7/2010 4:34 PM, Nasser M. Abbasi wrote:

On 6/7/2010 1:15 PM, Christopher Faylor wrote:

Rather than express amazement that I raised the issue why not just prove
that this doesn't mean anything by simplifying your path and trying
again?


I am not expressing amazement, I was asking a simple question, if one
can't install windows perl if they have cygwin also.


You can.  But if you're having a problem, it makes sense to eliminate the
possible collision, no?


I would try just doing something like:

c:\>set
PATH=c:\cygwin\bin;c:\windows;c:\windows\system32;c:\windows\system32\Wbem

bash$ ...



Ok, I just did, and those warnings are still there:

$ uname -a
CYGWIN_NT-6.1-WOW64 me-PC 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin

$ echo $PATH
/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem


$ cygcheck -s -v -r> cygcheck.out
/usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32
error 5

...

Chris wasn't asking you to try this to see if the cygcheck warnings would
go away.  He was asking you to try this to see if it made any difference
with your original problem.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal

[Nasser M. Abbasi]

On 6/7/2010 1:15 PM, Christopher Faylor wrote:



Rather than express amazement that I raised the issue why not just prove
that this doesn't mean anything by simplifying your path and trying
again?


I am not expressing amazement, I was asking a simple question, if one 
can't install windows perl if they have cygwin also.


btw, I did NOT touch the $PATH. This is how it is "out of the box".

cygwin by default post-append windows PATH to "/usr/bin:/bin:".

In my $HOME/.barc I only add /usr/loca/bin to PATH



I would try just doing something like:

c:\>set 
PATH=c:\cygwin\bin;c:\windows;c:\windows\system32;c:\windows\system32\Wbem
bash$ ...



Ok, I just did, and those warnings are still there:

$ uname -a
CYGWIN_NT-6.1-WOW64 me-PC 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin

$ echo $PATH
/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem

$ cygcheck -s -v -r>  cygcheck.out
/usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32 
error 5

Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper': 
Win32 error 5

Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5
Access is denied.
$

--Nasser




I also meant to mention that you should remove the reference to /usr/bin
since /bin and /usr/bin are the same directory under Cygwin.  This won't
have any effect other than to make things slightly slower but you don't
need to have this in your path.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal

[Christopher Faylor]

On Mon, Jun 07, 2010 at 12:59:51PM -0700, Nasser M. Abbasi wrote:
>On 6/7/2010 12:41 PM, Christopher Faylor wrote:
>> On Mon, Jun 07, 2010 at 11:48:54AM -0700, Nasser M. Abbasi wrote:
>>>
>>> This is a bug report. attached is output of  cygcheck -s -v -r (I get
>>> some access denited warnings btw):
>>>
>>> $ cygcheck -s -v -r>  cygcheck.out
>>> /usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32
>>> error 5
>>> Access is denied.
>>> /usr/bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5
>>> Access is denied.
>>> /usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5
>>> Access is denied.
>>> /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper':
>>> Win32 error 5
>>> Access is denied.
>>> /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5
>>> Access is denied.
>>> $
>>
>
>> This looks suspicious:
>>
>> Warning: C:\cygwin\bin\perl.exe hides G:\LATEX\perl\bin\perl.exe
>>
>> That would indicate that you have two versions of perl on your system.
>
>Yes, I have the windows version of perl (Active Perl 5.1) and cygwin own 
>perl.
>
>What is wrong with this? I need the windows version to be able to use 
>latex2html on windows, since I am not able to use latex2html installed 
>on cygwin.
>
>Can't one install different perl on windows if they have cygwin with its 
>own perl? cygwin perl comes before windows perl.  windows perl is on 
>windows path (defined by using windows, outside cygwin).
>
>$ echo $PATH
>/usr/local/bin:/usr/bin:/bin:/cygdrive/g/LATEX/MiKTeX2.8/miktex/bin:/cygdrive/g/
>LATEX/GnuWin32/bin:/cygdrive/g/LATEX/latex2html/bin:/cygdrive/g/LATEX/perl/bin:/
>cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbe
>m:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/cygdrive/c/Program 
>Files
>  (x86)/ATI Technologies/ATI.ACE/Core-Static:/cygdrive/c/Program Files 
>(x86)/MATL
>AB/R2008b Student/bin:/cygdrive/c/Program Files (x86)/MATLAB/R2008b 
>Student/bin/
>win32:/usr/lib/lapack

Rather than express amazement that I raised the issue why not just prove
that this doesn't mean anything by simplifying your path and trying
again?  I would try just doing something like:

c:\>set 
PATH=c:\cygwin\bin;c:\windows;c:\windows\system32;c:\windows\system32\Wbem
bash$ ...

I also meant to mention that you should remove the reference to /usr/bin
since /bin and /usr/bin are the same directory under Cygwin.  This won't
have any effect other than to make things slightly slower but you don't
need to have this in your path.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal

[Nasser M. Abbasi]

On 6/7/2010 12:41 PM, Christopher Faylor wrote:

On Mon, Jun 07, 2010 at 11:48:54AM -0700, Nasser M. Abbasi wrote:


This is a bug report. attached is output of  cygcheck -s -v -r (I get
some access denited warnings btw):

$ cygcheck -s -v -r>  cygcheck.out
/usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32
error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper':
Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5
Access is denied.
$





This looks suspicious:

Warning: C:\cygwin\bin\perl.exe hides G:\LATEX\perl\bin\perl.exe

That would indicate that you have two versions of perl on your system.

cgf




Yes, I have the windows version of perl (Active Perl 5.1) and cygwin own 
perl.


What is wrong with this? I need the windows version to be able to use 
latex2html on windows, since I am not able to use latex2html installed 
on cygwin.


Can't one install different perl on windows if they have cygwin with its 
own perl? cygwin perl comes before windows perl.  windows perl is on 
windows path (defined by using windows, outside cygwin).


$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/cygdrive/g/LATEX/MiKTeX2.8/miktex/bin:/cygdrive/g/
LATEX/GnuWin32/bin:/cygdrive/g/LATEX/latex2html/bin:/cygdrive/g/LATEX/perl/bin:/
cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbe
m:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/cygdrive/c/Program 
Files
 (x86)/ATI Technologies/ATI.ACE/Core-Static:/cygdrive/c/Program Files 
(x86)/MATL
AB/R2008b Student/bin:/cygdrive/c/Program Files (x86)/MATLAB/R2008b 
Student/bin/

win32:/usr/lib/lapack

m...@me-pc ~
$ which perl
/usr/bin/perl



--Nasser

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal

[Christopher Faylor]

On Mon, Jun 07, 2010 at 11:48:54AM -0700, Nasser M. Abbasi wrote:
>
>This is a bug report. attached is output of  cygcheck -s -v -r (I get 
>some access denited warnings btw):
>
>$ cygcheck -s -v -r> cygcheck.out
>/usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32 
>error 5
>Access is denied.
>/usr/bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5
>Access is denied.
>/usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5
>Access is denied.
>/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper': 
>Win32 error 5
>Access is denied.
>/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5
>Access is denied.
>$

This looks suspicious:

Warning: C:\cygwin\bin\perl.exe hides G:\LATEX\perl\bin\perl.exe

That would indicate that you have two versions of perl on your system.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim

[Andy Koppe]

On 7 June 2010 13:44, Michael Ludwig wrote:
> Andy Koppe schrieb am 07.06.2010 um 12:14:20 (+0100):
>> On 7 June 2010 11:40, Corinna Vinschen wrote:
>
>> > I'll build the next release of vim (there's a 7.3 release coming
>> > soon) against ncursesw.
>>
>> Probably a good idea anyway, but as far as I can see, vim works fine
>> with UTF-8 already.
>
>> Michael, what are the issues you're seeing with vim? Are you using
>> Cygwin 1.7?
>
> As you say, Vim works fine with UTF-8. It's just that until very
> recently, I've been using the rxvt terminal emulator, which lacks
> Unicode support; so Vim being compiled against ncurses (*without*
> wide characters) was a good match.
>
> Now that I'm switching to the MinTTY terminal, which supports
> Unicode/UTF-8, I need a Vim compiled against ncursesw (*with*
> wide characters) if my assessment of the situation is correct.

If vim works fine with UTF-8 already, what does it matter which
ncurses it's linked against? I don't know vim's internals, but I'd
guess it works without ncursesw because it does its own screen
buffering and displaying, using ncurses only for accessing the
terminfo database.

Andy

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Where to report problems with Perl modules

[Reini Urban]

Chloe schrieb:

Where should I report a problem with Perl modules?

bash-3.2$ uname -a
CYGWIN_NT-5.1 dumbopc 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin

cpan[9]>  install Log::Log4perl

t/017Watch.t . 30/30
#   Failed test 'log to externally recreated file'
#   at t/017Watch.t line 343.
#  got: undef
# expected: 'INFO - test3
# '
# Looks like you failed 1 test of 30.
t/017Watch.t . Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/30 subtests

Log-Log4perl-1.28.tar.gz


If it's problem shipped with cygwin perl at cygwin@cygwin.com,

For modules at the module's tracker listed at
http://search.cpan.org/dist/

http://search.cpan.org/dist/Log-Log4perl/ => View/Report Bugs (6)
and mention cygwin as OS.
And you did it right, 
https://rt.cpan.org/Public/Bug/Display.html?id=58188 is yours.


He would probably need a debugging session of
$ perl -d -Mblib t/017Watch.t
at the error.
--
Reini Urban
http://phpwiki.org/  http://murbreak.at/

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ssh error

[Corinna Vinschen]

On Jun  7 07:31, Andrew DeFaria wrote:
> On 06/07/2010 04:59 AM, Corinna Vinschen wrote:On Jun 5 10:21,
> Andrew DeFaria wrote:
> >>I'm surprised nobody has commented on this post as well as my
> >>prior post entitled "ssh problem" back on 5/21. Am I getting
> >>through? Can
> >>somebody at least say "Yes we've seen your post but don't have a
> >>response yet"?
> >I can login to 2K3 just fine. Is that a domain issue, perhaps?
> >http://cygwin.com/faq/faq.using.html#faq.using.sshd-in-domain
> >
> >Corinna
> I will look into this. However I can also log into 2K3 just fine
> also. Re-reading my summary: To summarize with pre-shared key I can
> only ssh with no command from XP -> Windows 2003. All other things
> fail like ssh with a command or scp. Without a pre-shared key,
> everything works.

I'm not sure about your terminology.  With pre-shared key you're talking
about public key authentication, right?  If so, I just tested this again
with Linux and XP Cygwin clients.  From both clients I can ssh with
command as well as scp, connecting with both, admin and non-admin
accounts.  So it's not a generic Cygwin problem afaics.  BLODA, maybe?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ssh error

[Andrew DeFaria]

On 06/07/2010 04:59 AM, Corinna Vinschen wrote:On Jun 5 10:21, Andrew 
DeFaria wrote:
I'm surprised nobody has commented on this post as well as my prior 
post entitled "ssh problem" back on 5/21. Am I getting through? Can
somebody at least say "Yes we've seen your post but don't have a 
response yet"?
I can login to 2K3 just fine. Is that a domain issue, perhaps? 
http://cygwin.com/faq/faq.using.html#faq.using.sshd-in-domain


Corinna
I will look into this. However I can also log into 2K3 just fine also. 
Re-reading my summary: To summarize with pre-shared key I can only ssh 
with no command from XP -> Windows 2003. All other things fail like ssh 
with a command or scp. Without a pre-shared key, everything works.

--
Andrew DeFaria 
Why is there a light in the fridge and not in the freezer?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Creating Cygwin DVD - pmcyg-0.3.1 released

[Christopher Faylor]

On Mon, Jun 07, 2010 at 02:41:03PM +0100, R.Penney wrote:
>Version 0.3.1 of pmcyg, a tool for creating Cygwin installation DVDs,
>has been released. It is available via http://sourceforge.net/projects/pmcyg
>
>pmcyg builds self-contained Cygwin installers, for CD/DVD/USB-flash,
>which can be used to setup PCs without an internet connection.
>pmcyg will take a user-specified list of cygwin packages, and download
>them and all their dependencies together with the setup.exe installer.
>This partial mirror of an official Cygwin release can then be burnt
>onto a DVD/CDROM. pmcyg can be used both via a simple graphical user
>interface, via the command-line, or within scripts.
>
>The latest release includes the following fixes:
>  * improved automatic updating of downloaded package sets
>  * improved management of list of cygwin mirror sites within the GUI

Please note that if people want to discuss this they should use the
resources at the web site.  We don't support this package here.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Creating Cygwin DVD - pmcyg-0.3.1 released

[R.Penney]

Version 0.3.1 of pmcyg, a tool for creating Cygwin installation DVDs,
has been released. It is available via http://sourceforge.net/projects/pmcyg

pmcyg builds self-contained Cygwin installers, for CD/DVD/USB-flash,
which can be used to setup PCs without an internet connection.
pmcyg will take a user-specified list of cygwin packages, and download
them and all their dependencies together with the setup.exe installer.
This partial mirror of an official Cygwin release can then be burnt
onto a DVD/CDROM. pmcyg can be used both via a simple graphical user
interface, via the command-line, or within scripts.

The latest release includes the following fixes:
  * improved automatic updating of downloaded package sets
  * improved management of list of cygwin mirror sites within the GUI

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim

[Michael Ludwig]

Michael Ludwig schrieb am 07.06.2010 um 15:09 (+0200):
> To get the same behaviour as with the Cygwin binary Mutt, some more
> tweaking of configure flags or other stuff seems required. Two
> differences I've noted so far:
> 
> * An error message "repetition-operator operand invalid" appears on
>   startup for "*" instead of ".*" in folder-hook directives.

Avoided by specifying --with-regex for the configure script.

> * My built forgets about mailboxes it has seen so they're all flagged
>   as containing new messages.

Solved by specifying --enable-buffy-size for the configure script.

The Cygwin build has more stuff enabled (which I don't use). My
configure line was:

./configure --prefix=/usr/local/muttw2 --with-regex --enable-buffy-size

The feature and package sets of different builds can be compared by
diffing the output of "mutt -v" and reading the output of "configure
--help".

-- 
Michael Ludwig

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim

[Michael Ludwig]

Michael Ludwig schrieb am 07.06.2010 um 14:28 (+0200):

> As for Mutt, I downloaded the sources via Cygwin setup.exe and
> recompiled against ncursesw. As I couldn't find a suitable configure
> option, I had to edit the Makefile as follows to (1) enable ncursesw
> and (2) skip building the documentation (which would fail):

To get the same behaviour as with the Cygwin binary Mutt, some more
tweaking of configure flags or other stuff seems required. Two
differences I've noted so far:

* An error message "repetition-operator operand invalid" appears on
  startup for "*" instead of ".*" in folder-hook directives.

* My built forgets about mailboxes it has seen so they're all flagged
  as containing new messages.

As I said, it would be fine to have a binary Mutt compiled and linked
against ncursesw with wide character support.

-- 
Michael Ludwig

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim

[Michael Ludwig]

Andy Koppe schrieb am 07.06.2010 um 12:14:20 (+0100):
> On 7 June 2010 11:40, Corinna Vinschen wrote:

> > �I'll build the next release of vim (there's a 7.3 release coming
> > soon) against ncursesw.
> 
> Probably a good idea anyway, but as far as I can see, vim works fine
> with UTF-8 already.

> Michael, what are the issues you're seeing with vim? Are you using
> Cygwin 1.7?

As you say, Vim works fine with UTF-8. It's just that until very
recently, I've been using the rxvt terminal emulator, which lacks
Unicode support; so Vim being compiled against ncurses (*without*
wide characters) was a good match.

Now that I'm switching to the MinTTY terminal, which supports
Unicode/UTF-8, I need a Vim compiled against ncursesw (*with*
wide characters) if my assessment of the situation is correct.

-- 
Michael Ludwig

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim

[Michael Ludwig]

Corinna Vinschen schrieb am 07.06.2010 um 12:40:43 (+0200):
> On Jun  7 11:23, Michael Ludwig wrote:

> > Are ncursesw versions of Vim and Mutt imminent? Or is it not going
> > to happen anytime soon?
> 
> Thanks for the heads up.  I'll build the next release of vim (there's
> a 7.3 release coming soon) against ncursesw.

That's great! Thank you!

As for Mutt, I downloaded the sources via Cygwin setup.exe and
recompiled against ncursesw. As I couldn't find a suitable configure
option, I had to edit the Makefile as follows to (1) enable ncursesw
and (2) skip building the documentation (which would fail):

  \,,,/
  (o o)
--oOOo-(_)-oOOo--
diff Makefile Makefile.orig 
164c164
< CPPFLAGS =  -I/usr/include/ncursesw -I$(top_srcdir)/intl
-I$(includedir)
---
> CPPFLAGS =  -I/usr/include/ncurses -I$(top_srcdir)/intl
> -I$(includedir)
208c208
< MUTTLIBS =  -lncursesw
---
> MUTTLIBS =  -lncurses
283c283
< SUBDIRS = m4 po intl contrib $(IMAP_SUBDIR)
---
> SUBDIRS = m4 po intl doc contrib $(IMAP_SUBDIR)
-

Text in Russian or Greek looks perfect now. Same for Mutt's
internationalized messages in German, Russian, Greek.

Отвечать по cyg...@cygwin.com?
([да]/нет):

(Japanese, Korean and Chinese are another story, possibly on account
of missing fonts.)

Great job, ncursesw! I think just like Vim users, Mutt users would
also appreciate Unicode support.

-- 
Michael Ludwig

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ssh error

[Corinna Vinschen]

On Jun  5 10:21, Andrew DeFaria wrote:
> I'm surprised nobody has commented on this post as well as my prior
> post entitled "ssh problem" back on 5/21. Am I getting through? Can
> somebody at least say "Yes we've seen your post but don't have a
> response yet"?

I can login to 2K3 just fine.  Is that a domain issue, perhaps?
http://cygwin.com/faq/faq.using.html#faq.using.sshd-in-domain


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim

[Andy Koppe]

On 7 June 2010 11:40, Corinna Vinschen wrote:
> On Jun  7 11:23, Michael Ludwig wrote:
>> The wide-character ncursesw was announced in January:
>>
>>   This is the first official release of ncurses compiled to support wide
>>   characters, and can be installed simultaineously with the "narrow"
>>   ncurses package(s).
>>
>> http://www.mail-archive.com/cygwin-annou...@cygwin.com/msg03179.html
>>
>> It sounds like Unicode is the preferred way now:
>>
>>   Actually, I'd prefer if people started using -I/usr/include/ncursesw
>>   and linking against the wide version of the library instead.
>>
>> http://sourceware.org/ml/cygwin/2010-05/msg00465.html
>>
>> People seem to have had success compiling Mutt with ncursesw:
>>
>> http://code.google.com/p/mintty/issues/detail?id=124
>>
>> Are ncursesw versions of Vim and Mutt imminent? Or is it not going to
>> happen anytime soon?
>
> Thanks for the heads up.  I'll build the next release of vim (there's
> a 7.3 release coming soon) against ncursesw.

Probably a good idea anyway, but as far as I can see, vim works fine
with UTF-8 already. It even handles non-BMP codepoints correctly,
which isn't a given due to the UTF-16 wchar_t on Windows and Cygwin.
(Emacs and mined get that right too, whereas for example bash and zsh
don't.)

Michael, what are the issues you're seeing with vim? Are you using Cygwin 1.7?

Mutt and also nano do need rebuilding with ncursesw though.

Andy

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim

[Corinna Vinschen]

On Jun  7 11:23, Michael Ludwig wrote:
> The wide-character ncursesw was announced in January:
> 
>   This is the first official release of ncurses compiled to support wide
>   characters, and can be installed simultaineously with the "narrow"
>   ncurses package(s).
> 
> http://www.mail-archive.com/cygwin-annou...@cygwin.com/msg03179.html
> 
> It sounds like Unicode is the preferred way now:
> 
>   Actually, I'd prefer if people started using -I/usr/include/ncursesw
>   and linking against the wide version of the library instead.
> 
> http://sourceware.org/ml/cygwin/2010-05/msg00465.html
> 
> People seem to have had success compiling Mutt with ncursesw:
> 
> http://code.google.com/p/mintty/issues/detail?id=124
> 
> Are ncursesw versions of Vim and Mutt imminent? Or is it not going to
> happen anytime soon?

Thanks for the heads up.  I'll build the next release of vim (there's
a 7.3 release coming soon) against ncursesw.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim

[Michael Ludwig]

After having used rxvt without Unicode support for years, the other
day I discovered MinTTY, which does support UTF-8 - very nice!

The occasional Greek or Cyrillic letters showing up in mails will no
longer be displayed as "?" or "??" in the Mutt mail reader, I thought.
Same story for editing with Vim.

Not quite, though. There are display and editing problems in both
programs. From reading, I believe this is due to their being linked to
ncurses instead of ncursesw ("w" for "wide characters"), as shown by
ldd:

  $ ldd $(which vim) | grep curses
cygncurses-10.dll => /usr/bin/cygncurses-10.dll (0x6958)
  $ ldd $(which mutt) | grep curses
cygncurses-8.dll => /usr/bin/cygncurses-8.dll (0x6c18)

Is this assessment correct, and complete in that this is the defining
reason for the display problems?

The wide-character ncursesw was announced in January:

  This is the first official release of ncurses compiled to support wide
  characters, and can be installed simultaineously with the "narrow"
  ncurses package(s).

http://www.mail-archive.com/cygwin-annou...@cygwin.com/msg03179.html

It sounds like Unicode is the preferred way now:

  Actually, I'd prefer if people started using -I/usr/include/ncursesw
  and linking against the wide version of the library instead.

http://sourceware.org/ml/cygwin/2010-05/msg00465.html

People seem to have had success compiling Mutt with ncursesw:

http://code.google.com/p/mintty/issues/detail?id=124

Are ncursesw versions of Vim and Mutt imminent? Or is it not going to
happen anytime soon?

-- 
Michael Ludwig

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: getline and getdelim

[Corinna Vinschen]

On Jun  6 08:06, Andy Koppe wrote:
> The getline() and getdelim() functions have become part of the
> standard with POSIX.1-2008. Time to drop the _GNU_SOURCE guard from
> their declarations in ?
> 
> http://www.opengroup.org/onlinepubs/9699919799/functions/getline.html

You're right.  Fixed in CVS.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin Performance and stat()

[Corinna Vinschen]

On Jun  6 19:28, Christopher Faylor wrote:
> On Mon, Jun 07, 2010 at 12:12:36AM +0200, Matthias Andree wrote:
> >Meaning that: even if I'm only a Cygwin user, and I'm sometimes  
> >disappointed by how slow it is, too, I'm sort of convinced there isn't a  
> >cheaper way to get all the required information.
> 
> I'm disappointed in Cygwin's slowness too.  Corinna and I have spent
> many hours pouring over MSDN, internals books, and internals web sites.
> I've spent time looking at ReactOS sources trying to see if they would
> provide any insight into how Windows does things.
> 
> It's possible, maybe even likely, that there are things that could be
> done to speed up Cygwin but I don't think it's likely that they include
> using simple Windows API stuff like the suggested GetFileAttributes() or
> limiting Cygwin's POSIXness.

Full ACK.

>   And, if speed ups do exist, they
> definitely do not require a private audience with me or Corinna.
> 
> The best place to discuss improvements is actually the cygwin-developers
> mailing list.  And, as I said, if you do have a patch to propose, it
> would pay to start early on getting the paperwork done.

Indeed.  It would be rather cool if some interested developer would dive
into this code and maybe just look from a different perspective.  I
don't like the idea to cripple the stat API, though.  There's certainly
room for improvement in other ways while maintaining information
completeness of the stat function.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin Performance and stat()

[Corinna Vinschen]

On Jun  5 08:43, Christopher Wingert wrote:
> So... the person who cared to improve his/her/its code would say,  "Well
> we use NTOpenFile() because it does the blah blah extra functionality that
> FindNextFile()/GetFileAttributes() do not."  Then we could look to other
> Win32 APIs to try to achieve those results.

As you can see in the source code, the Cygwin file access functions are
using the native NT API, rather than the Win32 API.

> For example opening a file on Windows for the purposes of stat()ing a file
> is dumb, considering the way most Windows Virus Scanners work.

That's not correct.  The Win32 functions are implemented in terms of
native NT functions, and the native NT functions have to open the file
to fetch information.  For instance, the function you're using in your
test code, GetFileAttributesEx, is probably actually implemented along
the lines of

  HANDLE h;
  NtOpenFile (&h, "File");
  NtQueryInformationFile (h, ..., FileAllInformation, ...);
  NtClose (h);

Alternatively

  HANDLE h;
  NtOpenFile (&h, "ParentDirectory");
  NtQueryInformationFile (h, ..., FileDirectoryInformation, ...);
  NtClose (h);

Just because the Win32 API doesn't require the application to open
the file doesn't mean it doesn't require it under the hood.

Having said that, there is obviously some reason why Cygwin's stat is
slow.  I'll have a look into it at some point.

What would be really cool would be if somebody could make some real
profiling, so we could get a hunch where to look first. 

For instance, I have a vague feeling that we can raise the performance
by avoiding the long call chain of the stat call

  stat64
stat_worker
  fhandler_disk_file::fstat
fhandler_base::fstat_fs
  fhandler_base::fstat_by_handle
fhandler_base::fstat_helper
  get_file_attribute
get_info_from_sd

given our experience with the call chain of the wctomb sort of
functions.  But that's certainly not the only knob we could play with.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal

[Nasser M. Abbasi]

On 6/7/2010 12:46 AM, Reini Urban wrote:

2010/6/7 Nasser M. Abbasi:

On 6/6/2010 8:32 PM, Reini Urban wrote:


--
Problem reports: http://cygwin.com/problems.html




At the link above you'll see in bold
"Run cygcheck -s -v -r>  cygcheck.out and include cygcheck.out as an
attachment in your report.


Ok. But where to email the actual attachment and the report??  That is 
what I am confused about.  To this mailing list (cygwin@cygwin.com)?




But what I did is document it all here, under the cygwin section
http://12000.org/my_notes/l2hwin/index.htm
Please feel free to use this as the report.






Great.

So it looks like we can make cygwin even more slower,
eh, fix that in perl core for Win64 cygwin only,
to sleep some milliseconds after a fork.
We I need a confirmation because I cannot repro it.



Ok, I changed sleep, kept making it sleep longer and longer, up to 
sleep(100), and the problem still there:


===
 262: my ($self,$cmd,$in,$out,$err) = @_;
 263: carp qq{Debug (syswait): Running "$cmd"\n} if($Verbose);
 265: my $status;
 266: my $child_pid;
 267: if ($child_pid = fork) {
 268:   sleep(100);
# Forked, but do not know how to create a new TTY. #
  Since two debuggers fight for the same TTY, input is severely entangled.

  I know how to switch the output to a different window in xterms, OS/2
  consoles, and Mac OS X Terminal.app only.  For a manual switch, put 
the name

  of the created TTY in $DB::fork_TTY, or define a function
  DB::get_fork_TTY() returning this.

  On UNIX-like systems one can get the name of a TTY for the given window
  by typing tty, and disconnect the shell from TTY by sleep 100.

 275:   unless(exec($cmd)) {
  0 [main] perl 3748 C:\cygwin\bin\perl.exe: *** fatal error - 
Internal error: TP_NUM_W_BUFS too small.

 269:   $status = waitpid($child_pid, 0);
 270:   carp "Debug (syswait): Finished child process: 
#$child_pid\n"

 271: if($Verbose);
 272:   $child_pid = 0;
 273:   return($?);
==



Do you have any process hook application running,
such as an antivir SW listed in BLODA?
http://cygwin.com/faq/faq.using.html#faq.using.bloda



Yes, I have NOD32 Antivirus, 64 bit version running on my PC. Version 
4.2.4, windows 7 home premium 64 bit on intel i7-930.


btw, That list seems to list every anti-virus software out there :)

I'll go turn off nod32 real time protection now for one minute while I 
run the test again to see if it makes a difference



ok, I am back.

Turned off nod32, run the test, and the problem is STILL there.


thanks
--Nasser

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Where to report problems with Perl modules

[Chloe]

Where should I report a problem with Perl modules? 


bash-3.2$ uname -a
CYGWIN_NT-5.1 dumbopc 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin

cpan[9]> install Log::Log4perl

t/017Watch.t . 30/30
#   Failed test 'log to externally recreated file'
#   at t/017Watch.t line 343.
#  got: undef
# expected: 'INFO - test3
# '
# Looks like you failed 1 test of 30.
t/017Watch.t . Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/30 subtests


Log-Log4perl-1.28.tar.gz


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: {glpk,libglpk0,libglpk-devel}-4.44-1

[Marco Atzeri]

Version 4.44-1 of glpk,libglpk0,libglpk-devel
have been uploaded for cygwin.

The GLPK (GNU Linear Programming Kit) package is
intended for solving large-scale linear
programming (LP), mixed integer programming (MIP),
 and other related problems. It is a set of
routines written in ANSI C and organized in
the form of a callable library.

This is a new mainstream release with some routine
improvements and extension to the MathProg language.

For the full changes:
http://lists.gnu.org/archive/html/help-glpk/2010-06/msg5.html

Regards

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.






--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal

[Reini Urban]

2010/6/7 Nasser M. Abbasi :
> On 6/6/2010 8:32 PM, Reini Urban wrote:
>
>>> --
>>> Problem reports: http://cygwin.com/problems.html
>>
>> We haven't got this report, BTW.
>>
>
> Hello Rieni;
>
> I went to make a report, but not able to find where to do that. I went in
> circles looking for a link.

At the link above you'll see in bold
"Run cygcheck -s -v -r > cygcheck.out and include cygcheck.out as an
attachment in your report. Please do not compress or otherwise encode
the output. Just attach it as a straight text file so that it can be
easily viewed."

So that we can you see your environment.

> But what I did is document it all here, under the cygwin section
> http://12000.org/my_notes/l2hwin/index.htm
> Please feel free to use this as the report.

Great.

So it looks like we can make cygwin even more slower,
eh, fix that in perl core for Win64 cygwin only,
to sleep some milliseconds after a fork.
We I need a confirmation because I cannot repro it.

Do you have any process hook application running,
such as an antivir SW listed in BLODA?
http://cygwin.com/faq/faq.using.html#faq.using.bloda

-- 
Reini Urban
http://phpwiki.org/   http://murbreak.at/

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple