Order confirmation
<<< image/gif: EXCLUDED >>>
Re: Mathematical Statistics Functions for libgo
* Arjunlal M. A.: > I was wondering if libgo contained any modules for high precision > statistics functions. If it doesn't, would implementing something like that > really necessary? I think these functions would have to go into the mainline Go codebase first before they appear in libgo. Thanks, Florian
Order Confirmation,
<<< image/gif: EXCLUDED >>>
Request to deprecate offloading to HSAIL in GCC
Hello, HSAIL - the intermediate language bit of HSA - has not been much of a success. I don't know about anybody using it, planning to use it or being interested in any way, except possibly me. There really isn't any finalizer targeting GPUs (or APUs), the one we use to test HSAIL generation is a proprietary executable hacked into an old HSA run-time in a way that makes me afraid to touch the computers set up this way. The HSAIL code generation is fortunately mostly a rather separate bit of code which does not really cause much trouble. That is, except the OpenMP bits which is how we feed the HSA back-end and which were unfortunately badly designed (mostly by me) and very likely will soon pose big problems during implementation of new OpenMP features. They have to go away. Right at the beginning of the next stage 1, I will set aside a few days to try and change the OpenMP bits of HSA offloading to something similar to what we use for NVPTX. But I will not hide that I plan to do it mostly so that I learn something new, a few days is probably not enough, and generally speaking, I do not think that any big effort invested into HSAIL is now worth it. Therefore it is only fair to warn the community and any possible hidden users or would-be users that it is very likely that I will propose removal of HSAIL offloading in the course of GCC 11 development cycle and I would like to formally deprecate it. So how is it done, by proposing a patch to changes.html? Note that this deprecation does not include the BRIG front-end. That does not cause any real problems that I am aware of and I think that at least at this point we can and should keep it. Thanks, Martin
Re: Not usable email content encoding
* Maciej W. Rozycki: > On Tue, 7 Apr 2020, Christopher Faylor wrote: > >> >In a way that's amusing and just reinforces my p.o.v. that DMARC is >> >bollocks. >> >> Not that it means anything but I agree 100%. >> >> It's like whoever made the "standard" just said "to hell with mailing >> lists". > > Maybe they just didn't know of their existence. Seriously. I think that's extremely unlikely. If you do not do header munging in the mailing list software, things will work. That suggests to me that the people who worked on DKIM and DMARC had this use case in mind. But of course if you add subject prefixes, rewrite attachments (and thus the message body), or enable the Mailman duplicate suppression feature (which edits To:/Cc: lists of the messages posted to the list), then things will break. But that's not required to run a mailing list.
Re: Request to deprecate offloading to HSAIL in GCC
On Thu, Apr 09, 2020 at 07:43:02PM +0200, Martin Jambor wrote: > Therefore it is only fair to warn the community and any possible hidden > users or would-be users that it is very likely that I will propose > removal of HSAIL offloading in the course of GCC 11 development cycle > and I would like to formally deprecate it. LGTM. > So how is it done, by proposing a patch to changes.html? I'd say so. Jakub
Re: Can we please have the old mailing list back
On 4/2/20 10:06 AM, Andreas Schwab wrote: > On Apr 02 2020, Bernd Edlinger wrote: > >> What happens to the e-mails when they are not archive, but forwarded >> to the subscribers, like mark.info who just subscribes the mails, >> and archived them they have a lot of hard disks for that and can >> handle attachments quite well. The point is previously the attachment >> were stored on marc.info, but now they are no longer reaching mark.info >> we mangle the e-mails that we do not archive. > > You should reach out to the maintainers of mark.info and ask them how > they receive the messages. On gmane.io, all mails were received in > their complete, unmangled form. > Interesting point with gmane.io, do they have a web-interface? I do not want to do the NNTP blues, you know ;-) Thanks Bernd. > Andreas. >