Bug in SqueakSource mailer service?

Hi Christoph,

On Mon, Oct 12, 2020 at 11:34:04AM +0000, Thiede, Christoph wrote:
I do not know the answer to your question, but based on my experience
supporting the old squeaksource.com server (which has until recently
been running on an older image and squeaksource code base), I would
not be surprised to find bugs like this related to improper handling
of WideString in squeaksource.

In earlier years, squeaksource.com was being used heavily by students
for Pharo-based classroom assignments. User names that (quite properly)
used WideString for the user name would cause failures in the squeaksource
application, and I would have to "fix" these problems by converting
the usernames to plausible 8-bit strings in the squeaksource.com image.
These failures happened quite frequently for a number of years after
the Pharo community moved to smalltalkhub.com, because squeaksource.com
was still being used to support classroom projects.

On source.squeak.org we did not ever have these issues, possibly because
it was running on a newer Squeak image with better support for WideString,
or possibly simply because the active developers on source.squeak.org
have been in the habit of avoiding the use of international character
sets in their commits.

My guess is that you have uncovered a bug in SqueakSqueak that simply
has not been noticed until now.

Dave

Hi Christoph,

On Mon, Oct 12, 2020 at 11:34:04AM +0000, Thiede, Christoph wrote:
> Hi all,
>
>
> that's funny. I uploaded EToys-ct.409, whiches removes some invalid encoding characters from a method comment, half an hour ago and it did not appear in the mailing list. However, Monticello-ct.731 which I uploaded some minutes later appeared on the list as usual. Do we have some bug in the mailer service code that stumbled upon the special characters in the method comment?
>
>
> Here is the (manually created) diff:
>
>
>   assureContentAreaStaysAt: aPoint
> -  "selbst-verst????????????????????????????ndlich"
>
> self currentWorld doOneCycleNow.
> self topLeft: ((self topLeft - contentArea topLeft ) + aPoint)
>

I do not know the answer to your question, but based on my experience
supporting the old squeaksource.com server (which has until recently
been running on an older image and squeaksource code base), I would
not be surprised to find bugs like this related to improper handling
of WideString in squeaksource.

In earlier years, squeaksource.com was being used heavily by students
for Pharo-based classroom assignments. User names that (quite properly)
used WideString for the user name would cause failures in the squeaksource
application, and I would have to "fix" these problems by converting
the usernames to plausible 8-bit strings in the squeaksource.com image.
These failures happened quite frequently for a number of years after
the Pharo community moved to smalltalkhub.com, because squeaksource.com
was still being used to support classroom projects.

On source.squeak.org we did not ever have these issues, possibly because
it was running on a newer Squeak image with better support for WideString,
or possibly simply because the active developers on source.squeak.org
have been in the habit of avoiding the use of international character
sets in their commits.

My guess is that you have uncovered a bug in SqueakSqueak that simply
has not been noticed until now.

Dave

Hi Christoph,

On Mon, Oct 12, 2020 at 09:45:31PM +0000, Thiede, Christoph wrote:
> Hi Dave,
>
>
> a naive question: Why isn't SqueakSource running on an automatically
> updated Trunk image, maybe only pulling updates that were approved by
> a CI process? Wasn't it worth the effort? :-)
>

That is a good and fair question. I will try to answer it from the
point of view of my historical role in adopting and maintaining the
old squeaksource.com service, with CC to Chris who has been maintaining
source.squeak.org, and who is more involved in championing a disciplined
release process for our main source.squeak.org server.

Answering from my own point of view in maintaining the ancient
squeaksource.com service, my answer is no, it would not have been
worth the effort to maintain a CI process. I know and understand the
value of CI and have used it for VM development (earlier years, not
now), and I use it today for non-Squeak work (outside the scope of
this discussion).  CI is hugely beneficial, and for many projects,
I could not live without it. But is is also a lot of work. Like
anything else, CI needs to be maintained.

The squeaksource.com service is an interesting case. It is radically
different from the typical Java-style deployment environment, because
*eveything* lives in the Squeak image that provides the service. If
something goes wrong, it will have gone wrong in the image, not in
the many layers of services and infrastructure that support it. For
that reason, I was able to keep it running for many years with very
little effort. I made periodic updates and bug fixes, and I updated
the underlying image a couple of times over the years, but overall
I was able to keep it reasonaably healthy with a very modest amount
of time and effort.

Moving forward, it might make sense to put services like this onto
a more CI basis, with more frequent updates and testing. But you
(or others) should do this if and only if you are prepared to invest
the time and effort to maintain the CI infrastructure on an ongoing
basis. That can be a lot of work.

Aside from that word of caution, I would also say that it would now
possible and practical of maintain the (formerly ancient) squeaksource.com
image with continuous integration and testing. Unlike the situation
in earlier years, it is now running on a Squeak 5.3 image, so keeping
it up to date with trunk is now a feasible thing.

If someone wants to step forward and volunteer to set up and
maintain the CI infrastructure, I will be happy to support the effort.
But to be clear, I do not want to be the person doing that work,
especially not on a long term basis.

Dave