Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Dave Yeo

Pages: [1] 2 3 ... 357
1
You have already identified the problem: your python.exe is the same as python3.9.exe.
Just copy python2.7.exe over python.exe and you are fine.

That's only a good solution if you want to usually use Python2. Other solutions include using the full name, python2.7.exe instead of python2.7 or python2. I think our system doesn't like the multiple dots in the executable name. Another solution is to use sh to launch the python2/python3 script as it seems to get it right.
As for removing python2, it is different enough from python3 it is likely worth keeping it around as there are lots of python2 scripts still out there. I also suspect that there are dependencies between the two in the RPM environment.

2
What might be a better option would be a kind of XP Mode, like in Windows 7. A lean and fast virtual environment for running a modern browser. And as if that weren't dreamy enough, perhaps even seamless on the WPS.

I don't know about a virtual machine. We do have Odin (think WINE). It hasn't been worked on in a while but you can run some Win32 programs, and can compile some Win32 programs to look native. In the past, Adobe Acrobat, OpenJDK for example have had their Win32 code recompiled on OS/2. Last time we went through this in the IE days, there was actually an official version of Opera built this way.
It would take syncing a recent version of WINE into Odin, probably a big job by skilled people, but a possibility.
Problem is that Win32 is going away. Less and less support it and I think Qt6 doesn't support it and not sure about others.

3
Programming / Re: GCC - updates
« on: Today at 05:51:33 am »
Thanks, working

4
Programming / Re: GCC - updates
« on: Today at 05:12:51 am »
404

5
The other side is financing. I don't know much about Arca Noae's internals, not even sure of how many people are involved though I have a better idea then most here. They have to pay IBM some amount for every copy of AOS sold or given away. No idea of how much but I'd imagine IBM wants enough that the profit margin on AOS isn't that high. I don't think they have many enterprise customers and the number of users has been steadily dropping. I think it is as much hobby and side hustle for the owners and not something that they are getting rich on and I doubt they have the resources to pay for browser development besides supplying a bit of infrastructure and similar. I also don't think the community is big enough to support much either.
All the above is my opinion as I don't know much about the internals of Arca Noae.

6
As pointed out, we're running an ancient system in PC terms, 20 years since IBM dropped all support, 30 years since most active development was stopped, 35 years since OS/2 2.x was basically designed.
We have a mickey mouse tool chain, Paul has done an excellent job of keeping our GCC fork up to date, but it is a fork and parts of it are ancient. Aout object format as an example with no one having the skills and interest in updating to a more modern object format such as ELF or even what Windows currently uses.
We're also missing other tools to lint our code to find obvious bugs like perhaps a missing free(), and those tools probably would require more then 4GB's of ram, especially to check the Qtwebengine.
Browsers are supported by large organizations, Google, Mozilla and Apple are about it. Even MS switched to being based on Google's work. Development happens fast and just keeping up would take a team of people. We saw with Mozilla, one person trying to keep up leads to burn out.
Our platform is missing modern features. Getting IPC working has proved to be hard, we have to run the browsers in --single-process mode, which is unsupported and may be the source of memory leaks. Seems the problem is our TCPIP stack just craps out on local socket operations that are too big.
For a developer to do much, they would have to be a guru, an OS/2 guru, of which there is a severe shortage of. And they would have to be full time, perhaps with a team. Expensive.
I hate to say it, but a modern browser is not likely. A semi-modern one might be possible. Pale Moon could perhaps be done by a decent OS/2 programmer as an example. All the code is in the Mozilla tree and it is a fork, though lots of changes there. Even then a lot of web sites would  not work.
We're an ancient platform. I'm lucky as most of what I do, our SeaMonkey is good enough with work arounds like my Credit Union where clicking an icon doesn't work but using the menu does.

