[OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
 

A bit of context: For Squeak, I am currently implementing full-fledged handling of DND events sent by the host system. Actually, Squeak only handles SQDragDrop at the moment.

However, when logging all received DND events on the image side, I discovered that whenever a file is dropped into the VM, after the last SQDragMove an SQDragLeave is received before the eventual SQDragDrop. This looks very suspicious to me. Neither does the same happen on any other platform (tested on Win32, too), nor does it appear logical to me in any way. If I release the mouse button over the image, the drag did not leave, so a "drag leave" should not be recorded.

This MR makes sure that in dndInDrop(), an SQDragLeave event is only recorded if the drop was not successful. (Please note that the SQDragDrop event itself will be sent in a deferred manner; dndInDrop() itself only calls XConvertSelection() from the X-Server which then will send a SelectionNotify which will trigger dndGetSelection() and eventually have generateSqueakDropEventIfDroppedFiles() called.)

Please review carefully, as I am a bloody VM newbie and this is my very first commit to this repo! :-) Mentioning @eliotmiranda who appears to be the code owner of this plugin, according to the file's history.

Todos:

  • Think about backward compatibility: Squeak did not respect any of the drag events but SQDragDrop until today, and I'm reworking that handling ATM, so there will be no problem. But are there other users of this plugin that could rely on the old behavior which I consider a bug? Or does the sq in the prefix unambiguously stand for Squeak?
  • Are there any tests I could run to make sure that this change cannot break anything else?

You can view, comment on, or merge this pull request online at:

  https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508

Commit Summary

  • Fix a typo
  • Comment out suspicious line
  • Merge branch 'Cog' into sqUnixXdnd
  • Refactor changes
  • Don't skip SQDragLeave if XGetSelectionOwner failed

File Changes

Patch Links:


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
 

@LinqLover pushed 1 commit.

  • e2be1e8 Don't skip SQDragLeave if XGetSelectionOwner failed


You are receiving this because you are subscribed to this thread.
View it on GitHub or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508/files/cb852fe26b0fa1e363bf2e62961da6644ea9833b..e2be1e85adaa5da536f665cf4a05655c0a0658da", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508/files/cb852fe26b0fa1e363bf2e62961da6644ea9833b..e2be1e85adaa5da536f665cf4a05655c0a0658da", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

Ehm, all the pharo builds are failing. Is this my fault?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-643603279", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-643603279", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

@nicolas-cellier-aka-nice Would you mind to have a short look at this? :-)


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-650434309", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-650434309", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

Concerning Pharo, you did not break anything.
External libraries are precompiled on the CI in some cache.
When version number of those libraries are update, the cache is not automatically cleared.
Therefore, the failure is postponed until the cache is cleared, which happens on a regular schedule apparently.

Concerning sq, we did not want to change each and every prefix to osvm when we switched squeak vm to osvm.
It would have touched each and every file and the VMMaker and all plugin repositories, for not much added value.
Who knows how many regressions could have been un-noticed.
So do not consider sq* as Squeak only.

Concerning DND, it's beyond my skill, I've never studied its logic nor particular sequence of events.
What you say sounds logical, and consistent VM behavior is desirable though.
So if you say that you compiled, used the VM and saw no regression in an official release (say drop a .png in Squeak 5.3), I can do the merge (and squash).

Ideally we should do it on an old version of pharo too (7?), but at one moment, pharo people shall help us to help them, and this is not the trend. The INRIA team forked, and when I request community help on Opensmalltalk-vm-dev ML, I ear nothing but a big silence, I guess no one is interested. Newspeak sounds less like a problem, because they use their own form of FFI for windows system integration rather than plugin.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-650611001", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-650611001", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

@LinqLover pushed 2 commits.

  • aafdc28 Only record SQDragLeave xor SQDragDrop
  • 4def9a6 Merge remote-tracking branch 'origin/Cog' into sqUnixXdnd


You are receiving this because you are subscribed to this thread.
View it on GitHub or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508/files/e2be1e85adaa5da536f665cf4a05655c0a0658da..4def9a65347638fe002deb5cfb92d00fa532145c", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508/files/e2be1e85adaa5da536f665cf4a05655c0a0658da..4def9a65347638fe002deb5cfb92d00fa532145c", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

