I don't whether establishing a community based workgroup would help Go to
gain wider acceptance or not. Java has its JCP program and Python has PEP
which seem to work in a fashion.
However, I certainly think that this sort of approach would be preferable
to formal standardization which I am co
What you've just suggested there has the makings of a decent proposal in
itself :)
But I think it would inevitably mean that the built-in types would need to
have methods or at least pseudo-methods for special purposes.
Of course, it may that this is a problem which isn't really worth solving
I can assure you that my concern is not theoretical but based on real life
experience. Unfortunately I am not at liberty to discuss in detail...
As for the approach, a community based workgroup with backing from Google may
be a more viable idea.
--
You received this message because you are sub
I guess that would be a workaround, but a Go to, say , Ada transpiler is not an
easy project. Still, something to consider.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
Java and python have become so common that all but the most hard headed
bureaucrats have to acknowledge those languages, if only for the ease of hiring
people who can program in them.
The same cannot be said yet of Ruby and Go, which are far less popular.
Hopefully that will change, but for th
I see, I did not realize that in the USA, the standardization organizations
expect to take control over the language. That is not very good. I understand
people's concerns better now.
The Ruby standard was submitted through the Japanese standard organization
which was far more sympathetic and f
Quoting alan.f...@gmail.com (2018-10-13 15:39:46)
>Unfortunately, no approach is immune to silly mistakes by yours truly
>but, as it's an area where "Effective Go" could offer some pointers, it
>need not be unduly error prone in practice.
Still, some approaches are more error prone th
Thanks for posting that very interesting link, Robert.
I'd remembered that Sun originally attempted to standardize Java in the
late 1990s but later withdrew it. However, I didn't know their reasons for
this until now.
Alan
On Saturday, October 13, 2018 at 7:10:42 PM UTC+1, robert engels wrote:
Thanks for your comments, Ian.
Unfortunately, no approach is immune to silly mistakes by yours truly but,
as it's an area where "Effective Go" could offer some pointers, it need not
be unduly error prone in practice.
The problem with associating operators with named methods is that there
will
Quoting alanfo (2018-10-13 13:26:18)
>Suppose we turn this strategy on its head and instead allow types which
>wouldn't otherwise do so support the ordering operators provided they
>satisfy a simple interface. This interface would have a single method
>which returned a string repr
This may be of interest
https://www.computer.org/csdl/proceedings/hicss/2001/0981/05/09815015.pdf
> On Oct 13, 2018, at 12:18 PM, alanfo wrote:
>
> May I remind those who are in favor of Go standardization that Java and
> Python have never been standardized by ISO/ANSI/ECMA but that hasn't
>
On 10/13/18, Aram Hăvărneanu wrote:
> Window's font rendering is simply wrong. Linux's is very similar to
> macOS's.
Do you mean anything else besides this?
https://www.joelonsoftware.com/2007/06/12/font-smoothing-anti-aliasing-and-sub-pixel-rendering/
Do you maybe have any objectively checkable a
A problem with the draft generics design (and with most of the alternative
proposals including my own) is that, without operator overloading, there
appears to be no way to unify the sorting functions.
This is because only the numeric and string types support the ordering
operators (<, <=, >=, >
May I remind those who are in favor of Go standardization that Java and
Python have never been standardized by ISO/ANSI/ECMA but that hasn't
prevented them from becoming extremely successful languages.
I find it hard to believe that there are large organizations in this day
and age who eschew t
Just ignore this thread.
I've figured it out.
On Saturday, October 13, 2018 at 12:38:53 PM UTC+2, changkun wrote:
>
> Hi golang nuts:
>
> In "mstart", there is a call "mexit" after "mstart1".
> Howeverm "mstart1" will be entering sched loop and never returns.
>
> So, my question is when will "mex
on mac (and I suppose linux too) you can use fontsrv to extract the
plan 9 font files as acme sees them. on my mac I did:
$ fontsrv -m font
$ acme -f font/GoMono/12a/font
here are screenshots of GoRegular and GoMono in 12a:
https://imgur.com/a/7xnGrmx
I will send you privately a tar of GoMono/1
Window's font rendering is simply wrong. Linux's is very similar to macOS's.
I tried the Go fonts in acme, but reverted to Lucida Grande.
--
Aram Hăvărneanu
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and sto
I know rog has already asked about this before and I am not sure if
it's feasible or not, but I ask, maybe someone has already thought of
a good resolution:
I'd like to use Go fonts on acme (plan9port linux), but fontsrv(4)'s
antialiased output is rather blurry at least compared to Windows'
Cleart
Thank you, I probably will use them in the future of more migrations~
cheers, changkun
On Sunday, September 30, 2018 at 12:06:09 AM UTC+2, K Davidson wrote:
>
> Not sure if it would be of any help, but maybe you can gleem some insight
> from the way these packages did things?
>
> https://github.
Hi,
Thanks for your recommendations, very interesting implementation :)
I solved the problem with a callback from c to go to c.
cheers, changkun
On Saturday, September 29, 2018 at 6:27:08 PM UTC+2, ohir wrote:
>
> On Fri, 28 Sep 2018 22:27:04 -0700 (PDT)
> changkun > wrote:
>
> > Not really,
Hi,
sorry for late response. Your solution is very inspiration! I solved the
problem
with letting pango call entering go domain and lock on os thread, then back
to c domain.
Thank you very much!
cheers, changkun
On Saturday, September 29, 2018 at 6:16:10 PM UTC+2, Tamás Gulácsi wrote:
>
>
> 2
Hi golang nuts:
In "mstart", there is a call "mexit" after "mstart1".
Howeverm "mstart1" will be entering sched loop and never returns.
So, my question is when will "mexit" be executed? How?
mstart1()
// Exit this thread.
if GOOS == "windows" || GOOS == "solaris" || GOOS == "plan9" || GOOS ==
On 13 Oct 2018, at 00:57, Ian Lance Taylor
mailto:i...@golang.org>> wrote:
So, as a general rule, it's a good idea for
any package to enforce that it is imported under a particular import
path.
I strongly disagree with this point. In my experience, import path comments are
used to enforce the
23 matches
Mail list logo