7
Applications / Re: EXIFTool
« on: April 24, 2025, 11:57:26 pm »
I installed it and quickly created a package that mostly goes into /@unixroot/usr/local with one file, perllocal.pod in /@unixroot/usr/lib/perl5. If that already exists, add the contents of the mine to the end of the file.
I also include exiftool.cmd so that you can simply run exiftool instead of doing perl exiftool.
Feedback and suggestions welcome. can also be the basis for a new WPI

8
Applications / Re: EXIFTool
« on: April 24, 2025, 04:40:35 am »
Hello

Sorry to confuse more the issue.
Are there two things, the ExifTool Perl Module, and the ExifTool command line tool? Does both belong to the same project?

Because "EXIFtool_2-2.zip" (2005) is from Marcel Mueller and it is a .exe binary with it's source code.
ExifTool Perl Module (ExifTool_Perl_9-46.wpi) (2014) I have no idea how to use it.

Regards

It appears at some point it was ported to perl. Good idea as it is portable. even without installing or running "perl Makefile.PL" then make, make install. Easy to use, go to where you untarred it and run "perl exiftool" with parameters. Installing would probably make the man pages available.

9
Applications / Re: EXIFTool
« on: April 24, 2025, 04:22:03 am »
Hi,

thanks for all your suggestions so far.
I also guess, that the WPI tool only cares for other WPI installations, but not for RPM packages.
There are some Perl RPMs on my system, the one named "Perl" is on version 5.16.1-9.
Dave's suggestion to install Paul's Perl 5.8.8 WPI package was my first idea but it is not available (for me) anywhere.

So there seems no other way as to inspect the WPI package in its details, as Lars already suggested in the German OS/2 forum.
I'm not familiar with this and I will try to follow Steven's advice. This will take some time and whenever I succeed I will report it here.

Hansi

I downloaded https://exiftool.org/Image-ExifTool-13.27.tar.gz, it doesn't even need installed. You should install some other Perl packages, see the README, then open ANPM, go to the available packages, scroll down to perl and you should be able to guess which packages supply stuff, eg the 1st 2 requirements,
Code: [Select]
Archive::Zip         (ZIP, DOCX, PPTX, XLSX, ODP, ODS, ODT, EIP, iWork)
Compress::Zlib       (DNG, PNG, PDF, DCM, MIE and SWF files)
are covered by
Code: [Select]
perl-Archive-extract
perl-Archive-Tar
perl-Archive-Zip
Tar might not be needed but doesn't hurt to add. Not all packages are available, some don't make sense for us such as the Win32 ones.
To run, just prefix the command with perl, after going to the folder you extracted the package to, eg the example,
Code: [Select]
perl ./exiftool t/images/ExifTool.jpg
Note using slashes instead of backslashes and the beginning ./ just means the current directory.

As Steve mentioned, it wouldn't be hard to examine the wic from ExifTool_Perl_9-46.wpi to figure out the program files. To access the wic, you need to run wic.exe -X ExifTool_Perl_9-46.wpi. wic.exe should be in C:\sys\install\WARPIN, or whatever drive letter you installed to.
Also see https://exiftool.org/ for other cmd line options, just remember on OS/2 you need to prefix the command with perl or perl.exe


10
Applications / Re: EXIFTool
« on: April 23, 2025, 05:37:03 am »
Thinking about it, you could probably install Paul's Perl 5.8.8 WPI carefully paying attention to whatever config.sys changes the package makes, install ExifTool_Perl then undo the config.sys changes and put those changes into the Program objects Environment tab. There's maybe a dozen Program Objects that would need the environment updated.
I think the only changes to config.sys that the perl package will make are to PATH, LIBPATH and adding SET PERLLIB_PREFIX. Backup config.sys before doing this. Use BEGINLIBPATH instead of LIBPATH and don't use the SET in the program object's ENVIRONMENT tab.
eg guessing, the environment tab should end up something like,
Code: [Select]
PATH=C:\Perl;$PATH%
BEGINLIBPATH=C:\PERL;C:\PERL\LIB
PERLIB_PREFIX=U:/PERL/LIB
Adjust to whatever gets written to config.sys
Wouldn't hurt to do a full backup first just in case.

