Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

[Vince Rice]

> On Mar 1, 2017, at 11:27 PM, Steven Penny wrote:
> 
> On Wed, 1 Mar 2017 21:46:38, Vince Rice wrote:
>> There are valid reasons (which several others have made) not to force others
>> to use it.
> 
> Have they though? I have not seen anyone save Eric (including you) make a 
> valid
> argument beyond "I like it the old way".

Then you haven't been paying attention.
And I didn't even attempt to make an argument one way or the other, 
except to say stop arguing. The horse is dead.
--
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: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

[Steven Penny]

On Wed, 1 Mar 2017 21:46:38, Vince Rice wrote:

There are valid reasons (which several others have made) not to force others
to use it.


Have they though? I have not seen anyone save Eric (including you) make a valid
argument beyond "I like it the old way".


--
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: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

[Vince Rice]

> On Mar 1, 2017, at 6:22 PM, Steven Penny  wrote:
> 
> On Wed, 1 Mar 2017 09:42:27, cyg Simple wrote:
>> Oh but it is.  We're discussing the bike shed named /bin/sh.
>> One of the color names is bash the other is dash; it's still the same
>> bike shed.
> 
> I see, when you realize your argument does not hold water, you resort to name
> calling. Here are concrete arguments:
> 
> 1. Debian uses Dash as /bin/sh
> 2. Ubuntu uses Dash as /bin/sh
> 3. The POSIX standard defines sh, and by definition Dash is closer to this 
> than
>  Bash
> 4. Dash is 3-5 times faster than Bash
> 5. While it might be upsetting to some users, _they_ have made an error in
>  assuming Bash is /bin/sh, it would not be our error in switching to a shell
>  that is closer to POSIX sh
> 
> Now, perhaps you can add a constructive post, or do you want to start with 
> some
> "yo momma" jokes?

He didn't call anyone names. He said that was a bike shed argument. Which is 
getting more accurate the longer this "discussion" goes on.

You've argued your point. If you like dash, then use it. There are valid 
reasons (which several others have made) not to force others to use it.

The decision isn't yours. Or mine. And the ones whose decision it is will 
switch or they won't.

Let's move on.


--
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: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

[Steven Penny]

On Wed, 1 Mar 2017 09:42:27, cyg Simple wrote:

Oh but it is.  We're discussing the bike shed named /bin/sh.
One of the color names is bash the other is dash; it's still the same
bike shed.


I see, when you realize your argument does not hold water, you resort to name
calling. Here are concrete arguments:

1. Debian uses Dash as /bin/sh
2. Ubuntu uses Dash as /bin/sh
3. The POSIX standard defines sh, and by definition Dash is closer to this than
  Bash
4. Dash is 3-5 times faster than Bash
5. While it might be upsetting to some users, _they_ have made an error in
  assuming Bash is /bin/sh, it would not be our error in switching to a shell
  that is closer to POSIX sh

Now, perhaps you can add a constructive post, or do you want to start with some
"yo momma" jokes?


--
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: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

[Matt Seitz (matseitz)]

Personally, I would invoke a variation of Linus's attitude to breaking user 
space apps:  the distribution should not break existing user's scripts, even if 
they are not following "the rules".

If you want to speed up the scripts distributed by Cygwin, then I would suggest 
modifying those scripts to use #!/bin/dash.  Or give the user an option to 
change "/bin/sh" to point to dash, but don't make that the default setting.

But breaking who-knows-how-many user scripts without the user's informed 
consent seems like an undesirable solution.


--
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: (fixup) [PATCH] forkables: use dynloaded dll's IndexNumber as dirname

[Michael Haubenwallner]

Hi Corinna,

On 02/23/2017 03:03 PM, Corinna Vinschen wrote:
> Hi Michael,
> 
> I'm inclined to promote the "forkables" code to master.  I just have a
> few points before we do that:
> 
> - Revert bumping of CYGWIN_VERSION_SHARED_DATA.  We only have to do that
>   if the shared region changes in an incompatible way.  But this is just
>   adding a member to the end.

