Perl6 script on MSYS2 causes 'failed to stat file' error - cross-platform

When I try to run a simple perl6 script on MSYS2-64 (bash.exe) on Windows 7 it says:
Could not open my-perl6-script.pl. Failed to stat file: no such file or directory
The same script runs perfectly fine on CMD.exe so I guess it's some incompatibility between perl6 and MSYS2.
$ perl6 -v returns:
This is Rakudo Star version 2018.04.1 built on MoarVM version 2018.04.1 implementing Perl 6.c.
The bin folder of perl6 is:
-rwxr-xr-x 1 win7 None 537938 May 11 2015 libgcc_s_sjlj-1.dll
-rw-r--r-- 1 win7 None 130262 May 7 2018 libmoar.dll.a
-rwxr-xr-x 1 win7 None 57681 May 11 2015 libwinpthread-1.dll
-rwxr-xr-x 1 win7 None 6633702 May 7 2018 moar.dll
-rwxr-xr-x 1 win7 None 57225 May 7 2018 moar.exe
-rw-r--r-- 1 win7 None 104 May 7 2018 nqp.bat
-rw-r--r-- 1 win7 None 104 May 7 2018 nqp-m.bat
lrwxrwxrwx 1 win7 None 23 Jun 19 2018 perl6 -> /c/rakudo/bin/perl6.exe
-rw-r--r-- 1 win7 None 242 May 7 2018 perl6.bat
lrwxrwxrwx 1 win7 None 23 Jun 19 2018 perl6.exe -> /c/rakudo/bin/perl6.bat
-rw-r--r-- 1 win7 None 248 May 7 2018 perl6-debug-m.bat
-rw-r--r-- 1 win7 None 242 May 7 2018 perl6-m.bat
It doesn't matter if I run the script using perl6, perl6.exe or perl6.bat; they all give the same error. I'd like to run perl6 scripts on MSYS2-64. What should I do? Thanks

I installed Rakudo for Windows and made a custom perl6 shell script:
#!/bin/sh
/c/rakudo/bin/moar --execname="$0" --libpath='C:\rakudo\share\nqp\lib' --libpath='C:\rakudo\share\nqp\lib' --libpath='C:\rakudo\share/perl6/lib' --libpath='C:\rakudo\share/perl6/runtime' 'C:\rakudo\share\perl6\runtime\perl6.moarvm' "$#"
I copied perl6.bat to perl6, changed the initial path to moar to an MSYS-style path, and changed from cmd to sh quoting and arugment conventions.
Example run, from cmd:
C:\Users\cxw>perl6 -v
This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03
implementing Perl 6.d.
From the shell opened by msys2_shell.cmd:
$ uname -a
MSYS_NT-6.1-7601 Desktop 3.0.7-338.x86_64 2019-07-03 08:42 UTC x86_64 Msys
$ export PATH="$PATH":~/bin
$ cat foo.p6
use v6;
(2+2).say;
$ perl6 foo.p6
4
For what it's worth, my Rakudo bin dir:
$ ls -l /c/rakudo/bin
total 8033
-rwxr-xr-x 1 cxw None 930663 May 11 2017 libgcc_s_seh-1.dll
-rw-r--r-- 1 cxw None 136146 Mar 30 21:55 libmoar.dll.a
-rwxr-xr-x 1 cxw None 56978 May 11 2017 libwinpthread-1.dll
-rwxr-xr-x 1 cxw None 7021172 Mar 30 21:55 moar.dll
-rwxr-xr-x 1 cxw None 64066 Mar 30 21:55 moar.exe
-rw-r--r-- 1 cxw None 126 Mar 30 21:56 nqp.bat
-rw-r--r-- 1 cxw None 126 Mar 30 21:56 nqp-m.bat
-rw-r--r-- 1 cxw None 242 Mar 30 21:56 perl6.bat
-rw-r--r-- 1 cxw None 248 Mar 30 21:56 perl6-debug-m.bat
-rw-r--r-- 1 cxw None 242 Mar 30 21:56 perl6-m.bat

Related

meson doesn't find binary dependency