Thank you for the detailed explanations, @nicolas-cellier-aka-nice!

you say that you compiled, used the VM and saw no regression in an official release (say drop a .png in Squeak 5.3)

Yes, I confirm that.

Newspeak sounds less like a problem, because they use their own form of FFI for windows system integration rather than plugin.

What is about Cuis?

consistent VM behavior is desirable though

Hm, please don't merge yet. I just found further small inconsistencies in this implementation I would like to fix within this PR. I will update the description when I am done and mention you again. :-)


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-650783530", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-650783530", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Fwd: [Lse-consortium] [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

Nicolas Cellier
In reply to this post by smalltalking
 

Hmm,
I forward this because I thought that I answered on vm-dev...
but of course, pharo team cannot follow this ML for obvious reasons, and prefer obscure ML not even listed here https://lists.gforge.inria.fr/mailman/listinfo, maybe a private ML unless it's a typo?

---------- Forwarded message ---------
De : Nicolas Cellier <[hidden email]>
Date: dim. 28 juin 2020 à 15:52
Subject: Re: [Lse-consortium] [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)
To: Stéphane Ducasse <[hidden email]>
Cc: Mailinglist for consortium engineering <[hidden email]>


Hi Stephane,

please read carefully 'Ridiculous failure...' thread on OpenSmalltalk VM dev mailing list.
> The job exceeded the maximum log length, and has been terminated.
We know that the CI set up is not good, it leads to these ridiculous failures.
Solutions have been sketched for a long time, but never implemented in the original opensmalltalk-vm repository.

And of course, this kind of solution has been implemented in the pharo fork meanwhile...
So a problem coming from the way pharo is built on opensmalltalk, is solved only in the fork shortly after the fork.
A sign that it was not so complex to solve after all?
This change was not contributed back. Why is that?
Do you think it's a good thing to let pharo build rotting in original repo?

Yes, this attitude upsets me. I helped fixing pharo builds upstream, "cleaning after the dog of someone else" as I said.
But no one in Pharo community will never help and contribute back?
Or take at least time to answer when I request support?
You know the French saying, "trop bon, trop con", that's exactly how I feel at the moment.

Le dim. 28 juin 2020 à 12:15, Stéphane Ducasse <[hidden email]> a écrit :
Hi nicolas

When did you requested something? and that we did not react. 
Most of us are in following the vm-dev for obvious reason.
We cannot be insulted on regular basis and be treated as guys that do not understand 
on discord. 
For my particular case,  I decided that pasted 50 I do not accept this anymore. 

S. 


On 27 Jun 2020, at 23:47, Christophe Demarey <[hidden email]> wrote:

In case you missed it:

Début du message réexpédié :

De: Nicolas Cellier <[hidden email]>
Objet: Rép : [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)
Date: 27 juin 2020 à 21:42:02 UTC+2
À: OpenSmalltalk/opensmalltalk-vm <[hidden email]>
Cc: Subscribed <[hidden email]>
Répondre à: OpenSmalltalk/opensmalltalk-vm <[hidden email]>, Open Smalltalk Virtual Machine Development Discussion <[hidden email]>

Ideally we should do it on an old version of pharo too (7?), but at one moment, pharo people shall help us to help them, and this is not the trend. The INRIA team forked, and when I request community help on Opensmalltalk-vm-dev ML, I ear nothing but a big silence, I guess no one is interested. Newspeak sounds less like a problem, because they use their own form of FFI for windows system integration rather than plugin.

_______________________________________________
Lse-consortium mailing list
[hidden email]
https://lists.gforge.inria.fr/mailman/listinfo/lse-consortium

--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

Regarding code ownership - there currently is nobody specifically tending to the unix VM, or the X window display system. Most of the code is more than 15 years old, written by Ian Piumarta. Others and I contributed smaller parts over the years. That history got lost when switching from svn to git.

As for DND, at some point around 2007 it was working fully - you could drag pictures and rich text into Squeak (e.g. a paragraph from Wikipedia), and you could drag e.g. a morph out of Squeak into an office document (where it would appear as a bitmap image) or onto another Squeak (where it would appear as fully functioning object, all the scripts etc. were being serialized). The latter part might be why there are squeak-specific DnD events.

This was used for full interoperability inside of the Sugar OS on the OLPC laptop. E.g. you could drag a morph out of Etoys onto the Sugar Frame Clipboard, switch apps, and drag it into the other app. I used to be the maintainer of Squeak/Etoys for Sugar but haven’t touched it in years.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655021654", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655021654", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

@codefrau This is very interesting to hear! For starters, my goal is to translate every incoming drag into a transfer morph that can be handled natively by any morph. However, reviving the full potential of DnD will be a very interesting follow-up project. If you have further information on how this could break all without anyone noticing, please tell me. :-) Do you know whether all platforms already supported this?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655369005", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655369005", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

