Re: it's a shame... python error over error
On 12/14/24 10:31 AM, aotto1968 via Python-list wrote: > The CORE problem is that python3 works well in *my* environment but the > installation is done as root and root does not use *my* environment. > > the mono build search for a working python3 and find *my* > > HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 > The build is fine but after switch to root for installation > > sudo make install > the root user call *my* python3 and fail. mono build is failing even before you get to running your python3. That's not something python developers can fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: it's a shame... python error over error
On 12/13/24 1:56 PM, aotto1968 via Python-list wrote: > the problem is *not* to setup an environment variable, the problem is that > python is *not* > able to setup the *python* environment by it self. You're mistaken in this case. Nothing you've posted indicates the problem is in Python itself. Something isn't quite right with your linker and the linker search paths. LD_LIBRARY_PATH is one way to force the linker to use the correct search path. Python has no direct influence over the linker search paths, other than to list what shared libraries it is linked against, or to manually add paths to the linker in /etc/ld.so.conf.d/ during package installation. The ld.so linker is responsible for finding the files and linking them in, not Python. In your case it seems unable to do so, for whatever reason. Since your custom version of python3 does seem to link to the so properly, it seems as though something isn't right in the environment of the mono build process. Again, nothing to do with Python. The linker isn't even getting to the bit where it links in libpython3. -- https://mail.python.org/mailman/listinfo/python-list
Re: it's a shame... python error over error
On 12/14/24 2:56 AM, Peter J. Holzer via Python-list wrote:
> So it might be because it's in a different directory ("HOME/ext/..." is
> a relative path. That will not work in a different directory. Also
> "HOME" is a strange choice for a directory name. Did you mean $HOME?) or
> because the acceptance tests set up their own environment.
>
> I'd test the first idea first. Cd into
> HOME/src/mono.git/acceptance-tests and try to invoke
> HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 there.
Indeed something is not right with his ld.so search paths. The original
error report indicates the linker cannot even find the libpython so
file, so this cannot be a problem with Python since the linker hasn't
even found it. I don't see how he expects python to fix this
configuration issue magically for mono's build scripts.
--
https://mail.python.org/mailman/listinfo/python-list
Division-Bug in decimal and mpmath
Hi,
the division 0.4/7 provides a wrong result. It should give a periodic
decimal fraction with at most six digits, but it doesn't.
Below is the comparison of the result of decimal, mpmath, dc and calc.
0.0571428571428571460292086417861615440675190516880580357142857 decimal: 0.4/7
0.0571428571428571460292086417861615440675190516880580357142857 mpmath: 0.4/7
0.0571428571428571428571428571428571428571428571428571428571428 dc: 0.4/7
0.0571428571428571428571428571428571428571428571428571428571429 calc: 0.4/7
0.05714285714285715 builtin: 0.4/7
Both decimal and mpmath give an identical result, which is not a
periodic decimal fraction with at most six digits.
calc and dc provide as well an identical result, which *is* a periodic
decimal fraction with six digits, so I think that's right.
Below ist the python-script, with which the computation was done.
Best regards
Martin Ruppert
#!/usr/bin/env python3
from decimal import Decimal as dec
from mpmath import *
from os import popen
import decimal
z=.4
nen=7
decimal.getcontext().prec=60
print(dec(z)/dec(nen),end=' ');print(f"decimal: {z}/{nen}")
mp.dps=60
a=fdiv(z,nen);print(a,end=' ');print(f"mpmath: {z}/{nen}")
f=popen(f"dc -e'61k{z} {nen}/f'")
for i in f:i=i.rstrip()
f.close()
print(f"0{i}",end=' ');print(f"dc: {z}/{nen}")
f=popen(f"calc 'config(\"display\",61);{z}/{nen}'")
j=0
for i in f:
if j>0:i=i.rstrip();print(i,end=' ');print(f"calc: {z}/{nen}")
j+=1
f.close()
print(f"{z/nen}",end=' ');print(f"builtin: {z}/{nen}")
--
rupp...@hs-worms.de
--
https://mail.python.org/mailman/listinfo/python-list
Re: Division-Bug in decimal and mpmath
Martin Ruppert wrote:
Hi,
the division 0.4/7 provides a wrong result. It should give a periodic
decimal fraction with at most six digits, but it doesn't.
Below is the comparison of the result of decimal, mpmath, dc and calc.
0.0571428571428571460292086417861615440675190516880580357142857 decimal: 0.4/7
0.0571428571428571460292086417861615440675190516880580357142857 mpmath: 0.4/7
0.0571428571428571428571428571428571428571428571428571428571428 dc: 0.4/7
0.0571428571428571428571428571428571428571428571428571428571429 calc: 0.4/7
0.05714285714285715 builtin: 0.4/7
Both decimal and mpmath give an identical result, which is not a
periodic decimal fraction with at most six digits.
calc and dc provide as well an identical result, which *is* a periodic
decimal fraction with six digits, so I think that's right.
I looks like you might be running into limitations in floating-point
numbers. At least with decimal, calculating 4/70 instead of 0.4/7
appears to give the correct result. As does:
```
from decimal import Decimal as dec
z2 = dec(4) / dec(10)
print(z2 / dec(nen))
```
You can also pass a string, and `dec("0.4")/dec(10)` gives the correct
result as well.
Your `z` is a float, and therefore limited by the precision of a float.
It doesn't represent exactly 0.4, since that can't be exactly
represented by a float. Anything you do from then on is limited to that
precision.
I can't easily find documentation for dc and calc (links from PyPI are
either broken or don't exist), but I'm guessing they use some heuristics
to determine that the float passed in very close to 0.4 so that was
probably intended, rather than using the exact value represented by that
float.
Below ist the python-script, with which the computation was done.
Best regards
Martin Ruppert
#!/usr/bin/env python3
from decimal import Decimal as dec
from mpmath import *
from os import popen
import decimal
z=.4
nen=7
decimal.getcontext().prec=60
print(dec(z)/dec(nen),end=' ');print(f"decimal: {z}/{nen}")
mp.dps=60
a=fdiv(z,nen);print(a,end=' ');print(f"mpmath: {z}/{nen}")
f=popen(f"dc -e'61k{z} {nen}/f'")
for i in f:i=i.rstrip()
f.close()
print(f"0{i}",end=' ');print(f"dc: {z}/{nen}")
f=popen(f"calc 'config(\"display\",61);{z}/{nen}'")
j=0
for i in f:
if j>0:i=i.rstrip();print(i,end=' ');print(f"calc: {z}/{nen}")
j+=1
f.close()
print(f"{z/nen}",end=' ');print(f"builtin: {z}/{nen}")
--
https://mail.python.org/mailman/listinfo/python-list
Re: it's a shame... python error over error
On 14.12.24 10:56, Peter J. Holzer wrote:
On 2024-12-13 11:36:01 +0100, aotto1968 via Python-list wrote:
it's a shame...
almost every tool I touch that uses "python" in some way has some
configuration error because apparently a __private__ python installation
__isn't__ properly "understood".
-> I think after ~30 years *python* should be able to handle a shared-library
proper __or__ switch to a *static-build* by default.
-> example here is the "mono-build" with the following installation.
make[1]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird betreten
HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared
libraries: libpython3.12d.so.1.0: cannot open shared object file: No such
file or directory
What is HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 and why is
HOME/src/mono.git/acceptance-tests trying to use it?
[...]
make[1]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird verlassen
[debug]dev1usr@linux02:~/src/mono.git> ldd
HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3
linux-vdso.so.1 (0x7ffd18e9a000)
libpython3.12d.so.1.0 =>
HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0
(0x7f9c5d374000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f9c5d35)
libdl.so.2 => /lib64/libdl.so.2 (0x7f9c5d349000)
libutil.so.1 => /lib64/libutil.so.1 (0x7f9c5d345000)
libm.so.6 => /lib64/libm.so.6 (0x7f9c5d1f9000)
libc.so.6 => /lib64/libc.so.6 (0x7f9c5d002000)
/lib64/ld-linux-x86-64.so.2 (0x7f9c5dab4000)
So HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 does find
HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 if you
invoke it from the shell (to confirm that, try actually invoking it
instead of running ldd on it), but not when it's called from whatever
make is doing in the acceptance-tests directory.
So it might be because it's in a different directory ("HOME/ext/..." is
a relative path. That will not work in a different directory. Also
"HOME" is a strange choice for a directory name. Did you mean $HOME?) or
because the acceptance tests set up their own environment.
I'd test the first idea first. Cd into
HOME/src/mono.git/acceptance-tests and try to invoke
HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 there.
hp
The CORE problem is that python3 works well in *my* environment but the
installation is done as root and root does not use *my* environment.
the mono build search for a working python3 and find *my*
> HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3
The build is fine but after switch to root for installation
> sudo make install
the root user call *my* python3 and fail.
--
https://mail.python.org/mailman/listinfo/python-list
Re: it's a shame... python error over error
On 2024-12-13 11:36:01 +0100, aotto1968 via Python-list wrote:
> it's a shame...
> almost every tool I touch that uses "python" in some way has some
> configuration error because apparently a __private__ python installation
> __isn't__ properly "understood".
>
> -> I think after ~30 years *python* should be able to handle a shared-library
> proper __or__ switch to a *static-build* by default.
>
> -> example here is the "mono-build" with the following installation.
>
> make[1]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird betreten
> HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared
> libraries: libpython3.12d.so.1.0: cannot open shared object file: No such
> file or directory
What is HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 and why is
HOME/src/mono.git/acceptance-tests trying to use it?
[...]
> make[1]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird verlassen
> [debug]dev1usr@linux02:~/src/mono.git> ldd
> HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3
> linux-vdso.so.1 (0x7ffd18e9a000)
> libpython3.12d.so.1.0 =>
> HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0
> (0x7f9c5d374000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f9c5d35)
> libdl.so.2 => /lib64/libdl.so.2 (0x7f9c5d349000)
> libutil.so.1 => /lib64/libutil.so.1 (0x7f9c5d345000)
> libm.so.6 => /lib64/libm.so.6 (0x7f9c5d1f9000)
> libc.so.6 => /lib64/libc.so.6 (0x7f9c5d002000)
> /lib64/ld-linux-x86-64.so.2 (0x7f9c5dab4000)
So HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 does find
HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 if you
invoke it from the shell (to confirm that, try actually invoking it
instead of running ldd on it), but not when it's called from whatever
make is doing in the acceptance-tests directory.
So it might be because it's in a different directory ("HOME/ext/..." is
a relative path. That will not work in a different directory. Also
"HOME" is a strange choice for a directory name. Did you mean $HOME?) or
because the acceptance tests set up their own environment.
I'd test the first idea first. Cd into
HOME/src/mono.git/acceptance-tests and try to invoke
HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 there.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: it's a shame... python error over error
On Sun, 15 Dec 2024 at 06:05, aotto1968 via Python-list wrote: > The CORE problem is that python3 works well in *my* environment but the > installation is done as root and root does not use *my* environment. > So, it's an environment problem, NOT a Python problem. You messed up your installation. Start over, rebuild. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Division-Bug in decimal and mpmath
On 2024-12-14 at 12:08:29 +,
Mark Bourne via Python-list wrote:
> Martin Ruppert wrote:
> > Hi,
> >
> > the division 0.4/7 provides a wrong result. It should give a periodic
> > decimal fraction with at most six digits, but it doesn't.
> >
> > Below is the comparison of the result of decimal, mpmath, dc and calc.
> >
> > 0.0571428571428571460292086417861615440675190516880580357142857 decimal:
> > 0.4/7
> > 0.0571428571428571460292086417861615440675190516880580357142857 mpmath:
> > 0.4/7
> > 0.0571428571428571428571428571428571428571428571428571428571428 dc: 0.4/7
> > 0.0571428571428571428571428571428571428571428571428571428571429 calc: 0.4/7
> > 0.05714285714285715 builtin: 0.4/7
> >
> > Both decimal and mpmath give an identical result, which is not a
> > periodic decimal fraction with at most six digits.
> >
> > calc and dc provide as well an identical result, which *is* a periodic
> > decimal fraction with six digits, so I think that's right.
>
> I looks like you might be running into limitations in floating-point
> numbers. At least with decimal, calculating 4/70 instead of 0.4/7 appears
> to give the correct result. As does:
> ```
> from decimal import Decimal as dec
> z2 = dec(4) / dec(10)
> print(z2 / dec(nen))
> ```
> You can also pass a string, and `dec("0.4")/dec(10)` gives the correct
> result as well.
>
> Your `z` is a float, and therefore limited by the precision of a float. It
> doesn't represent exactly 0.4, since that can't be exactly represented by a
> float. Anything you do from then on is limited to that precision.
>
> I can't easily find documentation for dc and calc (links from PyPI are
> either broken or don't exist), but I'm guessing they use some heuristics to
> determine that the float passed in very close to 0.4 so that was probably
> intended, rather than using the exact value represented by that float.
I'm going to guess that since dc is a shell utility and calc is either
another shell utility or the calculator in emacs, and that they both do
their own conversion from a string to an internal representation without
going through an IEEE float.
Why couldn't we have evolved with eight fingers on each hand? ;-)
--
https://mail.python.org/mailman/listinfo/python-list