I compiled wayland from source code with this command
meson --buildtype=release -D prefix=$HOME/mylib -D documentation=false
then installed it with ninja. Now in $HOME/mylib I have this structure:
total 24K
drwxr-xr-x 6 myuser myuser 4.0K Dec 3 19:52 .
drwxr-xr-x 16 myuser myuser 4.0K Dec 4 17:41 ..
drwxr-xr-x 2 root root 4.0K Dec 3 19:52 bin
drwxr-xr-x 2 root root 4.0K Dec 3 19:52 include
drwxr-xr-x 3 root root 4.0K Dec 3 19:52 lib
drwxr-xr-x 4 root root 4.0K Dec 3 19:52 share
Inside bin folder I have wayland-scanner and when I run this command
wayland-scanner -v
I got this output:
wayland-scanner 1.21.90
Now when I build other source code with meson that has wayland-scanner as dependency I got this error:
../tests/meson.build:2:0: ERROR: Invalid version of dependency, need 'wayland-scanner' ['>=1.20.0'] found '1.18.0'.
This is related to another wayland-scanner that is placed here:
/usr/bin/wayland-scanner
with version 1.18.0. The command
echo $PATH
reply with this output:
/home/myuser/mylib/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
Why meson doesn't find the updated version of wayland-scanner? Using PKG_CONFIG_PATH doesn't work, same error as above
Hi don't know the wayland package, but from description
I could think that /usr/bin/wayland-scanner is a link to the old installation,
Try to look in your environment for the wayland-scanner scanner binary to check if there is some link do not updated to the new installation.

apache2.service: Control process exited, code=exited status=139

