Problem solved, thanks.
I created a harfbuzz.cc inside the go package directory, it contains only
one line
#include "harfbuzz/src/harfbuzz.cc"
and then change the cgo header to:
/*
#cgo CFLAGS: -Iharfbuzz/src
#cgo CXXFLAGS: -std=c++11
#cgo LDFLAGS: -lstdc++
#include
#include "hb.h"
#includ
I'm trying to embed the harfbuzz(http://github.com/harfbuzz/harfbuzz)
library source code into go package,
just like what the glfw(http://github.com/go-gl/glfw) library does.
The difference is that glfw contains only C, but harfbuzz is actually a C++
library and provide C API.
My cgo header cod
On Sat, Dec 14, 2019 at 7:40 PM wrote:
>
> I need to spawn a subprocess and I'm trying to use os/exec. I need to capture
> stdout/err so I'm using Cmd.StdoutPipe and Cmd.StderrPipe . The problem I'm
> having is how to correctly clean up the pipes after I am done. If Cmd.Start
> works fine, all I n
Hello,
I need to spawn a subprocess and I'm trying to use os/exec. I need to
capture
stdout/err so I'm using Cmd.StdoutPipe and Cmd.StderrPipe . The problem I'm
having is how to correctly clean up the pipes after I am done. If Cmd.Start
works fine, all I need to do is read everything and then cal
On Sat, Dec 14, 2019 at 11:51 AM wrote:
>
> If I understand correctly, that would prevent me from starting any other
> goroutines. The following program deadlocks:
That turns out not to be the case. You can start other goroutines.
Your program deadlocks because you called time.After when you me
I found some existing discussion on this topic:
https://github.com/golang/go/issues/14163
Not sure I fully understand the reasoning there. If there is a better way
forward that doesn't involve adding a controversial function to the
scheduling package, I'm all ears.
On Saturday, December 14, 2
Would it be reasonable to make a Go proposal that adds something like
runtime.MainThread(), which would cause the calling goroutine to only ever
be scheduled on the main thread? Unlike runtime.LockOSThread, it would not
need to prevent other goroutines from running on the main thread (I think).
If I understand correctly, that would prevent me from starting any other
goroutines. The following program deadlocks:
package main
import (
"log"
"runtime"
"time"
)
func init() {
runtime.LockOSThread()
}
func main() {
go func() {
for range time.After(time.Second) {
I think you are right. Thanks.
On Sat, 2019-12-14 at 19:20 +, Paul Jolly wrote:
> > This seem massively over complicated, so I'm wondering if there is
> > an
> > easier way.
>
> I think you're after types.Universe.Lookup("error")?
>
>
> Paul
>
--
You received this message because you are
On Sat, Dec 14, 2019 at 11:31 AM wrote:
>
> I'd really love to get that LockOSThread call out of the main function and
> hide it away inside a library along with the other internal implementation
> details. Is that possible? As far as I can tell, it's not possible to ensure
> that a goroutine r
I've been experimenting with graphics programming using go+sdl2 for awhile
now. I've always been uncertain how to deal with locking a goroutine to the
main thread. MacOS requires interactions with the OS window to come from
the main thread.
So far, I have something like this (pseudocode):
fun
> This seem massively over complicated, so I'm wondering if there is an
> easier way.
I think you're after types.Universe.Lookup("error")?
Paul
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving e
I think I must have asked this really badly.
I don't want a reflect.Type of an error, I want a types.Type
representation of error for performing static analysis.
The playground that I imagine is necessary is something like this.
https://play.golang.org/p/e-FU0_4J9jK
This seem massively over com
https://play.golang.org/p/pdjKMn__ufA
On Sat, Dec 14, 2019 at 10:07 AM Dan Kortschak wrote:
> In the go/types package there is an easy way to obtain a types.Type for
> basic builtin types. This doesn't exist for the error type.
>
> Is there an easier way to get a types.Type representing error th
whoops, I misread :) types.Type,, not reflect :)
On Sat, Dec 14, 2019 at 6:54 PM Axel Wagner
wrote:
> https://play.golang.org/p/pdjKMn__ufA
>
> On Sat, Dec 14, 2019 at 10:07 AM Dan Kortschak wrote:
>
>> In the go/types package there is an easy way to obtain a types.Type for
>> basic builtin typ
Error is an interface, so its type depends on the implementation satisfying
that interface. You can't just create an "error", since they don't exist,
all that exists are implementation satisfying the error interface. That's
what you're doing with NewSignature.
Could you just create an implementati
They probably do, but only for database-related products, or maybe for software
in general. Trademarks are industry-specific.
Andy
> On Dec 13, 2019, at 9:22 PM, kddavidson...@gmail.com wrote:
>
> I would be surprised if they have a legal claim to "Ora" as well, otherwise
> the dental products
Taken from
https://www.iana.org/assignments/tls-parameters/tls-parameters.xml:
Note
>
> CCM_8 cipher suites are not marked as "Recommended". These
> cipher suites have a significantly truncated authentication tag
> that represents a security trade-off that may not be appropriate
>
In the go/types package there is an easy way to obtain a types.Type for
basic builtin types. This doesn't exist for the error type.
Is there an easier way to get a types.Type representing error than by
using NewInterfaceType, NewFunc and NewSignature functions (I am
assuming that the nil *types.Pa
19 matches
Mail list logo