I don't remember if all platforms supported this. Your best bet is to try with Etoys from Squeakland. This one here includes VMs for Win, Mac, and Linux: http://www.squeakland.org/content/installers/Etoys-To-Go-5.0.zip


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655400308", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655400308", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

Which VM version is that? On Windows, DnD works as well as in the latest OSVM. Unfortunately, I cannot find a 64 bit version for Linux, so I cannot test Etoys To Go on Linux ...


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655430452", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655430452", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

Hey @LinqLover, you should be able to get it to run on a 64bit linux as well. When running it will report which libraries are currently not installed in 32bit, on my system this was the only step necessary to get it to run: sudo apt install libxrender1:i386 libpangocairo-1.0-0:i386

In general, once you know which libraries cannot be loaded, you can run for example ldd Contents/Linux-i686/so.vm-display-X11 to see which of its dependencies are missing and then install those via apt-get with the :i386 suffix.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655433619", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655433619", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

@tom95 The message only I'm seeing is:

$ ./etoys.sh
./etoys.sh: line 107: ./Contents/Linux-i686/etoys: cannot execute binary file: Exec format error

ldd gives me not a dynamic executable. Does native Linux support more backward compatibility in terms of architecture than a virtualized Linux? I am using Ubuntu in Windows Subsystem for Linux.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655441484", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655441484", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

Oh okay, in that case this might be your best bet: https://superuser.com/questions/1407730/run-32-bit-application-on-ubuntu-on-windows-subsystem-for-linux


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655447927", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655447927", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

@tom95 Great to know that WSL2 supports this. I still have to set up this, thank you :)


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655479646", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655479646", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

smalltalking
In reply to this post by smalltalking
 

Inside Etoys-To-Go are old 32 Bit interpreter VMs, from before Cog was around. You need those to be able to run the Etoys image. On Linux, there used to be a simple way to install the 32 bit support even on a 64 bit system, but I don’t know what the current status is.

That Etoys image might have some more support code for DnD handling than current Squeak. Not everything has been properly integrated back. @timfel did the bulk of that work.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655665680", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508#issuecomment-655665680", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

David T. Lewis
 
On Wed, Jul 08, 2020 at 10:50:57AM -0700, Vanessa Freudenberg wrote:
>  
> Inside Etoys-To-Go are old 32 Bit interpreter VMs, from before Cog was around. You need those to be able to run the Etoys image. On Linux, there used to be a simple way to install the 32 bit support even on a 64 bit system, but I don???t know what the current status is.
>
> That Etoys image might have some more support code for DnD handling than current Squeak. Not everything has been properly integrated back. @timfel did the bulk of that work.
>

The old interpreter VM in the Etoys-To_Go distribution still works fine
on Ubuntu 16.04 LTS.  I have 32-bit libraries installed as described in
Tom Beckman's earlier reply.

If you want to run Etoys on a native 64-bit VM, follow the instructions
at http://wiki.squeak.org/squeak/6354. It takes about 5 or 10 minutes to
do this, so allow yourself an hour of free time before you start, because
nothing ever goes right the first time

As a side note, Windows does a very good job of providing run-time backward
compatibility for old applications, so a Squeak running on a very old Windows
VM will almost always work. On Unix systems in general, and Linux in particular,
there is very good source-level portability but backward compatibility
for old compiled executables is not as good. The supporting runtime libraries
tend to get updated regularly, and after 5 or 10 years you can easily end up
with a compiled executable with runtime linkages to libraries that are no
longer present.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