Ok.
As long as properly aligned, even int-access should be atomic:
Is it ok to add the new member as 'char' rather than 'int'?

> - I'm looking a bit cross-eyed on the usage of forkables_needs and
>   cygwin_shared->prefer_forkable_hardlinks.  It seems to me as if the
>   split between those two isn't quite right and the fact that both
>   share information seems error prone.
>   
>   IMHO prefer_forkable_hardlinks should actually be the single marker
>   for the per-installation state.  After startup of the first process it
>   should be "unknown" (0) by default.  At startup it's set to one of
> 
> "disabled"   (-1) no NTFS or dir is missing
> "enabled"(+1) NTFS and dir exists
> 
>   That sets the state once and for all by the first Cygwin process in
>   the system.

The initial check now is moved to dll_list::forkable_ntnamesize(),
which is called by dll_list::alloc().

What about the renaming cygwin_shared->prefer_forkable_hardlinks
to cygwin_shared->forkable_hardlink_support?

The new dll_list::forkables_supported() replaces the "unknown","impossible",
"disabled" values.  I've thought about inlining into dll_init.h, but that
would require to include "shared_info.h": Is there a specific reason behind
dll_init.h not having any #include right now?

>   Consequentially, forkables_needs should only reflect the per-process
>   states
> 
> "needless"
> "needed"
> "created"
> 
> - Shouldn't forkables_needs be renamed to forkables_needed?

I've further simplified and replaced "enum forkables_needs" with
"bool forkables_created", because the "needless" value now is
implemented as "first fork tries without hardlinks". So as soon as
request_forkables() is entered, hardlinks aren't "needless" any more.

> That's all.  There are a few minor formatting issues, but they are
> negligible.

Do you prefer another patch series with this patch applied as fixups?

Thanks a lot!
/haubi/
>From bf08d3ae7441f7db23d034cccb9563cee0842fa6 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner 
Date: Wed, 1 Mar 2017 10:19:37 +0100
Subject: [PATCH] forkables: simplify disabling via shm

* Rename cygwin_shared->prefer_forkable_hardlinks to
  forkable_hardlink_support, with values
  0 for Unknown, 1 for Supported, -1 for Unsupported.
  Upon first dll loaded ever, dll_list::forkable_ntnamesize checks the
  /var/run/cygfork directory to both exist and reside on NTFS, setting
  cygwin_shared->forkable_hardlink_support accordingly.
* Replace enum forkables_needs by bool forkables_created: Set
  to True by request_forkables after creating forkable hardlinks.
---
 winsup/cygwin/dll_init.h   |  21 ++--
 winsup/cygwin/forkable.cc  | 185 ++---
 winsup/cygwin/include/cygwin/version.h |   2 +-
 winsup/cygwin/shared.cc|   2 +-
 winsup/cygwin/shared_info.h|   4 +-
 5 files changed, 65 insertions(+), 149 deletions(-)

