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 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 This MR makes sure that in 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:
You can view, comment on, or merge this pull request online at:https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508 Commit Summary
File ChangesPatch Links:
— |
@LinqLover pushed 1 commit.
— |
In reply to this post by David T Lewis
Ehm, all the pharo builds are failing. Is this my fault? — |
In reply to this post by David T Lewis
@nicolas-cellier-aka-nice Would you mind to have a short look at this? :-) — |
In reply to this post by David T Lewis
Concerning Pharo, you did not break anything. Concerning sq, we did not want to change each and every prefix to osvm when we switched squeak vm to osvm. Concerning DND, it's beyond my skill, I've never studied its logic nor particular sequence of events. 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. — |
In reply to this post by David T Lewis
@LinqLover pushed 2 commits.
— |
In reply to this post by David T Lewis
Thank you for the detailed explanations, @nicolas-cellier-aka-nice!
Yes, I confirm that.
What is about Cuis?
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. :-) — |
In reply to this post by David T Lewis
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 :
|
In reply to this post by David T Lewis
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. — |
In reply to this post by David T Lewis
@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? — |
In reply to this post by David T Lewis
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 — |
In reply to this post by David T Lewis
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 ... — |
In reply to this post by David T Lewis
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: In general, once you know which libraries cannot be loaded, you can run for example — |
In reply to this post by David T Lewis
@tom95 The message only I'm seeing is:
— |
In reply to this post by David T Lewis
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 — |
In reply to this post by David T Lewis
@tom95 Great to know that WSL2 supports this. I still have to set up this, thank you :) — |
In reply to this post by David T Lewis
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. — |
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 |
> 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 |
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 |
Free forum by Nabble | Edit this page |