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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Jul 7 09:20:53 UTC 2020

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 <nicolas.cellier.aka.nice at gmail.com>
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 <stephane.ducasse at inria.fr>
Cc: Mailinglist for consortium engineering <
lse-consortium at lists.gforge.inria.fr>

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
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
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 <stephane.ducasse at inria.fr>
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 <Christophe.Demarey at inria.fr>
> wrote:
> In case you missed it:
> Début du message réexpédié :
> *De: *Nicolas Cellier <notifications at github.com>
> *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 <opensmalltalk-vm at noreply.github.com>
> *Cc: *Subscribed <subscribed at noreply.github.com>
> *Répondre à: *OpenSmalltalk/opensmalltalk-vm <
> Smalltalk Virtual Machine Development Discussion <
> vm-dev at lists.squeakfoundation.org>
> 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
> Lse-consortium at lists.gforge.inria.fr
> https://lists.gforge.inria.fr/mailman/listinfo/lse-consortium
> --------------------------------------------
> Stéphane Ducasse
> http://stephane.ducasse.free.fr / http://www.pharo.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200707/22cda301/attachment-0001.html>

More information about the Vm-dev mailing list