How are these release candidates, exactly?

[tschak909]

What testing methodologies are you using here?

"It works on my machine?"

What are you testing?

I ask this out of abject frustration, because I have been trying to set up a workable sun2 emulation, for almost 5 years to produce a series of Youtube videos, first with TME and then with NME.

The GTK+ output does not work correctly with HiDPI displays AT ALL. I have to run inside a Xephyr or Xnest to get anything remotely displayable.

And when I do, the GTK display ONLY updates, when I cause another window inside the display to update (e.g. when I open a root window on my window manager)

This, along with tons of inconsistent keyboard behaviors (e.g. ^C doesn't work), makes this entire emulation unusable, and I would be ashamed of attempting to place a "release candidate" moniker to any of this.

-Thom

[tschak909]

Video: https://www.youtube.com/watch?v=wXDLWKxBB30

[phabrics]

Indeed, I can confirm that my testing methodology involves only testing it on my machine(s) as that is all I have available to me right now. I haven't had a lot of feedback from others over the years, so I have had to rely on what I have at hand. To make up for this, I have tried to maintain a consistent building methodology that relies heavily on making sure that the bare minimum functionality can be built and run on as many different platforms as possible. To achieve that, I have had to rely on a lot of virtual machines, of course. So long as it builds & runs on the "worst" possible machine (and maintaining the spirit on NetBSD of "of course it runs it"), it should theoretically work on machines which I don't have.

Having said that, I can see that you were at least able to build & run NME/TME on your machine(s). I watched your video and was pleased to see that you had some success with it, albeit very limited. I am sorry that it was unusable and didn't work well enough for your needs. Unfortunately, it looks as though you stumbled upon the one testcase that eluded my attention. TME was built to host a variety of machines, so manually running all these with the various OSes was time-consuming. I would like to automate this more and have a better testing methodology as you say. It has been a goal for a while.

[phabrics]

After testing sun2 on a couple of machines, it does appear that there is a problem with the timer interrupts. It looks like it only affects Unix-like (POSIX) platforms. It appears to work OK on Windows under the MSYS2 mingw64 environment. I am not sure why that is. I am still looking into it and will assign it to myself as a bug. It does look like the interrupts are only generated upon graphical screen updates for some reason. This seems most pronounced on the cooperative multithreading (fiber) model. The preemptive multithreading (pthreads) build doesn't seem to have the problem. However, it is slower in general. If you want, you can try configuring with --enable-threads and that might work around the problem for the time-being. I'm hoping the next (sub)release will address it.

I have been meaning to drop the "release candidate" moniker. It was more a vestige of past ambitions. It's better to use subversioning so as not to raise expectations unnecessarily.

[tschak909]

Here is my environment, if you'd like a copy: sun2-sunos-3.2.tar.gz https://drive.google.com/file/d/1eHumXvUgSX0Nj2sCmvcvwxhE44mxry0-/view?usp=drive_web -Thom.

On Sun, Jul 28, 2024 at 6:33 PM Ruben Agin @.***> wrote:

After testing sun2 on a couple of machines, it does appear that there is a problem with the timer interrupts. It looks like it only affects Unix-like (POSIX) platforms. It appears to work OK on Windows under the MSYS2 mingw64 environment. I am not sure why that is. I am still looking into it and will assign it to myself as a bug. It does look like the interrupts are only generated upon graphical screen updates for some reason. This seems most pronounced on the cooperative multithreading (fiber) model. The preemptive multithreading (pthreads) build doesn't seem to have the problem. However, it is slower in general. If you want, you can try configuring with --enable-threads and that might work around the problem for the time-being. I'm hoping the next (sub)release will address it.

I have been meaning to drop the "release candidate" moniker. It was more a vestige of past ambitions. It's better to use subversioning so as not to raise expectations unnecessarily.

— Reply to this email directly, view it on GitHub https://github.com/phabrics/nme/issues/7#issuecomment-2254689270, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVBYZVANOMRVBQHSMBLKW3ZOV5WJAVCNFSM6AAAAABLQ35U6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJUGY4DSMRXGA . You are receiving this because you authored the thread.Message ID: @.***>

[phabrics]

I think I've fixed the sun2 timing issue that was causing the GUI to hang. It was a bit of a strange bug. I tried it out on your environment, and it seemed to work. I put out a new pre-release, v0.12.13. Please give it a try and let me know if it works for you. Note that there are now 3 frontends available: GTK, VNC, and SDL. The SDL is currently a full-screen implementation only. I have only added the option for the SUN4-75 example under machine/sun4 in the source tree right now. You can copy the corresponding line from there if you want to try it out. Let me know if you have any other questions or issues.

[tschak909]

Thanks, after grabbing latest pull, doing an autoreconf --install, ./configure and a make, I am getting some libltdl weirdness :(

touch plugins
  CCLD     tmesh
/usr/bin/ld: /tmp/cc6mL3BQ.ltrans0.ltrans.o: undefined reference to symbol 'lt_dlpreload_default'
/usr/bin/ld: /usr/local/lib/libltdl.so.7: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:631: tmesh] Error 1

[tschak909]

I had to pass the following to configure:

LDFLAGS="-Wl,--copy-dt-needed-entries" ./configure

[tschak909]

I think this can be closed now. Thank you. -Thom