Tobias Pape
 

> On 09.07.2020, at 03:17, David T. Lewis <[hidden email]> wrote:
>
>
> On Wed, Jul 08, 2020 at 10:50:57AM -0700, Vanessa Freudenberg wrote:
>>
>> Inside Etoys-To-Go are old 32 Bit interpreter VMs, from before Cog was around. You need those to be able to run the Etoys image. On Linux, there used to be a simple way to install the 32 bit support even on a 64 bit system, but I don???t know what the current status is.
>>
>> That Etoys image might have some more support code for DnD handling than current Squeak. Not everything has been properly integrated back. @timfel did the bulk of that work.
>>
>
> The old interpreter VM in the Etoys-To_Go distribution still works fine
> on Ubuntu 16.04 LTS.  I have 32-bit libraries installed as described in
> Tom Beckman's earlier reply.
>
> If you want to run Etoys on a native 64-bit VM, follow the instructions
> at http://wiki.squeak.org/squeak/6354. It takes about 5 or 10 minutes to
> do this, so allow yourself an hour of free time before you start, because
> nothing ever goes right the first time
>
> As a side note, Windows does a very good job of providing run-time backward
> compatibility for old applications, so a Squeak running on a very old Windows
> VM will almost always work. On Unix systems in general, and Linux in particular,
> there is very good source-level portability but backward compatibility
> for old compiled executables is not as good. The supporting runtime libraries
> tend to get updated regularly, and after 5 or 10 years you can easily end up
> with a compiled executable with runtime linkages to libraries that are no
> longer present.

BTW: Fedora ships a 64bit squeak interpreter vm that can run 323bit closure  and non-closure images.
Except for a broken Rome-plugin, this works very fine for Etoys 5.0…

Best regards
        -Tobias
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)

David T. Lewis
 
On Thu, Jul 09, 2020 at 07:19:32AM +0200, Tobias Pape wrote:

>  
>
> > On 09.07.2020, at 03:17, David T. Lewis <[hidden email]> wrote:
> >
> >
> > On Wed, Jul 08, 2020 at 10:50:57AM -0700, Vanessa Freudenberg wrote:
> >>
> >> Inside Etoys-To-Go are old 32 Bit interpreter VMs, from before Cog was around. You need those to be able to run the Etoys image. On Linux, there used to be a simple way to install the 32 bit support even on a 64 bit system, but I don???t know what the current status is.
> >>
> >> That Etoys image might have some more support code for DnD handling than current Squeak. Not everything has been properly integrated back. @timfel did the bulk of that work.
> >>
> >
> > The old interpreter VM in the Etoys-To_Go distribution still works fine
> > on Ubuntu 16.04 LTS.  I have 32-bit libraries installed as described in
> > Tom Beckman's earlier reply.
> >
> > If you want to run Etoys on a native 64-bit VM, follow the instructions
> > at http://wiki.squeak.org/squeak/6354. It takes about 5 or 10 minutes to
> > do this, so allow yourself an hour of free time before you start, because
> > nothing ever goes right the first time
> >
> > As a side note, Windows does a very good job of providing run-time backward
> > compatibility for old applications, so a Squeak running on a very old Windows
> > VM will almost always work. On Unix systems in general, and Linux in particular,
> > there is very good source-level portability but backward compatibility
> > for old compiled executables is not as good. The supporting runtime libraries
> > tend to get updated regularly, and after 5 or 10 years you can easily end up
> > with a compiled executable with runtime linkages to libraries that are no
> > longer present.
>
> BTW: Fedora ships a 64bit squeak interpreter vm that can run 323bit closure  and non-closure images.
> Except for a broken Rome-plugin, this works very fine for Etoys 5.0???
>

That's interesting, I did not know about that. If you get a chance,
could you please check the version information for that VM? Either
the contents of a system reporter in the image, or from the command
line "/usr/bin/squeak -version" (assuming it is installed in /usr/bin).

At one time there was a Debian package for the interpreter VM, but
it was badly broken, so it would be nice to know if someone has been
distributing one that works.

Thank you!
Dave
 
12