Re: No Native Language Support in browser started from shell prompt

2024-06-17 Thread Dr Bean via Cygwin 
On Sun, 16 Jun 2024, Thomas Wolff via Cygwin wrote:

> 
> Am 14.06.2024 um 09:37 schrieb Dr Bean via Cygwin:
> > With qutebrowser and Microsoft Edge started from a cygwin shell prompt,
> > there is no Native Language Support.
> > 
> > Started from a cmd prompt,
> > 
> > "c:\Program Files\qutebrowser\qutebrowser.exe" 
> > https://ja.wikipedia.org/wiki/%E8%A5%BF%E6%97%A5%E6%9C%AC%E3%81%AE%E5%A4%A7%E5%AD%A6%E4%B8%80%E8%A6%A7
> > 
> > qutebrowser has Chinese and Japanese support.
> > 
> > But in cygwin neither qutebrowser, started with cygstart or
> > as /cygdrive/c/Program\ Files/qutebrowser/qutebrowser
> > https://ja.wikipedia.org/wiki/%E8%A5%BF%E6%97%A5%E6%9C%AC%E3%81%AE%E5%A4%A7%E5%AD%A6%E4%B8%80%E8%A6%A7
> > 
> > nor Microsoft Edge as default browser started with cygstart, enjoy NLS 
> > support.
> That page displays fine for me, after starting /Program Files
> (x86)/Microsoft/Edge/Application/msedge.exe with cygstart. What exactly
> is the symptom of "no Japanese support"?

I spoke too soon. Microsoft Edge doesn't appear to lack NLS support when 
started from a mintty window either with cygstart or the /cygdrive path.

qutebrowser, started from a mintty window with both cygstart and the /cygdrive
path, does lack support.

But when started from a 'cmd' prompt as "c:\Program
Files\qutebrowser\qutebrowser.exe" qutebrowser's NLS support
doesn't differ from Edge's.

The 3 Japanese, Korean and Traditional Chinese MS IME I have on this Japanese
Windows 10 computer have various ways of switching between ASCII (I guess)
keyboard entry and kana, hangul and bopomo entry modes.

The Japanese switch is via the CapsLock key.
The Korean switch is via clicking a task bar toggle next to the IME icon (?) in
the lower right hand corner.  The Traditional Chinese switch is Ctrl-Space

None of these toggle switches are responsive with qutebrowser started from a
mintty window, and I can only input ASCII. (But they are when it's started from
the 'cmd' prompt or desktop.)

The Korean switch has a pop-up message in Japanese saying the switch is
inoperative (or disabled.)

> > Of course the IME are working in the mintty bash shell and 'screen' 
> > sessions.
> > 
> > I don't understand.
> > 

Thanks for your work with mintty.

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

-- 
Greg "Dr Bean" Matheson Some are born autonomous. Some achieve
http://drbean.sdf.org   autonomy. And some have autonomy thrust
drb...@freeshell.orgupon them. --Dr Bean


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

Re: Cygwin outputting message to stderr on dofork EAGAIN failure even when Python exception is caught and handled

2024-06-17 Thread Andrey Repin via Cygwin 
Greetings, Nicholas Williams!

> We have a Python (installed and run through Cygwin) process running on
> Windows Server 2022 that was very, very occasionally failing when 
> subprocess.check_output was called:

> 0 [main] python3 28481 dofork: child -1 - forked process 16856 died
> unexpectedly, retry 0, exit code 0xC142, errno 11
> …
> subprocess.check_output(["cygpath", "-w", directory.name], 
> encoding="utf-8").strip()
> File "/usr/lib/python3.9/subprocess.py", line 424, in check_output <>
>      <>return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, <>
> File "/usr/lib/python3.9/subprocess.py", line 505, in run <>
>      <>with Popen(*popenargs, **kwargs) as process: <>
> File "/usr/lib/python3.9/subprocess.py", line 951, in __init__ <>
>      <>self._execute_child(args, executable, preexec_fn, close_fds, <>
> File "/usr/lib/python3.9/subprocess.py", line 1754, in _execute_child
>     self.pid = _posixsubprocess.fork_exec(
> BlockingIOError: [Errno 11] Resource temporarily unavailable

> Setting aside for a minute the various reasons this might be happening
> occasionally, which we cannot solve for at this moment, the error number
> (EAGAIN) indicates that you should “try again.” So that’s exactly what we
> did. We added a try/catch to the Python code to catch the BlockingIOError
> and, if and only if the error number is EAGAIN, we try up to two more times.
> This fixed the problem and caused the application to stop quitting. We
> output a warning to our log so that we don’t forget about the problem, but
> the warning only ever appears once, so retrying a single time seems to help.

> However … even though Python handles the dofork error, turns it into a
> Python exception, and our code catches the Python exception and handles it
> properly, Cygwin (not Python … Cygwin) still outputs a message to stderr
> right before our warning message. This Cygwin error message shows up as an 
> error in our log tracking:

> 0 [main] python3 15042 dofork: child -1 - forked process 6780 died
> unexpectedly, retry 0, exit code 0xC142, errno 11
> 06/16 13:57:53. 87520: WARNING: Retrying command in 2 seconds due to EAGAIN: 
> [the command we’re running]

> I’m sure there could be any number of things I might be missing, but IMO,
> if the process calling dofork properly handles the error raised by dofork,
> Cygwin should not be outputting an error message to stderr.

> Thoughts?

My inexperienced and uneducated thought would be that forking code is fragile
and some parts of it prone to misbehavior. When an unforeseen error is
detected, it's better to report it sooner, than to get bitten by it later.

Regarding your specific issue, if you create a STC[1] (a minimally enough
version of your code that, say, fork a process thousands of times, which
reliable reproduce the issue) somebody else could run to test the cause, that
would be wonderful.

(If, however, you could find and fix the cause, that would be even more 
wonderful!)

[1] https://www.cygwin.com/acronyms/#STC


-- 
With best regards,
Andrey Repin
Monday, June 17, 2024 10:52:05

Sorry for my terrible english...

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

Re: [Ms-nfs41-client-devel] Cygwin&mingw svn fails on NFS4 share

2024-06-17 Thread Mark Liam Brown via Cygwin 
On Fri, Jun 14, 2024 at 5:19 PM Roland Mainz  wrote:
>
> On Fri, Jun 14, 2024 at 12:14 PM Mark Liam Brown
>  wrote:
> > Cygwin 3.4/3.5&mingw svn fails on a NFS4 share during checkout
> >
> > svn checkout https://svn.FreeBSD.org/base/head/share/man
> > Aman/man4
> > Aman/man4/tcp.4
> > Aman/man4/ndis.4
> > Aman/man4/Makefile
> > Aman/man4/altq.4
> > Aman/man4/miibus.4
> > Aman/man4/vlan.4
> > Aman/man4/ng_macfilter.4
> > Aman/man4/mn.4
> > Aman/man4/ossl.4
> > Aman/man4/ktls.4
> > Aman/man4/ftwd.4
> > Aman/man4/inet6.4
> > Aman/man4/crypto.4
> > Aman/man4/rtsx.4
> > Aman/man4/isp.4
> > svn: E200030: sqlite[S11]: database disk image is malformed
> > svn: E200042: Additional errors:
> > svn: E200030: sqlite[S11]: database disk image is malformed
> > svn: E200030: sqlite[S11]: database disk image is malformed
> > svn: E200030: sqlite[S11]: database disk image is malformed
> >
> > This works on C: (/cygdrive/c).
>
> Could you please try to mount the filesystem with "writethru", e.g. $
> /sbin/nfs_mount -o rw,writethru 'j'
> derfwpc5131_ipv4:/export/home2/rmainz #, and then do a $ svn checkout
> https://svn.FreeBSD.org/base/release/12.2.0/share/man/ # (e.g. testing
> using a FreeBSD stable release branch, so we always have the same
> files being checked out) ?

Yes, mounting the fs with -o rw,writethru fixes svn checkout

Mark
-- 
IT Infrastructure Consultant
Windows, Linux

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

Inevitable India: Transforming Businesses Thru Advance Digital Innovation and IT Solutions.

2024-06-17 Thread Aashutosh Pandey via Cygwin 
Dear Sir/Mam,

 

We are reaching out to you from a new age Global Services Delivery
Organization, Inductus IT, head quartered at National Capital Region
of India, New Delhi.

 

At Inductus IT, we operate through our state of the art, IT & allied
Services Global Capability Centre (GCC) and proud to be associated
with many global conglomerates and corporate organizations of global
repute.

We are ably contributing and supporting our elite & valued Tech firms
& Corporate organizations with; 

Staff AugmentationCustom Software Development Digital Transformation
New-age Tech SolutionsArtificial Intelligence (AI)
Machine Learning (ML)CybersecurityData AnalyticsCloud Solutions

With Real-time Round the Clock Back-end Support Services 

Team Inductus, doesn’t just excel in delivery of tech-based
services; we prioritise subject expertise, efficiency,
cost-effectiveness, set-timelines and collaboration to scale and help
our client organizations to focus upon their core businesses &
activities.

 

As a matter of fact, currently India commands over 50 per cent of the
GCC market with a mix of unique talent and subject matter experts.
Also, globally the country, India continues to be the most preferred
destination for getting the businesses & backend support services,
delivered through the Indian GCCs and the trend is expected to
continue.

 

As per EY, by 2030, India is expected to host 2400 New Global
Capability Centres (GCCs) for various global organizations &
conglomerates.

As an organization, Inductus possess over 17 years of Industry
experience, wherein, we've successfully delivered thousand plus
projects and have saved a staggering ‘over 1 million man hours’ of
precious time & money of our globally reputed & elite clientele.

 

We are keenly looking forward to align & serve you and your revered
organization, with our New-age, Global Standard, Technology Based
Services, through our state of the art Global Capability Centre (GCC)
in New Delhi, India.

We shall be happy to share a presentation, elaborating & detailing our
star rated value added processes & services.

Thanking you in anticipation!!

 

With warm regards, 

Aashutosh Pandey

Technical Officer

Helpline- 9315432692/9234692346

C – 127, Sector – 2, Noida, Delhi NCR – 201301 (INDIA)

Mob: +1 941-491-0454 | Email: h...@inductusgroup.com

 |www.inductusgroup.com 


--Click Here to unsubscribe from this newsletter.


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

Re: Cygwin outputting message to stderr on dofork EAGAIN failure even when Python exception is caught and handled

2024-06-17 Thread Dale Lobb (Sys Admin) via Cygwin 
Greetings, Nicholas;

> From: Cygwin  On Behalf 
> Of Andrey Repin via Cygwin
> Sent: Monday, June 17, 2024 2:58 AM
> To: Nicholas Williams ; cygwin@cygwin.com
> Cc: Andrey Repin 
> Subject: EXTERNAL SENDER: Re: Cygwin outputting message to stderr on dofork 
> EAGAIN failure even when Python exception is caught and handled
>
> Greetings, Nicholas Williams! > We have a Python (installed and run through 
> Cygwin) process running on > Windows Server 2022 that was very, very 
> occasionally failing when subprocess. check_output was called: > 0 [main] 
> python3 28481
> 
> Greetings, Nicholas Williams!
>
> > We have a Python (installed and run through Cygwin) process running on
> > Windows Server 2022 that was very, very occasionally failing when 
> > subprocess.check_output was called:
>
> > 0 [main] python3 28481 dofork: child -1 - forked process 16856 died
> > unexpectedly, retry 0, exit code 0xC142, errno 11
> > …
> > subprocess.check_output(["cygpath", "-w", directory.name], 
> > encoding="utf-8").strip()
> > File "/usr/lib/python3.9/subprocess.py", line 424, in check_output <>
> >  <>return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, <>
> > File "/usr/lib/python3.9/subprocess.py", line 505, in run <>
> >  <>with Popen(*popenargs, **kwargs) as process: <>
> > File "/usr/lib/python3.9/subprocess.py", line 951, in __init__ <>
> >  <>self._execute_child(args, executable, preexec_fn, close_fds, <>
> > File "/usr/lib/python3.9/subprocess.py", line 1754, in _execute_child
> > self.pid = _posixsubprocess.fork_exec(
> > BlockingIOError: [Errno 11] Resource temporarily unavailable
>
> > Setting aside for a minute the various reasons this might be happening
> > occasionally, which we cannot solve for at this moment, the error number
> > (EAGAIN) indicates that you should “try again.” So that’s exactly what we
> > did. We added a try/catch to the Python code to catch the BlockingIOError
> > and, if and only if the error number is EAGAIN, we try up to two more times.
> > This fixed the problem and caused the application to stop quitting. We
> > output a warning to our log so that we don’t forget about the problem, but
> > the warning only ever appears once, so retrying a single time seems to help.
>
> > However … even though Python handles the dofork error, turns it into a
> > Python exception, and our code catches the Python exception and handles it
> > properly, Cygwin (not Python … Cygwin) still outputs a message to stderr
> > right before our warning message. This Cygwin error message shows up as an 
> > error in our log tracking:
>
> > 0 [main] python3 15042 dofork: child -1 - forked process 6780 died
> > unexpectedly, retry 0, exit code 0xC142, errno 11
> > 06/16 13:57:53. 87520: WARNING: Retrying command in 2 seconds due to 
> > EAGAIN: [the command we’re running]
>
> > I’m sure there could be any number of things I might be missing, but IMO,
> > if the process calling dofork properly handles the error raised by dofork,
> > Cygwin should not be outputting an error message to stderr.
>
> > Thoughts?
>
> My inexperienced and uneducated thought would be that forking code is fragile
> and some parts of it prone to misbehavior. When an unforeseen error is
> detected, it's better to report it sooner, than to get bitten by it later.
>
> Regarding your specific issue, if you create a STC[1] (a minimally enough
> version of your code that, say, fork a process thousands of times, which
> reliable reproduce the issue) somebody else could run to test the cause, that
> would be wonderful.
>
> (If, however, you could find and fix the cause, that would be even more 
> wonderful!)
>

  I have seen this exact issue on every Windows  2019 or 2022
server where I have installed new versions of Cygwin since fall of 2023.
Admittedly, that has only been 3 or 4 machines, but it sure seems like
a pattern.  I have resisted upgrading old Cygwin installations for fear
that they also would start to exhibit this fork problem.

https://cygwin.com/pipermail/cygwin/2023-September/254417.html

  The only thing I have found that decreases the frequency of the
errors is to increase the amount of RAM assigned to the machine.
It does not eliminate the issue.  I've tried a ton of different
options with re-basing the Cygwin executables, to no avail.


Best Regards,

Dale






CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipients and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.

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