I install apache2 on ubuntu 18.04. This is fresh install with all default configuration.
I tried to start apache2 but failed. And this is what I see.
# systemctl status apache2.service
● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/apache2.service.d
└─apache2-systemd.conf
Active: failed (Result: exit-code) since Wed 2020-03-11 23:17:35 WIB; 13s ago
Process: 9151 ExecStart=/usr/sbin/apachectl start (code=exited, status=139)
Mar 11 23:17:35 xdn.id systemd[1]: Starting The Apache HTTP Server...
Mar 11 23:17:35 xdn.id apachectl[9151]: Segmentation fault
Mar 11 23:17:35 xdn.id apachectl[9151]: Action 'start' failed.
Mar 11 23:17:35 xdn.id apachectl[9151]: The Apache error log may have more information.
Mar 11 23:17:35 xdn.id systemd[1]: apache2.service: Control process exited, code=exited status=139
Mar 11 23:17:35 xdn.id systemd[1]: apache2.service: Failed with result 'exit-code'.
Mar 11 23:17:35 xdn.id systemd[1]: Failed to start The Apache HTTP Server.
When I check /var/log/apache2/error.log, there is empty.
What's wrong with this error?
The "status=139" error must have something to do with having multiple, conflicting versions of PHP enabled.
I am running 18.04 and an old PHP site I run only locally ceased to work. I am guessing aptitude installed and enabled php7.2, possibly when I installed kubuntu-desktop a few weeks back.
Regardless, I had two versions of PHP enabled:
$ cd /etc/apache2/
$ l mods-*/php*
-rw-r--r-- 1 root root 867 Jun 9 2017 mods-available/php5.6.conf
-rw-r--r-- 1 root root 102 Jun 9 2017 mods-available/php5.6.load
-rw-r--r-- 1 root root 867 Mar 2 2017 mods-available/php7.0.conf
-rw-r--r-- 1 root root 102 Oct 1 2018 mods-available/php7.0.load
-rw-r--r-- 1 root root 855 Jul 7 2017 mods-available/php7.1.conf
-rw-r--r-- 1 root root 102 Jul 7 2017 mods-available/php7.1.load
-rw-r--r-- 1 root root 855 Feb 8 2019 mods-available/php7.2.conf
-rw-r--r-- 1 root root 102 Feb 8 2019 mods-available/php7.2.load
lrwxrwxrwx 1 root root 29 Jul 1 2017 mods-enabled/php5.6.conf -> ../mods-available/php5.6.conf
lrwxrwxrwx 1 root root 29 Jul 1 2017 mods-enabled/php5.6.load -> ../mods-available/php5.6.load
lrwxrwxrwx 1 root root 29 May 28 06:05 mods-enabled/php7.2.conf -> ../mods-available/php7.2.conf
lrwxrwxrwx 1 root root 29 May 28 06:05 mods-enabled/php7.2.load -> ../mods-available/php7.2.load
In my case, I am fine with using php5.6, because the site is not online and is purely for my local use only. So disabling 7.2 did the trick:
sudo a2dismod php7.2
Now my php mods-enabled are less confusing to apache3:
$ l mods-*/php*
-rw-r--r-- 1 root root 867 Jun 9 2017 mods-available/php5.6.conf
-rw-r--r-- 1 root root 102 Jun 9 2017 mods-available/php5.6.load
-rw-r--r-- 1 root root 867 Mar 2 2017 mods-available/php7.0.conf
-rw-r--r-- 1 root root 102 Oct 1 2018 mods-available/php7.0.load
-rw-r--r-- 1 root root 855 Jul 7 2017 mods-available/php7.1.conf
-rw-r--r-- 1 root root 102 Jul 7 2017 mods-available/php7.1.load
-rw-r--r-- 1 root root 855 Feb 8 2019 mods-available/php7.2.conf
-rw-r--r-- 1 root root 102 Feb 8 2019 mods-available/php7.2.load
lrwxrwxrwx 1 root root 29 Jul 1 2017 mods-enabled/php5.6.conf -> ../mods-available/php5.6.conf
lrwxrwxrwx 1 root root 29 Jul 1 2017 mods-enabled/php5.6.load -> ../mods-available/php5.6.load
Naturally for a live site one would want to disable php-5.6 and leave the php7.2 enabled, because you should run the newer version in real life.
sudo a2dismod php5.6
sudo a2enmod php7.2
Then the php mods should look like this:
$ l mods-*/php*
-rw-r--r-- 1 root root 867 Jun 9 2017 mods-available/php5.6.conf
-rw-r--r-- 1 root root 102 Jun 9 2017 mods-available/php5.6.load
-rw-r--r-- 1 root root 867 Mar 2 2017 mods-available/php7.0.conf
-rw-r--r-- 1 root root 102 Oct 1 2018 mods-available/php7.0.load
-rw-r--r-- 1 root root 855 Jul 7 2017 mods-available/php7.1.conf
-rw-r--r-- 1 root root 102 Jul 7 2017 mods-available/php7.1.load
-rw-r--r-- 1 root root 855 Feb 8 2019 mods-available/php7.2.conf
-rw-r--r-- 1 root root 102 Feb 8 2019 mods-available/php7.2.load
lrwxrwxrwx 1 root root 29 May 29 17:43 mods-enabled/php7.2.conf -> ../mods-available/php7.2.conf
lrwxrwxrwx 1 root root 29 May 29 17:43 mods-enabled/php7.2.load -> ../mods-available/php7.2.load
Don't forget to resatart the server!
systemctl restart apache2
Thanks to Pavel's comment for inspiring this line of research!
I got this error and I fixed it by enabling PHP version 8.0 (current stable) and disabling PHP version 7.4 (old) in my ubuntu 20.04 by these commands:
sudo a2dismod php7.4
sudo a2enmod php8.0
sudo service apache2 restart
After doing these check your apache status by:
sudo systemctl status apache2.service
It has to be green and must show you active (running).
NOTE: You can do this to any PHP version that you have and want to
change.

What's the `.A` in `libobjc.A.dylib`