11
Applications / Re: EXIFTool
« on: April 23, 2025, 05:09:33 am »
As I mentioned elsewhere: the WPI package script needs rework to get rid of the dependency on the Perl WPI package as Perl is now delivered via YUM/RPM.

Looks more like it needs rebuilding with a PREFIX of /@unixroot/local which hopefully will work with Perl. Currently it installs all the pod etc files in $(Paul Smedley\base)\EXIFTOOL. Could install to the system Perl but not sure what would happen when Perl is updated, especially a major update. Generally a bad idea to mix other stuff in the default RPM directories.
I'm not up enough on my Warpin scripts to try to adjust the install script to /@unixroot/local, nor sure about where in local (is it possible?) to keep Perl happy and where the default would be.

12
Multimedia / Re: Updated Uniaud32 build
« on: April 20, 2025, 04:09:26 am »
No, at least one German user has the same problem, https://forums.linuxmint.com/viewtopic.php?p=2513872 Someone else after completely powering down and back up started to access. Weird.
Tracerte ends up at the same address,
Code: [Select]
1  192.168.0.1               (192.168.0.1)  0 ms  0 ms  0 ms
 2  100.123.16.15             (100.123.16.15)  40 ms  30 ms  20 ms
 3  100.123.19.8              (100.123.19.8)  20 ms  20 ms  40 ms
 4  100.123.19.16             (100.123.19.16)  30 ms  60 ms  60 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  80.150.170.94             (80.150.170.94)  110 ms  150 ms  280 ms
10  l-ea5-i.L.DE.NET.DTAG.DE  (217.5.68.242)  210 ms  190 ms  190 ms
11  62.157.251.90             (62.157.251.90)  190 ms  190 ms  220 ms
12  dd41708.kasserver.com     (85.13.139.169)  200 ms  190 ms  200 ms

13
Multimedia / Re: Updated Uniaud32 build
« on: April 20, 2025, 03:44:51 am »
Not here. Tried SeaMonkey, then Dooble-Qt6. Then fell back to my phone where I tried the duckduckgo browser and then Chrome, all give 403 Forbidden, You don't have permission to access this resource. My son also tried Firefox on Win 11. Phone is on a different network from our home, phone is Bell and home is Telus
Geo-blocked?
Edit:
Code: [Select]
H:\tmp>wget https://www.linuxmintusers.de/
--2025-04-19 18:45:35--  https://www.linuxmintusers.de/
Resolving www.linuxmintusers.de (www.linuxmintusers.de)... 85.13.139.169
Connecting to www.linuxmintusers.de (www.linuxmintusers.de)|85.13.139.169|:443..
. connected.
HTTP request sent, awaiting response... 403 Forbidden
2025-04-19 18:45:36 ERROR 403: Forbidden.

14
Multimedia / Re: Updated Uniaud32 build
« on: April 20, 2025, 12:53:30 am »

As playing around with PMUnimix and all those available unimix switches lead to no success, I opend a question on the German Linux Mint Forum:

https://www.linuxmintusers.de/index.php?topic=86025.msg1099397#new

I hope to collect more information about the OEM Kernel and its difference with the "usual" 6.8 or 6.12 Kernel.

Hmm, 403 error, guess have to have an account?
Same with https://www.linuxmintusers.de/

15
Applications / Re: SSL update: Firefox XUL.DLL can no longer load
« on: April 18, 2025, 04:49:56 pm »
The original idea from Bitwise was to use the RPM installed NSPR4 and NSS and some builds were built using those RPM's. I and others found that the browser would simply vanish now and again so I went back to building using the intree NSPR4 and NSS as it was more stable.
Lars, you are using an old build and at least for me. the newer builds are more stable. Various fixes were made to build with GCC 9.2.0 and different flags, including less optimization which helped stability.
You can find the build ID by going to about:support and the GCC version and configure flags by going to about:buildconfig
Edit: about:about will list all the about: URL's

Pages: [1] 2 3 ... 357