Interesting. I have no idea how the GC would interact with "Go-aware" C
code.
I suppose the hardest thing about the new compiler would be to emulate what
Go does at blocking system calls to not actually block the whole process.
(Notice somehow, and start a new thread; not sure if this is still
True. I was collapsing the two because why does Go care. If the routine is in a
C native call don’t switch the routine assigned to the thread. Similarly. If
the thread is in C native it can’t affect stacks / heap structures - so
routines that make C calls only need to ensure a C minimum stack
On Sun, Mar 14, 2021 at 1:46 PM Robert Engels wrote:
>
> That was my point, based on Java, there is the ability to make the GC
> coordination extremely efficient a read and two writes per Go to C complete
> call trip - and this can often be eliminated in tight loops.
I don't mean to drag out
Thanks for your explanation, that's very helpful :-)
On Friday, March 12, 2021 at 3:03:00 PM UTC+8 axel.wa...@googlemail.com
wrote:
> On Fri, Mar 12, 2021 at 4:55 AM messi...@gmail.com
> wrote:
>
>> Does it use for generics constraints only?
>
>
> That is my understanding.
>
>
>> As
On Sat, Mar 13, 2021 at 9:25 AM Space A. wrote:
>
> And Russ didn't write academic paper regarding it (before accepting proposal
> in less than a month after it was published). =)
There may be some confusion here. Are you referring to the
Featherweight Go paper
On Sat, Mar 13, 2021 at 7:59 AM Space A. wrote:
>
> You are a smart guy, one of the smartest I have ever talked to. But it looks
> like you somehow missed a very obvious thing. The people you mentioned (and
> most of the so-called Go team) AFAIK are Google employees. They work for a
> company
On Sat, Mar 13, 2021 at 7:19 AM Space A. wrote:
>
> > The discussion of whether or not generics will be added to Go has been
> > going on for more than a decade.
> That's a lie. There has never been a question of "add it or not". It was
> always "we will add them" sooner or later.
Please
Hello everyone.
I have a question about a common programming error I have made several
times. It regards the use of a pointer to a loop variable outside of the
loop. Basically, we want to convert a slice, map, or channel of items (the
source sequence) into a map, slice, or channel of pointers
I considered generics so important to our workflow that I added it quite
some time ago, Go is an implementation language, you may implement anything
you like with it. If you do not like the way it does something, you can use
it to create a different language, that is what real programmers do.
Hi,
I am currently thinking about implementing SSR for a Go client-side
framework.
Not only that but I would like to be able to create static html from the
same code I use to create dynamic wasm-based webapps.
I was trying to find a package that would enable me to generate an html
document
On Sun, 2021-03-14 at 15:08 -0700, Pascal de Kloe wrote:
> > Did you consider using context.Context rather than quit channels?
>
> Applying a context.Context pretty much implies using a quit channel.
> Done is the only way to receive an expiry signal.
>
> I just don't want to lock code into using
>
> Did you consider using context.Context rather than quit channels?
Applying a context.Context pretty much implies using a quit channel. Done
is the only way to receive an expiry signal.
I just don't want to lock code into using the context package. The context
setup is quite viral. For
Now that a proposal for an approach to generics has been approved[1],
it seems like a good time to again[2] raise the issue of how to be able
to write code that has correlated types where types are structured but
built-in, and so fields are not available to examine. The only case of
this in the
On Sun, 2021-03-14 at 10:41 -0700, Pascal de Kloe wrote:
> New MQTT client library + command line tool available.
>
> https://github.com/pascaldekloe/mqtt
>
> Comments are welcome.
Did you consider using context.Context rather than quit channels?
--
You received this message because you are
That was my point, based on Java, there is the ability to make the GC
coordination extremely efficient a read and two writes per Go to C complete
call trip - and this can often be eliminated in tight loops.
So if the scheduling is the source of inefficiency there are more simple ways
to
On Sun, Mar 14, 2021 at 12:00 PM Robert Engels wrote:
>
> Based on two decades of Java FFI - the overhead comes from type mapping not
> the housekeeping to control GC. The latter can be as simple as a volatile
> read and 2 writes per call and can usually be coalesced in tight loops. Since
> Go
Based on two decades of Java FFI - the overhead comes from type mapping not the
housekeeping to control GC. The latter can be as simple as a volatile read and
2 writes per call and can usually be coalesced in tight loops. Since Go already
has easy native C type mapping the FFi should be very
New MQTT client library + command line tool available.
https://github.com/pascaldekloe/mqtt
Comments are welcome.
--
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 email
> I'm no authority here, but I believe a large (major?) part of the Cgo
overhead is caused by scheduling overhead. As I understand it, a C function
call is non-preemptible and the Go runtime don't know whether the call will
block.
But that part would be handled by the C-compiler-that-knows-Go
On Sun, 14 Mar 2021 12:56:43 +0100
"Elias Naur" wrote:
> > It incentivises us to rewrite C codebases into proper Go.
> Rewriting (and maintaining!) mature and well-maintained libraries is
> impractical.
> Rewriting platform-bound APIs (OpenGL, Cocoa) is impossible.
> A rewrite is one thing,
There's something to be said to the notion of being able to better inter-op
with C code bases, though.
If we had a C compiler written in Go (like modernc.org/cc perhaps), integrated
with the Go compiler (yes, that's an additional maintenance issue), that would
spit off Go-compatible ASM, then
hi,
I recently wanted to get the juice out of some programs.
A queue consumer that transforms inputs over many routines,
then aggregates the results to re order them.
The order is defined by the input order.
There was many variations written around it,
using a map, a slice, a regular heap,
On Sun Mar 14, 2021 at 13:03, Jan Mercl wrote:
> On Sun, Mar 14, 2021 at 12:57 PM Elias Naur wrote:
>
> > > Eg. if you really need to hook at battle-tested C code that needs no
> > > further maintenance, you may try https://github.com/minio/c2goasm
> > > It lets you bootstrap fast, then you may
On Sun, Mar 14, 2021 at 12:57 PM Elias Naur wrote:
> > Eg. if you really need to hook at battle-tested C code that needs no
> > further maintenance, you may try https://github.com/minio/c2goasm
> > It lets you bootstrap fast, then you may aim at a proper rewrite.
> >
>
> A rewrite is one
On Sun Mar 14, 2021 at 12:30, Wojciech S. Czarnecki wrote:
> On Sat, 13 Mar 2021 22:57:11 -0800 (PST)
> "Jason E. Aten" wrote:
>
> > Iminimize the cost of crossing the CGO barrier from Go code into C code and
> > back.
>
> I personally regard this cost as godsend ;) It incentivises us to rewrite
On Sat, 13 Mar 2021 22:57:11 -0800 (PST)
"Jason E. Aten" wrote:
> Iminimize the cost of crossing the CGO barrier from Go code into C code and
> back.
I personally regard this cost as godsend ;) It incentivises us to rewrite C
codebases into proper Go.
> Instead of teaching the Go compiler
вс, 14 мар. 2021 г. в 01:38, 'Axel Wagner' via golang-nuts
:
>
> One thing I would add is that you'll likely want to use the *Stable versions
> of the sort functions, to make sure the order of equivalent elements does not
> change.
> Apart from that, the solution posted by Carla above with an
On Sunday, 14 March 2021 at 07:57:12 UTC+1 Jason E. Aten wrote:
> I was noodling about how to minimize the cost of crossing the CGO barrier
from Go code into C code and back.
> Then I thought, what if I look at this the other way around.
> Instead of teaching the Go compiler how to better run
Hello Tim.
Translating, that's a hobbyhorse I ride now and then.
(Learn something new about Go and improve your English and German in
parallel! ;-)
No, sorry. There is no public repository. The private one right here under
my desk is ... well ... private.
Now, about you taking up translating:
29 matches
Mail list logo
