Re: /dev/clipboard sometimes fails to set CF_UNICODETEXT data.
Hi Takashi,
Takashi Yano wrote:
Hello,
In one of my PCs,
dd if=/dev/urandom count=10 | xxd > /dev/clipboard
sometimes fails to set CF_UNICODETEXT data.
As a result, pasting clipboard to notepad does not work.
Even in the case, cygnativeformat data is set correctly.
So, "cat /dev/clipboard" works.
This problem depends on machine very much.
My one PC with Xeon E3-1281 v3 CPU has a high probability of failure,
however, another machine with Core i7-6700K CPU does not.
I looked into this problem, and found OpenClipboard() for
CF_UNICODETEXT fails. It seems that OpenClipboard() just
after CloseClipboard() has high probability of failure.
You can see the following test case immediately stops with error.
Even with Core i7-6700K CPU machine above, the test case fails.
#include
#include
int main()
{
for (;;) {
if (!OpenClipboard(0)) {
printf("Open error.\n");
break;
}
if (!EmptyClipboard()) {
printf("Empty error.\n");
break;
}
if (!CloseClipboard()) {
printf("Cloes error.\n");
break;
}
}
return 0;
}
I also found the patch attached solves the issue.
I would appreciate any suggestion.
Would be neet if this patch wasn't needed, but, oh well. My only comment on the
patch would be to possibly call the new wrapper function MyOpenClipboard, or
CygOpenClipboard, to help keep the name paired with CloseClipboard.
I suppose it might happen in the future that a faster processor will require the
loop count to be made larger. Once again, oh well.
My 2c (adjusted for inflation),
..mark
--
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: /dev/clipboard sometimes fails to set CF_UNICODETEXT data.
On Tue, 5 Jul 2022 00:42:50 -0700
Mark Geisert wrote:
> Hi Takashi,
>
> Takashi Yano wrote:
> > Hello,
> >
> > In one of my PCs,
> > dd if=/dev/urandom count=10 | xxd > /dev/clipboard
> > sometimes fails to set CF_UNICODETEXT data.
> > As a result, pasting clipboard to notepad does not work.
> >
> > Even in the case, cygnativeformat data is set correctly.
> > So, "cat /dev/clipboard" works.
> >
> > This problem depends on machine very much.
> >
> > My one PC with Xeon E3-1281 v3 CPU has a high probability of failure,
> > however, another machine with Core i7-6700K CPU does not.
> >
> > I looked into this problem, and found OpenClipboard() for
> > CF_UNICODETEXT fails. It seems that OpenClipboard() just
> > after CloseClipboard() has high probability of failure.
> >
> > You can see the following test case immediately stops with error.
> > Even with Core i7-6700K CPU machine above, the test case fails.
Additional information:
In the machine with Xeon E3-1281 v3 CPU, the test case fails
in a several times of the loop, while it fails after 1000 to
3000 times of the loop in the machine with Core i7-6700K CPU.
The probability of failure depends much on machine.
> > #include
> > #include
> >
> > int main()
> > {
> > for (;;) {
> > if (!OpenClipboard(0)) {
> > printf("Open error.\n");
> > break;
> > }
> > if (!EmptyClipboard()) {
> > printf("Empty error.\n");
> > break;
> > }
> > if (!CloseClipboard()) {
> > printf("Cloes error.\n");
> > break;
> > }
> > }
> > return 0;
> > }
> >
> > I also found the patch attached solves the issue.
> >
> > I would appreciate any suggestion.
>
> Would be neet if this patch wasn't needed, but, oh well. My only comment on
> the
> patch would be to possibly call the new wrapper function MyOpenClipboard, or
> CygOpenClipboard, to help keep the name paired with CloseClipboard.
Thanks for the comment. IIUC, the camel case name should be
used only for Win32 APIs related. However, this is the wrapper
for Win32 API. So, it might be acceptable. In other places,
some wrapper functions are named as camel case.
Corinna, WDYT?
> I suppose it might happen in the future that a faster processor will require
> the
> loop count to be made larger. Once again, oh well.
Maybe. In my most cases, OpenClipboard() successes after one
or two times of retrying. So, I think max_retry = 10 is enough
for the time being.
> My 2c (adjusted for inflation),
--
Takashi Yano
--
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: VS Code is missing a few characters when running launch task in Git Bash
On Tue, Jul 5, 2022 at 6:18 AM Takashi Yano wrote:
>
> On Mon, 4 Jul 2022 08:57:09 +0300
> Orgad Shaneh wrote:
> > Sure,
> >
> > Install VS Code and Node.JS.
> >
> > Clone this repository: https://github.com/orgads/cygtest
> >
> > Open the directory in VS Code and run (F5). Wait for it to finish,
> > then run again.
> >
> > I've noticed that even the first execution has some mistyped
> > characters (moved from ** to ##):
> >
> > waitForDeb**u**gge**r**
> > "exe**c**Path":"C:\\Program Fil**es**\\nodejs\\node.exe"
> > "autoAttachMod##urces##e":"always"
> >
> > And on the second run:
> > "inspecto**r**Ipc":".\\pipe\\node-cdp.9412-8.sock","##r##deferredMode":false
> >
> > $ /usr/bin/env 'NODE_OPTIONS=--require
> > "c:/Users/orgads/AppData/Local/Programs/Microsoft VS
> > Code/resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js"
> > --inspect-publish-uid=http'
> > 'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":".\\pipe\\node-cdp.9412-7.sock","deferredMode":false,"waitForDebgge":"","exePath":"C:\\Program
> > Fil\\nodejs\\node.exe","onlyEntrypoint":false,"autoAttachModurcese":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-c57206c2f20dca1d"}'
> > C:\\Program\ Files\\nodejs\\node.exe index.js
> > hi
> >
> > $ cd f:\\Projects\\cygtest ; /usr/bin/env 'NODE_OPTIONS=--require
> > "c:/Users/orgads/AppData/Local/Programs/Microsoft VS
> > Code/resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js"
> > --inspect-publish-uid=http'
> > 'VSCODE_INSPECTOR_OPTIONS={"inspectoIpc":".\\pipe\\node-cdp.9412-8.sock","rdeferredMode":false,"waitForDebugger":"","execPath":"C:\\Program
> > Files\\nodejs\\node.exe","onlyEntrypoint":false,"autoAttachMode":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-fab5a0d7b63917c7"}'
> > C:\\Program\ Files\\nodejs\\node.exe index.js
> > hi
>
> Thanks.
>
> Could you please test if the commit
> https://www.cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=521dfff143f9533533d161f37b73a92147c88e7c
> fixes the issue?
Yes, finally! Thank you very much! :)
You can test with the binary from here:
https://github.com/msys2/msys2-runtime/pull/96/checks
- Orgad
--
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: /dev/clipboard sometimes fails to set CF_UNICODETEXT data.
On Jul 5 17:40, Takashi Yano wrote: > On Tue, 5 Jul 2022 00:42:50 -0700 > Mark Geisert wrote: > > Takashi Yano wrote: > > > I also found the patch attached solves the issue. > > > > > > I would appreciate any suggestion. > > > > Would be neet if this patch wasn't needed, but, oh well. My only comment > > on the > > patch would be to possibly call the new wrapper function MyOpenClipboard, > > or > > CygOpenClipboard, to help keep the name paired with CloseClipboard. > > Thanks for the comment. IIUC, the camel case name should be > used only for Win32 APIs related. However, this is the wrapper > for Win32 API. So, it might be acceptable. In other places, > some wrapper functions are named as camel case. > > Corinna, WDYT? What about just adding a static inline wrapper called close_clipboard for symmetry? Corinna -- 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
[ANNOUNCEMENT] fish 3.5.0-1
fish 3.5.0-1 is now available in Cygwin. This release has many small improvements and bug fixes since the previous Cygwin release, 3.4.1-1. See the upstream release notes[1] for a list. fish is the friendly interactive shell. It's a Unix shell that focuses on interactive use, discoverability, and user friendliness. The design goal of fish is to give the user a rich set of powerful features in a way that is easy to discover, remember, and use. Home page: https://fishshell.com Andrew E. Schulman [1] https://fishshell.com/docs/current/relnotes.html *** To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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.com_at_cygwin.com If you need more information on unsubscribing, start reading here: http://cygwin.com/lists.html#subscribe-unsubscribe Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: [ANNOUNCEMENT] fish 3.5.0-1
Andrew Schulman via Cygwin-announce wrote: fish 3.5.0-1 is now available in Cygwin. This release has many small improvements and bug fixes since the previous Cygwin release, 3.4.1-1. See the upstream release notes[1] for a list. Please note this minor permission issue which may affect installations for "All Users" (easy to fix locally, of course): https://sourceware.org/pipermail/cygwin/2022-July/251802.html -- Regards, Christian -- 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
Typo in ?
Hi, There's some inconsistency between and : sys/select.h has this: --- /* * Select uses bit masks of file descriptors in longs. * These macros manipulate such bit fields (the filesystem macros use chars). * FD_SETSIZE may be defined by the user, but the default here * should be >= NOFILE (param.h). */ #ifndef FD_SETSIZE #define FD_SETSIZE 64 #endif -- Now, this is the relevant part of sys/param.h looks like this: -- /* Max number of open files. The Posix version is OPEN_MAX. */ /* Number of fds is virtually unlimited in cygwin, but we must provide some reasonable value for Posix conformance */ #define NOFILE 8192 -- So it's either "<= NOFILE" that was actually meant to be there in the comment (or, an equivalent "should NOT be > NOFILE"), or FD_SETSIZE should have been defined as 8192, if the comment is actually correct. Or maybe I'm missing something here :-) I understand that if I redefined FD_SETSIZE in my code before including , it'd work with whatever large (or small) fd_set I need, but that's not what I'm after. Anton Lavrentiev Contractor NIH/NLM/NCBI -- 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: /dev/clipboard sometimes fails to set CF_UNICODETEXT data.
Greetings, Takashi Yano!
> On Tue, 5 Jul 2022 00:42:50 -0700
> Mark Geisert wrote:
>> Hi Takashi,
>>
>> Takashi Yano wrote:
>> > Hello,
>> >
>> > In one of my PCs,
>> > dd if=/dev/urandom count=10 | xxd > /dev/clipboard
>> > sometimes fails to set CF_UNICODETEXT data.
>> > As a result, pasting clipboard to notepad does not work.
>> >
>> > Even in the case, cygnativeformat data is set correctly.
>> > So, "cat /dev/clipboard" works.
>> >
>> > This problem depends on machine very much.
>> >
>> > My one PC with Xeon E3-1281 v3 CPU has a high probability of failure,
>> > however, another machine with Core i7-6700K CPU does not.
>> >
>> > I looked into this problem, and found OpenClipboard() for
>> > CF_UNICODETEXT fails. It seems that OpenClipboard() just
>> > after CloseClipboard() has high probability of failure.
>> >
>> > You can see the following test case immediately stops with error.
>> > Even with Core i7-6700K CPU machine above, the test case fails.
> Additional information:
> In the machine with Xeon E3-1281 v3 CPU, the test case fails
> in a several times of the loop, while it fails after 1000 to
> 3000 times of the loop in the machine with Core i7-6700K CPU.
> The probability of failure depends much on machine.
MFG… this might as well explain the issues OpenOffice having with clipboard
content. I'll forward your findings.
>> > #include
>> > #include
>> >
>> > int main()
>> > {
>> > for (;;) {
>> > if (!OpenClipboard(0)) {
>> > printf("Open error.\n");
>> > break;
>> > }
>> > if (!EmptyClipboard()) {
>> > printf("Empty error.\n");
>> > break;
>> > }
>> > if (!CloseClipboard()) {
>> > printf("Cloes error.\n");
>> > break;
>> > }
>> > }
>> > return 0;
>> > }
>> >
>> > I also found the patch attached solves the issue.
>> >
>> > I would appreciate any suggestion.
>>
>> Would be neet if this patch wasn't needed, but, oh well. My only comment on
>> the
>> patch would be to possibly call the new wrapper function MyOpenClipboard, or
>> CygOpenClipboard, to help keep the name paired with CloseClipboard.
> Thanks for the comment. IIUC, the camel case name should be
> used only for Win32 APIs related. However, this is the wrapper
> for Win32 API. So, it might be acceptable. In other places,
> some wrapper functions are named as camel case.
> Corinna, WDYT?
>> I suppose it might happen in the future that a faster processor will require
>> the
>> loop count to be made larger. Once again, oh well.
> Maybe. In my most cases, OpenClipboard() successes after one
> or two times of retrying. So, I think max_retry = 10 is enough
> for the time being.
>> My 2c (adjusted for inflation),
> --
> Takashi Yano
--
With best regards,
Andrey Repin
Tuesday, July 5, 2022 17:44:56
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: Typo in ?
Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]! > There's some inconsistency between and : > sys/select.h has this: > --- > /* > * Select uses bit masks of file descriptors in longs. > * These macros manipulate such bit fields (the filesystem macros use chars). > * FD_SETSIZE may be defined by the user, but the default here > * should be >= NOFILE (param.h). > */ > #ifndef FD_SETSIZE > #define FD_SETSIZE 64 > #endif > -- > Now, this is the relevant part of sys/param.h looks like this: > -- > /* Max number of open files. The Posix version is OPEN_MAX. */ > /* Number of fds is virtually unlimited in cygwin, but we must provide >some reasonable value for Posix conformance */ > #define NOFILE 8192 > -- > So it's either "<= NOFILE" that was actually meant to be there in the comment > (or, > an equivalent "should NOT be > NOFILE"), or FD_SETSIZE should have been > defined as 8192, > if the comment is actually correct. Or maybe I'm missing something here :-) > I understand that if I redefined FD_SETSIZE in my code before including > , > it'd work with whatever large (or small) fd_set I need, but that's not what > I'm after. I'm no expert, but it seems the FD_SETSIZE should have been 128. Long is 8 bytes, 64 bits. One bit if one open file, 64 * 64 = 4096. -- With best regards, Andrey Repin Tuesday, July 5, 2022 17:52:26 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: Typo in ?
> I'm no expert, but it seems the FD_SETSIZE should have been 128. > Long is 8 bytes, 64 bits. One bit if one open file, 64 * 64 = 4096. FD_SETSIZE is the file descriptor bitset capacity in _BITS_. 64 (as currently in there) means 1 int (on 64 bit platforms, or 2 ints on 32 bit platforms, respectively), and is capable of representing 64 file descriptors by default. Anton Lavrentiev Contractor NIH/NLM/NCBI -- 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: Typo in ?
On 7/5/2022 10:13 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: Hi, There's some inconsistency between and : sys/select.h has this: --- /* * Select uses bit masks of file descriptors in longs. * These macros manipulate such bit fields (the filesystem macros use chars). * FD_SETSIZE may be defined by the user, but the default here * should be >= NOFILE (param.h). */ #ifndef FD_SETSIZE #define FD_SETSIZE 64 #endif -- I think Cygwin's FD macros are based on FreeBSD. The most recent on FreeBSD says: - /* * Select uses bit masks of file descriptors in longs. These macros * manipulate such bit fields (the filesystem macros use chars). * FD_SETSIZE may be defined by the user, but the default here should * be enough for most uses. */ #ifndef FD_SETSIZE #define FD_SETSIZE 1024 #endif - NOFILE isn't mentioned. Maybe Cygwin (or really newlib) should also remove the reference to NOFILE and, perhaps, change the default FD_SETSIZE to 1024. But Cygwin isn't the only newlib target, so there might be good reasons to keep it at 64. Corinna, WDYT? Or should the discussion be moved to the newlib list? Now, this is the relevant part of sys/param.h looks like this: -- /* Max number of open files. The Posix version is OPEN_MAX. */ /* Number of fds is virtually unlimited in cygwin, but we must provide some reasonable value for Posix conformance */ #define NOFILE 8192 -- So it's either "<= NOFILE" that was actually meant to be there in the comment (or, an equivalent "should NOT be > NOFILE"), or FD_SETSIZE should have been defined as 8192, if the comment is actually correct. Or maybe I'm missing something here :-) I suspect that the comment was actually meant as written. On FreeBSD, NOFILE is defined to be OPEN_MAX, which is 64. On Cygwin, however, it wouldn't make sense to follow that comment since, as noted in your quote from sys/param.h, there is effectively no limit on open files on Cygwin. (Cygwin maintains a dynamically growing table of file descriptors.) Ken -- 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