diff --git a/winsup/cygwin/dll_init.h b/winsup/cygwin/dll_init.h
index d598618..7129cee 100644
--- a/winsup/cygwin/dll_init.h
+++ b/winsup/cygwin/dll_init.h
@@ -87,17 +87,9 @@ struct dll
 class dll_list
 {
   /* forkables */
-  enum
-{
-  forkables_unknown,
-  forkables_impossible,
-  forkables_disabled,
-  forkables_needless,
-  forkables_needed,
-  forkables_created,
-}
-forkables_needs;
+  bool forkables_supported ();
   DWORD forkables_dirx_size;
+  bool forkables_created;
   PWCHAR forkables_dirx_ntname;
   PWCHAR forkables_mutex_name;
   HANDLE forkables_mutex;
@@ -160,10 +152,11 @@ public:
   void cleanup_forkables ();
   bool setup_forkables (bool with_forkables)
   {
-if (forkables_needs == forkables_impossible)
-  return true; /* short cut to not retry fork */
-/* Once used, always use forkables in current process chain. */
-if (forkables_needs != forkables_unknown)
+if (!forkables_supported ())
+  return true; /* no need to retry fork */
+if (forkables_created)
+  /* Once created, use forkables in current
+	 process chain on first fork try already. */
   with_forkables = true;
 if (with_forkables)
   request_forkables ();
diff --git a/winsup/cygwin/forkable.cc b/winsup/cygwin/forkable.cc
index ebbed8c..b668d03 100644
--- a/winsup/cygwin/forkable.cc
+++ b/winsup/cygwin/forkable.cc
@@ -501,17 +501,56 @@ dll::create_forkable ()
   return false;
 }
 
+bool
+dll_list::forkables_supported ()
+{
+  return cygwin_shared->forkable_hardlink_support >= 0;
+}
+
 /* return the number of characters necessary to store one forkable name */
 size_t
 

Re: problem with fortran common block in shared library

[Marco Atzeri]

On 06/01/2017 16:52, Bill Greene wrote:

This problem is not a generic gcc/gfortran one.
If you build the test code on Linux, it works correctly.

Bill



the problem is gfortran one on Windows platform

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68040

If you create a directive like

--
!GCC$ ATTRIBUTES DLLEXPORT :: /cb1/
  integer cvar
  common /cb1/ cvar
--

It produces and error like
--
 !GCC$ ATTRIBUTES DLLEXPORT :: /cb1/
   1
Error: Invalid character in name at (1)
--

so the DLLEXPORT directive is not correctly
managing "common" as "/cb1/"

I also noted that the "!GCC$" must be at the beginning of the line
otherwise is totally ignored, that is also very hard to note.

Regards
Marco







#!/bin/sh -x
cat >cb_main.f <<\EOF
  program cb_main
  !GCC$ ATTRIBUTES DLLEXPORT :: /cb1/
  integer cvar
  common /cb1/ cvar
  cvar = 0
  call cb_func()
  if(cvar.eq.2) then
  write(*,*)'GOOD COMMON BLOCK'
  else
  write(*,*)'BAD COMMON BLOCK'
  endif
  end
EOF
cat >cb_func.f <<\EOF
  subroutine cb_func()
  !GCC$ ATTRIBUTES DLLIMPORT :: /cb1/
  integer cvar
  common /cb1/ cvar
  cvar = 2
  cvar2 = 2
  end
EOF

rm -f *.o *.dll *.a *.exe
gfortran -c cb_func.f 
gfortran -c cb_main.f 

ar cr libcb_static.a cb_func.o
gfortran cb_main.o -L. -lcb_static -o cb_main_static

gfortran -shared -o libcb_dynamic.dll cb_func.o 
gfortran cb_main.o -L. -lcb_dynamic -o cb_main_dynamic 

./cb_main_static
./cb_main_dynamic

#!/bin/sh -x
cat >cb_main.f <<\EOF
  program cb_main
!GCC$ ATTRIBUTES DLLEXPORT :: /cb1/
  integer cvar
  common /cb1/ cvar
  cvar = 0
  call cb_func()
  if(cvar.eq.2) then
  write(*,*)'GOOD COMMON BLOCK'
  else
  write(*,*)'BAD COMMON BLOCK'
  endif
  end
EOF
cat >cb_func.f <<\EOF
  subroutine cb_func()
!GCC$ ATTRIBUTES DLLIMPORT :: /cb1/
  integer cvar
  common /cb1/ cvar
  cvar = 2
  cvar2 = 2
  end
EOF

rm -f *.o *.dll *.a *.exe
gfortran -c cb_func.f 
gfortran -c cb_main.f 

ar cr libcb_static.a cb_func.o
gfortran cb_main.o -L. -lcb_static -o cb_main_static

gfortran -shared -o libcb_dynamic.dll cb_func.o 
gfortran cb_main.o -L. -lcb_dynamic -o cb_main_dynamic 

./cb_main_static
./cb_main_dynamic


--
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

Fwd:Feugiat Lorem Ipsum Ltd invoice\13hi31

[Zahir Williams]

Greetings

Please review the invoice from Feugiat Lorem Ipsum Ltd attached. 

The passwd is 5Z3WBM1o


Zahir Williams

13hi31.docx
Description: Attached file: 13hi31.docx

--
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: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

[cyg Simple]

On 2/28/2017 4:43 PM, Steven Penny wrote:
> On Tue, 28 Feb 2017 15:52:15, cyg Simple wrote:
>> Ironic that *you* should make the same argument for using #!/bin/bash as
>> I've made to you about using #!/bin/dash.
> 
> Its not the same argument:
> 

Oh but it is.  We're discussing the bike shed named /bin/sh.

> - You are talking about people assuming Dash is /bin/sh
> - I am talking about people assuming Bash is /bin/sh
> 

One of the color names is bash the other is dash; it's still the same
bike shed.

-- 
cyg 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: cygpath (reprised)

[cyg Simple]

On 3/1/2017 8:12 AM, Andrey Repin wrote:
> Greetings, cyg Simple!
> 
>> On 2/25/2017 8:13 PM, Andrey Repin wrote:
>>> Greetings, cyg Simple!
>>>
 Also a : isn't a valid character for a name in Windows.  Cygwin uses
 some magic to represent it in UNICODE format though.
>>>
>>> It isn't a valid file "name" character, yes, but it is still a meaningful
>>> character in pathname under windows.
>>> Just the meaning of it is far from regular file name semantics.
>>>
> 
>> Not when specifying ./a:b which was the example being discussed.
> 
> We were discussing "a:b", not "./a:b".

Then you need to re-read the elided content.  An example of ./a:b was
given and what I responded to.

-- 
cyg 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: cygpath (reprised)

[Andrey Repin]

Greetings, cyg Simple!

> On 2/25/2017 8:13 PM, Andrey Repin wrote:
>> Greetings, cyg Simple!
>> 
>>> Also a : isn't a valid character for a name in Windows.  Cygwin uses
>>> some magic to represent it in UNICODE format though.
>> 
>> It isn't a valid file "name" character, yes, but it is still a meaningful
>> character in pathname under windows.
>> Just the meaning of it is far from regular file name semantics.
>> 

> Not when specifying ./a:b which was the example being discussed.

We were discussing "a:b", not "./a:b".


-- 
With best regards,
Andrey Repin
Wednesday, March 1, 2017 16:11:45

Sorry for my terrible english...


--
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: All wx apps crash because of nl_langinfo(CODESET) returns garbage

[Corinna Vinschen]

On Mar  1 07:56, Kolya Kosenko wrote:
> All wxWidgets-based application crash because call
> nl_langinfo(CODESET) returns sometimes garbage during wxWidgets
> initialization at
> /usr/src/debug/wxWidgets3.0-3.0.2.0-2/src/common/intl.cpp:811:
> char *oldLocale = strdup(setlocale(LC_CTYPE, NULL));
> setlocale(LC_CTYPE, "");
> const char *alang = nl_langinfo(CODESET);
> setlocale(LC_CTYPE, oldLocale);
> free(oldLocale);
> alang variable is not null and garbage here! It causes wxWidgets
> assertion failure at wxString::FromAscii().

At first sight this looks like a bug to me.  The information returned by
nl_langinfo is only guaranteed to be stable if you don't call setlocale
or nl_langinfo again.  If you need the result of nl_langinfo(CODESET)
even after calling setlocale again, you have to strdup it.


Corinna

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


signature.asc
Description: PGP signature