Simple question, what's the .A in libobjc.A.dylib? Sorry for the simple question, but it isn't exactly easy to Google information about the letter "A" without Google thinking you're using it as the singular "a" as in "a cat."
It is part of the name used to indicate a version of the library and allows multiple versions of the same library to be present. There is often an unadorned name which links to the current version, as is the case with libobjc:
$ ls -l libobjc.*
-rwxr-xr-x 1 root wheel 12937200 9 Jul 2016 libobjc.A.dylib
lrwxr-xr-x 1 root wheel 15 7 Nov 2015 libobjc.dylib -> libobjc.A.dylib
This shows that libobjc.dylib is a symbolic link to libobjc.A.dylib.
As a different example consider libgcc:
lrwxr-xr-x 1 root wheel 17 7 Nov 2015 libgcc_s.1.dylib -> libSystem.B.dylib
lrwxr-xr-x 1 root wheel 19 20 Dec 2016 libgcc_s.10.4.dylib -> libgcc_s.10.5.dylib
-rwxr-xr-x 1 root wheel 29480 2 Aug 2015 libgcc_s.10.5.dylib
Here there are three names, and two distinct versions, of the library available.
Software which requires a particular library version can link with the versioned name. Links are used when a later version is completely compatible with an earlier version, so software linking with the earlier version actually gets the later one.
All of this is only an issue with dynamic linking. With static linking the actual version of the library used during compilation is combined into the software binary and so there is no dependency on the library version(s) currently installed on the system.
I believe this is simply a naming convention to distinguish a dynamic library from it's symbolic link and the fact that any .A.dylib located within /usr/lib has the dependency of libsystem.B.dylib.
Using ls with grep shows all the .A.dylib files in /usr/lib:
$ ls -lat | grep A.dylib
-rwxr-xr-x 1 root wheel 6076144 Jul 14 23:41 libicucore.A.dylib
-rwxr-xr-x 1 root wheel 14249664 Jul 14 23:41 libobjc.A.dylib
-rwxr-xr-x 1 root wheel 85136 Jul 14 21:29 libBSDPClient.A.dylib
-rwxr-xr-x 1 root wheel 32416 Jul 14 21:28 libDHCPServer.A.dylib
-r-xr-xr-x 1 root wheel 116352 Jul 14 21:27 libalias.A.dylib
-rwxr-xr-x 1 root wheel 497312 Jul 14 21:27 libpcap.A.dylib
-rwxr-xr-x 1 root wheel 530800 Mar 22 16:56 libtidy.A.dylib
-r-xr-xr-x 1 root wheel 84704 Mar 22 16:55 libipsec.A.dylib
lrwxr-xr-x 1 root wheel 21 Oct 1 2016 libBSDPClient.dylib -> libBSDPClient.A.dylib
lrwxr-xr-x 1 root wheel 21 Oct 1 2016 libDHCPServer.dylib -> libDHCPServer.A.dylib
lrwxr-xr-x 1 root wheel 16 Oct 1 2016 libalias.dylib -> libalias.A.dylib
lrwxr-xr-x 1 root wheel 18 Oct 1 2016 libicucore.dylib -> libicucore.A.dylib
lrwxr-xr-x 1 root wheel 16 Oct 1 2016 libipsec.dylib -> libipsec.A.dylib
lrwxr-xr-x 1 root wheel 15 Oct 1 2016 libmx.A.dylib -> libSystem.dylib
lrwxr-xr-x 1 root wheel 15 Oct 1 2016 libobjc.dylib -> libobjc.A.dylib
lrwxr-xr-x 1 root wheel 15 Oct 1 2016 libpcap.dylib -> libpcap.A.dylib
lrwxr-xr-x 1 root wheel 15 Oct 1 2016 libtidy.dylib -> libtidy.A.dylib
Now for .B.dylib:
$ ls -lat | grep B.dylib
-rwxr-xr-x 1 root wheel 60848 Jul 14 21:28 libSystem.B.dylib
lrwxr-xr-x 1 root wheel 17 Oct 1 2016 libSystem.dylib -> libSystem.B.dylib
lrwxr-xr-x 1 root wheel 17 Oct 1 2016 libgcc_s.1.dylib -> libSystem.B.dylib
Take any of the .A.dylib and check it's dependencies:
$ otool -L libobjc.A.dylib
libobjc.A.dylib:
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 307.3.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
$ otool -L libipsec.A.dylib
libipsec.A.dylib:
/usr/lib/libipsec.A.dylib (compatibility version 1.0.0, current version 300.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)
$ otool -L libicucore.A.dylib
libicucore.A.dylib:
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 57.1.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
...
Is it a dynamic library or a static library? file tells us that's it's a dynamic library all the way:
$ file libobjc.A.dylib
libobjc.A.dylib: Mach-O universal binary with 3 architectures: [x86_64: Mach-O 64-bit dynamically linked shared library x86_64] [i386] [x86_64h]
libobjc.A.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
libobjc.A.dylib (for architecture i386): Mach-O dynamically linked shared library i386
libobjc.A.dylib (for architecture x86_64h): Mach-O 64-bit dynamically linked shared library x86_64h
It seems as though the logic here points to a means of identifying the dynamic libraries ( A ) which all have the common trait of depending on library ( B ).
The .A files are static libraries. You can find more information on them on the Wikipedia.
They are collections of object files that are linked into the program during the linking phase of compilation, and are not relevant during runtime

How to freeze graphs from checkpoint directory for inception-v3 model?

I am fine tuning inception-v3 model flowers using this: https://github.com/tensorflow/models/tree/master/inception
I checkpointed the result in a directory. But in the directory I see files like these:
-rw-r--r-- 1 root root 389908432 Mar 15 21:46 model.ckpt-0.data-00000-of-00001
-rw-r--r-- 1 root root 72680 Mar 15 21:46 model.ckpt-0.index
-rw-r--r-- 1 root root 15189794 Mar 15 21:47 model.ckpt-0.meta
-rw-r--r-- 1 root root 135185788 Mar 15 22:36 events.out.tfevents.1489594533.f7d5defbed64
-rw-r--r-- 1 root root 72680 Mar 15 22:37 model.ckpt-4999.index
-rw-r--r-- 1 root root 389908432 Mar 15 22:37 model.ckpt-4999.data-00000-of-00001
-rw-r--r-- 1 root root 15189794 Mar 15 22:38 model.ckpt-4999.meta
-rw-r--r-- 1 root root 130 Mar 15 22:49 checkpoint
whereas I need outputs in directory similar to this:
-rw-r----- 1 107456 5000 223 Mar 2 2016 README.txt
-rw-r----- 1 107456 5000 43 Mar 2 2016 checkpoint
-rw-r----- 1 107456 5000 434903494 Mar 15 2016 model.ckpt-157585
For that I need to do something like freezing, but freezing needs to provide output_node_names. Can anyone guide me, what will be the output_node_names for inception-v3?
Also, I need a reliable way to freeze. Is tensorflow freezer tool okay for this?
I found the answer eventually.
One-line answer should be to use freezer.py available in upstream Tensorflow codebase. See the example on how to use that program from tests.
You may check the following link for sample:
https://gist.githubusercontent.com/morgangiraud/249505f540a5e53a48b0c1a869d370bf/raw/6cb0b4d497925517316a92f935ce5dccb6aafd17/medium-tffreeze-1.py

Apache: Error writing httpd-userdir.conf: Permission denied

I'm following this guide so that I can run websites on a local server using Apache on OS-X El Capitan. I'm trying to edit my httpd-userdir.conf file but when I try to save it gives me the error:
Error writing httpd-userdir.conf: Permission denied
Terminal shows that the permissions for my httpd-userdir.conf file is -rw-r--r-- , so I don't understand why I wouldn't be allowed to write?
drwxr-xr-x 15 root wheel 510B Feb 24 13:35 ./
drwxr-xr-x 11 root wheel 374B Feb 24 13:27 ../
-rw-r--r-- 1 root wheel 2.8K Jul 31 2015 httpd-autoindex.conf
-rw-r--r-- 1 root wheel 1.7K Jul 31 2015 httpd-dav.conf
-rw-r--r-- 1 root wheel 2.9K Jul 31 2015 httpd-default.conf
-rw-r--r-- 1 root wheel 1.1K Jul 31 2015 httpd-info.conf
-rw-r--r-- 1 root wheel 5.0K Jul 31 2015 httpd-languages.conf
-rw-r--r-- 1 root wheel 1.0K Jul 31 2015 httpd-manual.conf
-rw-r--r-- 1 root wheel 4.4K Jul 31 2015 httpd-mpm.conf
-rw-r--r-- 1 root wheel 2.2K Jul 31 2015 httpd-multilang-errordoc.conf
-rw-r--r-- 1 root wheel 13K Jul 31 2015 httpd-ssl.conf
-rw-r--r-- 1 root wheel 607B Jul 31 2015 httpd-userdir.conf
-rw-r--r-- 1 root wheel 607B Feb 24 13:35 httpd-userdir.conf.bak
-rw-r--r-- 1 root wheel 1.5K Jul 31 2015 httpd-vhosts.conf
-rw-r--r-- 1 root wheel 3.1K Jul 31 2015 proxy-html.conf
#erapert was correct, I just had to do sudo vi /etc/apache2/extra/httpd-userdir.conf and that allowed me to edit the file.