[go-nuts] guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

The Conn and UDPConn Read methods look like io.Reader Read methods, but
there is no explicit claim that Conn is an io.Reader. Are the Read
methods of these two types identical in behaviour to io.Reader?
Specifically, are the reads allowed to fill the buffer with arbitrary
numbers of bytes in 0 <= len(p) <= n?

Also, can UPDConn.Read fill the buffer with more than one packet if the
buffer would accommodate that? (I am guessing yes, and that if this is
important then the ReadFrom method should be used).

thanks
Dan

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1557384824.4298.19.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to run a go method on multiple cores ?

[Kurtis Rader]

On Wed, May 8, 2019 at 10:17 PM Nitish Saboo 
wrote:

> Yes, I want (exactly) two instances of syslog-ng engines running since I
> initialised the engine twice.And I guess it is possible only when the
> syslog-ng engines are running on two different processors.I might be wrong
> here, please correct me if my understanding is not right.
> My goal right now is how to verify if two independent syslog-ng engines
> are getting initialised or not ?
> Once this verification is done, Can we hook instance 'a' to syslog-ng
> engine on processor 'a' and instance 'b' to syslog-ng engine on processor
> 'b'.
>

There may be a human language barrier here in as much as my native language
is English and I suspect your native language is something else. Whether or
not you instantiate two distinct syslog-ng engines is unrelated to which
CPUs (processors) each runs on. There is no way, in general, for the Go
scheduler to know which CPU a goroutine is running on. Nor is there any way
to bind a goroutine to a specific CPU as far as I know. You could (in
theory) create two distinct instances of the syslog-ng engine and they
could still execute on the same CPU. If or no other reason than that your
system only has a single CPU core available for your process.

> I hope I am able to clarify my thinking here.

No, sorry, you have not. If anything every reply you make increases the
confusion about what you are trying to do. If your `*initialize_engine()`
method always instantiates, and returns, a new instance of the "syslog-ng"
engine then the two Go objects initialized by that call will be two
independent instances of that engine. Assuming, of course, that your
syslog-ng engine does not share state between distinct `**initialize_engine()`
calls.*

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD_s54b%3DUcprekRMWXGZvRv%3D51E6XsgM8u9yd3XQHtTZ%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to run a go method on multiple cores ?

[Nitish Saboo]

Hi Michael,

Yes, I want (exactly) two instances of syslog-ng engines running since I
initialised the engine twice.And I guess it is possible only when the
syslog-ng engines are running on two different processors.I might be wrong
here, please correct me if my understanding is not right.
My goal right now is how to verify if two independent syslog-ng engines are
getting initialised or not ?
Once this verification is done, Can we hook instance 'a' to syslog-ng
engine on processor 'a' and instance 'b' to syslog-ng engine on processor
'b'.
I hope I am able to clarify my thinking here.

Thanks


On Thu, May 9, 2019 at 4:01 AM Michael Jones 
wrote:

> Can you share a little more of your motivation for saying: “I want two
> instances of syslog-ng engine running on two different processors.”
>
> Do you mean (minimum) that you want two independent instances, or
> (maximum) that you want to prove that there are two instances, two physical
> processors, and that at no time does processor “a” execute code on behalf
> of instance “b” and likewise for processor “b” and instance “a”, (or
> something else completely).
>
> This “proof” idea seems very unusual but also seems to be what you want.
> Maybe it is not. That’s why it might be good to share more of your thinking
> and not just the conclusion.
>
> The natural thing in most every situation with modern CPUs, OSs, and non
> hard real-time applications, is just having enough total CPU resources for
> the mix of work and enough independence (concurrency opportunity) in the
> application so that the load can be magically balanced.
>
> If this is not enough for you then you must have special circumstances.
>
> On Wed, May 8, 2019 at 2:47 AM Nitish Saboo 
> wrote:
>
>> Hi Marvin,
>>
>> Thanks for your response.
>>
>> "Do you mean "log/syslog" from the standard library?  What does
>> initialize do?"
>>
>> >>I have installed syslog-ng parser on my Linux box and I am planning you
>> use syslog-ng parser and wanted to initialise it's engine for parsing the
>> data.
>>
>> so initialise() method in my Go code calls  C code that is wrapper around
>> syslog-ng C header files.So ,I am making use of cgo
>>
>> *Following is my Go code:*
>>
>> func (obj Syslogparser) initialise{
>>
>> X := C.CString(obj.X)
>> defer C.free(unsafe.Pointer(X))
>> Y := C.CString(obj.Y)
>> defer C.free(unsafe.Pointer(Y))
>> C.initialize_engine(X, Y,
>> (C.key_value_cb)(unsafe.Pointer(C.callOnMeGo_cgo)));
>> }
>>
>> *And following is my C method 'initialize_engine':*
>>
>> int initialize_engine(const gchar* X, const gchar* Y, key_value_cb cb) //
>> cb is callback function
>> {
>> // does some operation for initialising the engine of syslog-ng parser
>>   return 0;
>> }
>>
>> 1)I want two instances of syslog-ng engine running on two different
>> processors.How can I achieve this?
>>
>> 2)I made the following change :
>>
>> func main {
>> var obj1 Syslogparser  = initalize() // This initialises syslog-ng 
>> engine.call
>> to a C library via cgo
>> var obj2 Syslogparser// Not a package-level variable
>> obj1.ParseMessage(program,msg)// this will parse the data and get the
>> result
>> if result["Z"] == "unknown"{ // On the basis of this result I want to
>> initialise a new engine
>> go func() {
>>  opts := Syslog{}
>> obj2 = initalize() //call to a C library via cgo
>> obj2.ReloadPatternDB(opts)  //call to a C library via cgo
>> obj2.ParseMessage(program, msg) //call to a C library via cgo
>> }()
>> }
>> }
>>
>> Will this initialise two different syslog-ng engines for me ?
>>
>> 3)I understand goroutines are not OS threads and they just run on OS
>> threads.Can we extract the process id of the running syslog-ng engines
>> within the go routine where it spawned the syslog-ng engine ?
>>
>> Thanks
>>
>>
>> On Wed, May 8, 2019 at 3:01 AM Marvin Renich  wrote:
>>
>>> * Nitish Saboo  [190507 14:07]:
>>> > Thanks Michel for your detailed response.
>>> > I am initialising the syslog engine.
>>>
>>> Do you mean "log/syslog" from the standard library?  What does
>>> initialize do?
>>>
>>> > var obj1 parser  = initalize()
>>> > var obj2 parser
>>> > go func() {
>>> > obj2 = initalize()
>>> > }()
>>>
>>> You have initialized obj1, then you create a go routine that initializes
>>> obj2.  Assuming the initialization step takes a relatively short amount
>>> of time and terminates, and does not itself create another go routine,
>>> obj2 is not "on another go routine" (or thread or CPU or anything else).
>>> It is simply another variable whose value was assigned by a different go
>>> routine, but that go routine terminated immediately after obj2 was given
>>> its value.
>>>
>>> Note that obj2 is a variable, not a running function; it is not
>>> associated with a specific go routine, at least not in the sense that
>>> you appear to be thinking.  If obj2 is declared at the package level,
>>> than any function in the package can reference it regardless of the go
>>> routine in which that function is running.
>>>
>>

Re: [go-nuts] Re: A question about A sync.Once implementation.

[White Pure]

Hi, 
You are right, I did some modification to your code and make it able to 
reproduce everytime: https://play.golang.org/p/y6vxC_DNjp9
Thanks!

在 2019年5月8日星期三 UTC+8下午7:15:26，rog写道：
>
> It seems clear to me that C ("can run but has not implemented the 
> singleton pattern, function f may run multi times") is not the correct 
> answer, because I'm pretty sure that f cannot run more than once.
>
> However, it's still not a correct Once implementation, because as has 
> already been pointed out, the Do method can return before the function has 
> completed.
>
> The reason why f cannot run more than once is that if you *don't* have 
> the initial non-atomic test of o.done, then the function cannot run more 
> than once, and the extra condition only reduces the number of times that f 
> can be called.
>
> The implementation would be incorrect even if the `o.done = 1` assignment 
> was moved before the call to f, because there's no happens-before 
> relationship between the `o.done == 1` check and either of the statements 
> within the mutex. This means that it's possible for the `o.done == 1` check 
> to report true but for the caller to see memory that indicates that f 
> hasn't been called.
>
> If you run this code with the race detector enabled, it will report an 
> error. That should be good enough reason not to use code like this.
>
> Here's a complete example: https://play.golang.org/p/vWVXzRBPMNe
> The question is: according to the Go memory model, what's the set of 
> possible things that that program can print?
>
> I think it could print "unexpected value 0" but not "unexpected value 2".
>
>
> On Wed, 8 May 2019 at 05:49, Kurtis Rader  > wrote:
>
>> On Tue, May 7, 2019 at 9:42 PM White Pure > > wrote:
>>
>>> Hi,
>>> Thanks for your reply.
>>> The second bug is a known issue, so let’s ignore that. In that case, 
>>> I think function f still can only be executed once.
>>> But why does the load and store of o.done need to be done using 
>>> atomic operations? I suppose there’s mutex assuring the happens-before.
>>>
>>
>> You seem to be using two different email accounts to comment on this 
>> thread. That is confusing, at best, and sock puppeting, at worst. Don't do 
>> that.
>>
>> Also, your text in the message I am replying to is in a very light grey 
>> color. Which makes it hard to read on a white background. Please don't use 
>> styled text that modifies the colors on a general purpose mailing list. Not 
>> everyone is using color preferences compatible with your preferences.
>>  
>> -- 
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
>> -- 
>> 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 to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD8hZAt0DRyrTEnunU2%3D6_y2hheDB48RZft7BAS4a7fEcg%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cded8904-87b2-4c1f-8b69-e40b51bdbaf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Could someone tell me how to build gollvm?

[Yuan Ting]

Oh, my mistake. I can successfully build gollvm now, thank you so much!

On Thursday, May 9, 2019 at 11:07:37 AM UTC+8, Than McIntosh wrote:
>
> There was a recent checkin related to -fdebug-go-optimization in both 
> repos-- I think the failure you're seeing is just build skew.
> Try doing a "git pull" in llvm/tools/gollvm and 
> llvm/tools/gollvm/gofrontend to make sure everything is up to date.
> Thanks, Than
>
>
> *From: *Ting Yuan >
> *Date: *Wed, May 8, 2019 at 10:10 PM
> *To: *golang-nuts
>
> Hi Than,
>> It turned out to be the problem of shell. By SHELL=/bin/sh I can build 
>> gollvm in the right way, but I still failed on a compile error:
>>
>> [2066/3237] Building CXX object tools/gollvm/bridge/CMakeFiles/
>> LLVMCppGoFrontEnd.dir/__/gofrontend/go/go.cc.o
>> FAILED: tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/__/
>> gofrontend/go/go.cc.o 
>> /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE 
>> -D__STDC_CONSTANT_MACROS 
>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/gollvm/bridge -I/
>> home/yt/LLVMsvn/llvm/tools/gollvm/bridge -I/usr/include/libxml2 -Iinclude 
>> -I/home/yt/LLVMsvn/llvm/include -Itools/gollvm/external/install/include -
>> I/home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go -fPIC -fvisibility-
>> inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra 
>> -Wno-unused-parameter 
>> -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -
>> Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-
>> noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color 
>> -g-fno-exceptions -fno-rtti -MD -MT tools/gollvm/bridge/CMakeFiles/
>> LLVMCppGoFrontEnd.dir/__/gofrontend/go/go.cc.o -MF tools/gollvm/bridge/
>> CMakeFiles/LLVMCppGoFrontEnd.dir/__/gofrontend/go/go.cc.o.d -o tools/
>> gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/__/gofrontend/go/go.cc.o -c 
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go/go.cc
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go/go.cc: In function ‘void 
>> go_create_gogo(const go_create_gogo_args*)’:
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go/go.cc:47:13: error: ‘
>> const struct go_create_gogo_args’ has no member named ‘debug_optimization
>> ’
>>   if (args->debug_optimization)
>> ^~
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go/go.cc:48:42: error: ‘
>> const struct go_create_gogo_args’ has no member named ‘debug_optimization
>> ’
>> ::gogo->set_debug_optimization(args->debug_optimization);
>>  ^~
>> [2069/3237] Building CXX object tools/gollvm/bridge/CMakeFiles/
>> LLVMCppGoFrontEnd.dir/__/gofrontend/go/gogo.cc.o
>> ninja: build stopped: subcommand failed.
>>
>>
>> I checked the structure go_create_gogo_args (in gollvm/bridge/go-c.h) and 
>> there really wasn't a field called debug_optimization there. Could I add 
>> this field in go_create_gogo_args so I can let the build progress continue?
>>
>> Thanks.
>>
>> On Thursday, May 9, 2019 at 12:21:42 AM UTC+8, Than McIntosh wrote:
>>>
>>> Agree, the embedded space looks fishy.
>>>
>>> I also note that your shell is set to zsh -- you might try instead using 
>>> SHELL=/bin/sh to see if that works better.
>>>
>>> Thanks, Than
>>>
>>>
>>>
>>>
>>> On Wed, May 8, 2019 at 12:04 PM Ting Yuan  wrote:
>>>
 OK, I got something like
 ...
 /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(55):  if(NOT 
 EXISTS /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid )
 /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(57):  else()
 /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(58):  
 set(tool_target gotools_cmd_buildid )
 /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(62):  
 execute_process(COMMAND /usr/bin/zsh 
 /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/match.sh 
 --goarch=amd64 
 --goos=linux 
 --srcdir=/home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid
  
 OUTPUT_VARIABLE toolfiles ERROR_VARIABLE errmsg RESULT_VARIABLE exitstatus 
 )
 /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(68):  if(NOT 
 0 MATCHES 0 )
 /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(71):  
 string(STRIP  
 /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid/ 
 buildid.go doc.go
  toolfiles )
 /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(72):  
 separate_arguments(toolfiles )
 ...

 I found that the absolute path of buildid.go is illegal (there is a 
 space before the filename). This looks like the root cause.

 On Wednesday, May 8, 2019 at 11:46:09 PM UTC+8, Than McIntosh wrote:
>
> Hmm, OK, sounds like 'sed' is not the issue.
>
> >>I found there are only two files (CMakeLists.txt and 
> gotestprogram.sh) under the llvm/tools/gollvm/gotools/. Should the 
> missing 
> files (e.g. buildid.go) be th

Re: [go-nuts] Could someone tell me how to build gollvm?

['Than McIntosh' via golang-nuts]

There was a recent checkin related to -fdebug-go-optimization in both
repos-- I think the failure you're seeing is just build skew.
Try doing a "git pull" in llvm/tools/gollvm and
llvm/tools/gollvm/gofrontend to make sure everything is up to date.
Thanks, Than


*From: *Ting Yuan 
*Date: *Wed, May 8, 2019 at 10:10 PM
*To: *golang-nuts

Hi Than,
> It turned out to be the problem of shell. By SHELL=/bin/sh I can build
> gollvm in the right way, but I still failed on a compile error:
>
> [2066/3237] Building CXX object tools/gollvm/bridge/CMakeFiles/
> LLVMCppGoFrontEnd.dir/__/gofrontend/go/go.cc.o
> FAILED: tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/__/gofrontend
> /go/go.cc.o
> /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE 
> -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/gollvm/bridge -I/home
> /yt/LLVMsvn/llvm/tools/gollvm/bridge -I/usr/include/libxml2 -Iinclude -I/
> home/yt/LLVMsvn/llvm/include -Itools/gollvm/external/install/include -I/
> home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go -fPIC -fvisibility-inlines
> -hidden -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -
> Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-
> long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type
> -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -g
> -fno-exceptions
> -fno-rtti -MD -MT tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/__/
> gofrontend/go/go.cc.o -MF tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd
> .dir/__/gofrontend/go/go.cc.o.d -o tools/gollvm/bridge/CMakeFiles/
> LLVMCppGoFrontEnd.dir/__/gofrontend/go/go.cc.o -c /home/yt/LLVMsvn/llvm/
> tools/gollvm/gofrontend/go/go.cc
> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go/go.cc: In function ‘void
> go_create_gogo(const go_create_gogo_args*)’:
> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go/go.cc:47:13: error: ‘
> const struct go_create_gogo_args’ has no member named ‘debug_optimization’
>   if (args->debug_optimization)
> ^~
> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go/go.cc:48:42: error: ‘
> const struct go_create_gogo_args’ has no member named ‘debug_optimization’
> ::gogo->set_debug_optimization(args->debug_optimization);
>  ^~
> [2069/3237] Building CXX object tools/gollvm/bridge/CMakeFiles/
> LLVMCppGoFrontEnd.dir/__/gofrontend/go/gogo.cc.o
> ninja: build stopped: subcommand failed.
>
>
> I checked the structure go_create_gogo_args (in gollvm/bridge/go-c.h) and
> there really wasn't a field called debug_optimization there. Could I add
> this field in go_create_gogo_args so I can let the build progress continue?
>
> Thanks.
>
> On Thursday, May 9, 2019 at 12:21:42 AM UTC+8, Than McIntosh wrote:
>>
>> Agree, the embedded space looks fishy.
>>
>> I also note that your shell is set to zsh -- you might try instead using
>> SHELL=/bin/sh to see if that works better.
>>
>> Thanks, Than
>>
>>
>>
>>
>> On Wed, May 8, 2019 at 12:04 PM Ting Yuan  wrote:
>>
>>> OK, I got something like
>>> ...
>>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(55):  if(NOT
>>> EXISTS /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid )
>>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(57):  else()
>>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(58):
>>> set(tool_target gotools_cmd_buildid )
>>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(62):
>>> execute_process(COMMAND /usr/bin/zsh
>>> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/match.sh --goarch=amd64
>>> --goos=linux
>>> --srcdir=/home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid
>>> OUTPUT_VARIABLE toolfiles ERROR_VARIABLE errmsg RESULT_VARIABLE exitstatus )
>>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(68):  if(NOT 0
>>> MATCHES 0 )
>>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(71):
>>> string(STRIP
>>> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid/
>>> buildid.go doc.go
>>>  toolfiles )
>>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(72):
>>> separate_arguments(toolfiles )
>>> ...
>>>
>>> I found that the absolute path of buildid.go is illegal (there is a
>>> space before the filename). This looks like the root cause.
>>>
>>> On Wednesday, May 8, 2019 at 11:46:09 PM UTC+8, Than McIntosh wrote:

 Hmm, OK, sounds like 'sed' is not the issue.

 >>I found there are only two files (CMakeLists.txt and
 gotestprogram.sh) under the llvm/tools/gollvm/gotools/. Should the missing
 files (e.g. buildid.go) be there?

 No, this is expected. The Go sources for 'buildid' will be pulled from
 /tools/gollvm/gofrontend/libgo/go/cmd/buildid.

 At this point what I would recommend to gather more info: rerun cmake
 and pass it the "--trace-expand" flag, e.g.

 cmake --trace-expand -DCMAKE_BUILD_TYPE=Debu

[go-nuts] Type safe and modularize way to generate html on server side.

[Felix Sun]

https://github.com/theplant/htmlgo

A few benefits with this approach than html/template

- Compiled type safe
- Fast as go itself
- Not possible to generate unmatched html tags
- No need to manage template files, and caring about it's path etc
- Easier to modularize, any component can be purely funcs

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADdyq2x9Cdv2da8-Mm4EuYbC50vbtBzNXsiX8YBETLY1-R5SvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Could someone tell me how to build gollvm?

[Ting Yuan]

Hi Than,
It turned out to be the problem of shell. By SHELL=/bin/sh I can build 
gollvm in the right way, but I still failed on a compile error:

[2066/3237] Building CXX object tools/gollvm/bridge/CMakeFiles/
LLVMCppGoFrontEnd.dir/__/gofrontend/go/go.cc.o
FAILED: tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/__/gofrontend/
go/go.cc.o 
/usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/gollvm/bridge -I/home/
yt/LLVMsvn/llvm/tools/gollvm/bridge -I/usr/include/libxml2 -Iinclude -I/home
/yt/LLVMsvn/llvm/include -Itools/gollvm/external/install/include -I/home/yt/
LLVMsvn/llvm/tools/gollvm/gofrontend/go -fPIC -fvisibility-inlines-hidden -
Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings 
-Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -
Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-
non-virtual-dtor -Wno-comment -fdiagnostics-color -g-fno-exceptions -fno
-rtti -MD -MT tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/__/
gofrontend/go/go.cc.o -MF tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.
dir/__/gofrontend/go/go.cc.o.d -o tools/gollvm/bridge/CMakeFiles/
LLVMCppGoFrontEnd.dir/__/gofrontend/go/go.cc.o -c /home/yt/LLVMsvn/llvm/
tools/gollvm/gofrontend/go/go.cc
/home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go/go.cc: In function ‘void 
go_create_gogo(const go_create_gogo_args*)’:
/home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go/go.cc:47:13: error: ‘const 
struct go_create_gogo_args’ has no member named ‘debug_optimization’
  if (args->debug_optimization)
^~
/home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/go/go.cc:48:42: error: ‘const 
struct go_create_gogo_args’ has no member named ‘debug_optimization’
::gogo->set_debug_optimization(args->debug_optimization);
 ^~
[2069/3237] Building CXX object tools/gollvm/bridge/CMakeFiles/
LLVMCppGoFrontEnd.dir/__/gofrontend/go/gogo.cc.o
ninja: build stopped: subcommand failed.


I checked the structure go_create_gogo_args (in gollvm/bridge/go-c.h) and 
there really wasn't a field called debug_optimization there. Could I add 
this field in go_create_gogo_args so I can let the build progress continue?

Thanks.

On Thursday, May 9, 2019 at 12:21:42 AM UTC+8, Than McIntosh wrote:
>
> Agree, the embedded space looks fishy.
>
> I also note that your shell is set to zsh -- you might try instead using 
> SHELL=/bin/sh to see if that works better.
>
> Thanks, Than
>
>
>
>
> On Wed, May 8, 2019 at 12:04 PM Ting Yuan > 
> wrote:
>
>> OK, I got something like
>> ...
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(55):  if(NOT 
>> EXISTS /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid )
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(57):  else()
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(58):  
>> set(tool_target gotools_cmd_buildid )
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(62):  
>> execute_process(COMMAND /usr/bin/zsh 
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/match.sh --goarch=amd64 
>> --goos=linux 
>> --srcdir=/home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid 
>> OUTPUT_VARIABLE toolfiles ERROR_VARIABLE errmsg RESULT_VARIABLE exitstatus )
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(68):  if(NOT 0 
>> MATCHES 0 )
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(71):  
>> string(STRIP  
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid/ 
>> buildid.go doc.go
>>  toolfiles )
>> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(72):  
>> separate_arguments(toolfiles )
>> ...
>>
>> I found that the absolute path of buildid.go is illegal (there is a space 
>> before the filename). This looks like the root cause.
>>
>> On Wednesday, May 8, 2019 at 11:46:09 PM UTC+8, Than McIntosh wrote:
>>>
>>> Hmm, OK, sounds like 'sed' is not the issue.
>>>
>>> >>I found there are only two files (CMakeLists.txt and gotestprogram.sh) 
>>> under the llvm/tools/gollvm/gotools/. Should the missing files (e.g. 
>>> buildid.go) be there?
>>>
>>> No, this is expected. The Go sources for 'buildid' will be pulled from 
>>> /tools/gollvm/gofrontend/libgo/go/cmd/buildid.
>>>
>>> At this point what I would recommend to gather more info: rerun cmake 
>>> and pass it the "--trace-expand" flag, e.g.
>>>
>>> cmake --trace-expand -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold 
>>> ../llvm
>>>
>>> Be warned that this will produce a huge amount of output (~40M or so). 
>>> Sift through the output and see if you can find the place where it is 
>>> trying to locate the source files for the buildid tool by running 
>>> 'match.sh'. Should look something like
>>>
>>> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(55):  if(NOT EXISTS 
>>> /root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid )

Re: [go-nuts] How to run a go method on multiple cores ?

[Michael Jones]

Can you share a little more of your motivation for saying: “I want two
instances of syslog-ng engine running on two different processors.”

Do you mean (minimum) that you want two independent instances, or (maximum)
that you want to prove that there are two instances, two physical
processors, and that at no time does processor “a” execute code on behalf
of instance “b” and likewise for processor “b” and instance “a”, (or
something else completely).

This “proof” idea seems very unusual but also seems to be what you want.
Maybe it is not. That’s why it might be good to share more of your thinking
and not just the conclusion.

The natural thing in most every situation with modern CPUs, OSs, and non
hard real-time applications, is just having enough total CPU resources for
the mix of work and enough independence (concurrency opportunity) in the
application so that the load can be magically balanced.

If this is not enough for you then you must have special circumstances.

On Wed, May 8, 2019 at 2:47 AM Nitish Saboo 
wrote:

> Hi Marvin,
>
> Thanks for your response.
>
> "Do you mean "log/syslog" from the standard library?  What does
> initialize do?"
>
> >>I have installed syslog-ng parser on my Linux box and I am planning you
> use syslog-ng parser and wanted to initialise it's engine for parsing the
> data.
>
> so initialise() method in my Go code calls  C code that is wrapper around
> syslog-ng C header files.So ,I am making use of cgo
>
> *Following is my Go code:*
>
> func (obj Syslogparser) initialise{
>
> X := C.CString(obj.X)
> defer C.free(unsafe.Pointer(X))
> Y := C.CString(obj.Y)
> defer C.free(unsafe.Pointer(Y))
> C.initialize_engine(X, Y,
> (C.key_value_cb)(unsafe.Pointer(C.callOnMeGo_cgo)));
> }
>
> *And following is my C method 'initialize_engine':*
>
> int initialize_engine(const gchar* X, const gchar* Y, key_value_cb cb) //
> cb is callback function
> {
> // does some operation for initialising the engine of syslog-ng parser
>   return 0;
> }
>
> 1)I want two instances of syslog-ng engine running on two different
> processors.How can I achieve this?
>
> 2)I made the following change :
>
> func main {
> var obj1 Syslogparser  = initalize() // This initialises syslog-ng engine.call
> to a C library via cgo
> var obj2 Syslogparser// Not a package-level variable
> obj1.ParseMessage(program,msg)// this will parse the data and get the
> result
> if result["Z"] == "unknown"{ // On the basis of this result I want to
> initialise a new engine
> go func() {
>  opts := Syslog{}
> obj2 = initalize() //call to a C library via cgo
> obj2.ReloadPatternDB(opts)  //call to a C library via cgo
> obj2.ParseMessage(program, msg) //call to a C library via cgo
> }()
> }
> }
>
> Will this initialise two different syslog-ng engines for me ?
>
> 3)I understand goroutines are not OS threads and they just run on OS
> threads.Can we extract the process id of the running syslog-ng engines
> within the go routine where it spawned the syslog-ng engine ?
>
> Thanks
>
>
> On Wed, May 8, 2019 at 3:01 AM Marvin Renich  wrote:
>
>> * Nitish Saboo  [190507 14:07]:
>> > Thanks Michel for your detailed response.
>> > I am initialising the syslog engine.
>>
>> Do you mean "log/syslog" from the standard library?  What does
>> initialize do?
>>
>> > var obj1 parser  = initalize()
>> > var obj2 parser
>> > go func() {
>> > obj2 = initalize()
>> > }()
>>
>> You have initialized obj1, then you create a go routine that initializes
>> obj2.  Assuming the initialization step takes a relatively short amount
>> of time and terminates, and does not itself create another go routine,
>> obj2 is not "on another go routine" (or thread or CPU or anything else).
>> It is simply another variable whose value was assigned by a different go
>> routine, but that go routine terminated immediately after obj2 was given
>> its value.
>>
>> Note that obj2 is a variable, not a running function; it is not
>> associated with a specific go routine, at least not in the sense that
>> you appear to be thinking.  If obj2 is declared at the package level,
>> than any function in the package can reference it regardless of the go
>> routine in which that function is running.
>>
>> > if obj1 engine fails:
>> > go func() {
>> > obj2.ReloadPattern(opts)
>> > }()
>> >
>> > My question is, will obj2.ReloadPattern reload the pattern on the second
>> > syslog-engine , how can I verify that?Because I am not maintaining the
>> > engine info. I am just having the parser object.
>> > Will parser object obj2 go and reload the respective syslog engine that
>> was
>> > initialised by it? I guess yes, but still need clarification on this .
>>
>> A new go routine will be created (possibly unnecessarily, but you don't
>> give enough information), and the ReloadPattern method of obj2 will be
>> invoked in that go routine.  When ReloadPattern terminates, the go
>> routine will also terminate.  obj2 is still a package-level variable (or
>> associated with whate

Re: [go-nuts] Re: Does fmt.Fprint use WriteString ?

[Marvin Renich]

[Sorry for the late reply; I was having technical difficulties!]

* Louki Sumirniy  [190503 10:39]:
> A lot of people clearly don't know this, also - there is a builtin print() 
> and println() function in Go. If the output is stdout, these are probably 
> the most efficient ways to thow strings at it.

FYI, these are documented at https://golang.org/ref/spec#Bootstrapping

  Current implementations provide several built-in functions useful
  during bootstrapping. These functions are documented for completeness
  but are not guaranteed to stay in the language. They do not return a
  result.

So, if you use print and println, be aware that they are not really
intended for production use and are not covered by the language
compatibility guarantee.

...Marvin

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20190503160605.sx3obnjdjjq3ppvz%40lynx.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Could someone tell me how to build gollvm?

['Than McIntosh' via golang-nuts]

Agree, the embedded space looks fishy.

I also note that your shell is set to zsh -- you might try instead using
SHELL=/bin/sh to see if that works better.

Thanks, Than




On Wed, May 8, 2019 at 12:04 PM Ting Yuan  wrote:

> OK, I got something like
> ...
> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(55):  if(NOT
> EXISTS /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid )
> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(57):  else()
> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(58):
> set(tool_target gotools_cmd_buildid )
> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(62):
> execute_process(COMMAND /usr/bin/zsh
> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/match.sh --goarch=amd64
> --goos=linux
> --srcdir=/home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid
> OUTPUT_VARIABLE toolfiles ERROR_VARIABLE errmsg RESULT_VARIABLE exitstatus )
> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(68):  if(NOT 0
> MATCHES 0 )
> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(71):
> string(STRIP
> /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid/
> buildid.go doc.go
>  toolfiles )
> /home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(72):
> separate_arguments(toolfiles )
> ...
>
> I found that the absolute path of buildid.go is illegal (there is a space
> before the filename). This looks like the root cause.
>
> On Wednesday, May 8, 2019 at 11:46:09 PM UTC+8, Than McIntosh wrote:
>>
>> Hmm, OK, sounds like 'sed' is not the issue.
>>
>> >>I found there are only two files (CMakeLists.txt and gotestprogram.sh)
>> under the llvm/tools/gollvm/gotools/. Should the missing files (e.g.
>> buildid.go) be there?
>>
>> No, this is expected. The Go sources for 'buildid' will be pulled from
>> /tools/gollvm/gofrontend/libgo/go/cmd/buildid.
>>
>> At this point what I would recommend to gather more info: rerun cmake and
>> pass it the "--trace-expand" flag, e.g.
>>
>> cmake --trace-expand -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold
>> ../llvm
>>
>> Be warned that this will produce a huge amount of output (~40M or so).
>> Sift through the output and see if you can find the place where it is
>> trying to locate the source files for the buildid tool by running
>> 'match.sh'. Should look something like
>>
>> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(55):  if(NOT EXISTS
>> /root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid )
>> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(57):  else()
>> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(58):  set(tool_target
>> gotools_cmd_buildid )
>> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(62):
>> execute_process(COMMAND /bin/bash
>> /root/llvm/tools/gollvm/gofrontend/libgo/match.sh --goarch=amd64
>> --goos=linux
>> --srcdir=/root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid
>> OUTPUT_VARIABLE toolfiles ERROR_VARIABLE errmsg RESULT_VARIABLE exitstatus )
>> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(68):  if(NOT 0 MATCHES 0 )
>> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(71):  string(STRIP
>> /root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid/buildid.go
>> /root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid/doc.go
>>  toolfiles )
>>
>> I am thinking that maybe there is something going wrong with the
>> invocation of 'match.sh' in your case that is throwing things off.
>>
>> Thanks, Than
>>
>>
>>
>> On Wed, May 8, 2019 at 11:30 AM Ting Yuan  wrote:
>>
>>> Hi Than,
>>>
>>> On my system the version of sed is 4.4. Is the version mismatch?
>>>
>>> I found there are only two files (CMakeLists.txt and gotestprogram.sh)
>>> under the llvm/tools/gollvm/gotools/. Should the missing files (e.g.
>>> buildid.go) be there?
>>>
>>> Thanks.
>>>
>>> On Wednesday, May 8, 2019 at 8:50:23 PM UTC+8, Than McIntosh wrote:

 Hi,

 From the error output it sounds like something went wrong with the
 initial cmake run -- the error from match.sh seems nonsensical (it suggests
 that the script is looking for gotools sources in the wrong location).

 One possibility would be that you don't have "sed" installed on your
 system?

 Thanks, Than


 On Tue, May 7, 2019 at 9:56 PM Ting Yuan  wrote:

> Hello Than,
> when I using ninja to build gollvm, just like
>
> % cmake -DCMAKE_INSTALL_PREFIX=/home/yt/LLVMsvn/install -
> DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold
> -G "Ninja" ../llvm
> % ninja gollvm
>
> the build system still reports an error:
>
> ninja: error:
> '/home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gotools/buildid.go',
> needed by 'tools/gollvm/gotools/buildid', missing and no known rule
> to make it
>
> I notice that some warnings are raised during the configuration like:
>
> /home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gofrontend/libgo/match.sh:138:
> no such file or directory:  

Re: [go-nuts] Could someone tell me how to build gollvm?

[Ting Yuan]

OK, I got something like
...
/home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(55):  if(NOT 
EXISTS /home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid )
/home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(57):  else()
/home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(58):  
set(tool_target gotools_cmd_buildid )
/home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(62):  
execute_process(COMMAND /usr/bin/zsh 
/home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/match.sh --goarch=amd64 
--goos=linux 
--srcdir=/home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid 
OUTPUT_VARIABLE toolfiles ERROR_VARIABLE errmsg RESULT_VARIABLE exitstatus )
/home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(68):  if(NOT 0 
MATCHES 0 )
/home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(71):  
string(STRIP  
/home/yt/LLVMsvn/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid/ 
buildid.go doc.go
 toolfiles )
/home/yt/LLVMsvn/llvm/tools/gollvm/gotools/CMakeLists.txt(72):  
separate_arguments(toolfiles )
...

I found that the absolute path of buildid.go is illegal (there is a space 
before the filename). This looks like the root cause.

On Wednesday, May 8, 2019 at 11:46:09 PM UTC+8, Than McIntosh wrote:
>
> Hmm, OK, sounds like 'sed' is not the issue.
>
> >>I found there are only two files (CMakeLists.txt and gotestprogram.sh) 
> under the llvm/tools/gollvm/gotools/. Should the missing files (e.g. 
> buildid.go) be there?
>
> No, this is expected. The Go sources for 'buildid' will be pulled from 
> /tools/gollvm/gofrontend/libgo/go/cmd/buildid.
>
> At this point what I would recommend to gather more info: rerun cmake and 
> pass it the "--trace-expand" flag, e.g.
>
> cmake --trace-expand -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold 
> ../llvm
>
> Be warned that this will produce a huge amount of output (~40M or so). 
> Sift through the output and see if you can find the place where it is 
> trying to locate the source files for the buildid tool by running 
> 'match.sh'. Should look something like
>
> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(55):  if(NOT EXISTS 
> /root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid )
> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(57):  else()
> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(58):  set(tool_target 
> gotools_cmd_buildid )
> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(62):  
> execute_process(COMMAND /bin/bash 
> /root/llvm/tools/gollvm/gofrontend/libgo/match.sh --goarch=amd64 
> --goos=linux 
> --srcdir=/root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid 
> OUTPUT_VARIABLE toolfiles ERROR_VARIABLE errmsg RESULT_VARIABLE exitstatus )
> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(68):  if(NOT 0 MATCHES 0 )
> /root/llvm/tools/gollvm/gotools/CMakeLists.txt(71):  string(STRIP 
> /root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid/buildid.go 
> /root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid/doc.go
>  toolfiles )
>
> I am thinking that maybe there is something going wrong with the 
> invocation of 'match.sh' in your case that is throwing things off.
>
> Thanks, Than
>
>
>
> On Wed, May 8, 2019 at 11:30 AM Ting Yuan > 
> wrote:
>
>> Hi Than,
>>
>> On my system the version of sed is 4.4. Is the version mismatch?
>>
>> I found there are only two files (CMakeLists.txt and gotestprogram.sh) 
>> under the llvm/tools/gollvm/gotools/. Should the missing files (e.g. 
>> buildid.go) be there?
>>
>> Thanks.
>>
>> On Wednesday, May 8, 2019 at 8:50:23 PM UTC+8, Than McIntosh wrote:
>>>
>>> Hi,
>>>
>>> From the error output it sounds like something went wrong with the 
>>> initial cmake run -- the error from match.sh seems nonsensical (it suggests 
>>> that the script is looking for gotools sources in the wrong location).
>>>
>>> One possibility would be that you don't have "sed" installed on your 
>>> system?
>>>
>>> Thanks, Than
>>>
>>>
>>> On Tue, May 7, 2019 at 9:56 PM Ting Yuan  wrote:
>>>
 Hello Than,
 when I using ninja to build gollvm, just like

 % cmake -DCMAKE_INSTALL_PREFIX=/home/yt/LLVMsvn/install -
 DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold 
 -G "Ninja" ../llvm
 % ninja gollvm

 the build system still reports an error:

 ninja: error: 
 '/home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gotools/buildid.go', 
 needed by 'tools/gollvm/gotools/buildid', missing and no known rule to 
 make it

 I notice that some warnings are raised during the configuration like:

 /home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gofrontend/libgo/match.sh:138:
  
 no such file or directory:  action.go build.go buildid.go exec.go gc.go 
 gccgo.go init.go security.go testgo.go

 Is there something I missing ?



 在 2019年5月7日星期二 UTC+8下午9:48:48，Than McIntosh写道：
>
> Hello,
> For the gollvm build ninja is recommended (using "make" is untested 
> and I doubt if it

Re: [go-nuts] Could someone tell me how to build gollvm?

['Than McIntosh' via golang-nuts]

Hmm, OK, sounds like 'sed' is not the issue.

>>I found there are only two files (CMakeLists.txt and gotestprogram.sh)
under the llvm/tools/gollvm/gotools/. Should the missing files (e.g.
buildid.go) be there?

No, this is expected. The Go sources for 'buildid' will be pulled from
/tools/gollvm/gofrontend/libgo/go/cmd/buildid.

At this point what I would recommend to gather more info: rerun cmake and
pass it the "--trace-expand" flag, e.g.

cmake --trace-expand -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold ../llvm

Be warned that this will produce a huge amount of output (~40M or so). Sift
through the output and see if you can find the place where it is trying to
locate the source files for the buildid tool by running 'match.sh'. Should
look something like

/root/llvm/tools/gollvm/gotools/CMakeLists.txt(55):  if(NOT EXISTS
/root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid )
/root/llvm/tools/gollvm/gotools/CMakeLists.txt(57):  else()
/root/llvm/tools/gollvm/gotools/CMakeLists.txt(58):  set(tool_target
gotools_cmd_buildid )
/root/llvm/tools/gollvm/gotools/CMakeLists.txt(62):
execute_process(COMMAND /bin/bash
/root/llvm/tools/gollvm/gofrontend/libgo/match.sh --goarch=amd64
--goos=linux
--srcdir=/root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid
OUTPUT_VARIABLE toolfiles ERROR_VARIABLE errmsg RESULT_VARIABLE exitstatus )
/root/llvm/tools/gollvm/gotools/CMakeLists.txt(68):  if(NOT 0 MATCHES 0 )
/root/llvm/tools/gollvm/gotools/CMakeLists.txt(71):  string(STRIP
/root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid/buildid.go
/root/llvm/tools/gollvm/gofrontend/libgo/go/cmd/buildid/doc.go
 toolfiles )

I am thinking that maybe there is something going wrong with the invocation
of 'match.sh' in your case that is throwing things off.

Thanks, Than



On Wed, May 8, 2019 at 11:30 AM Ting Yuan  wrote:

> Hi Than,
>
> On my system the version of sed is 4.4. Is the version mismatch?
>
> I found there are only two files (CMakeLists.txt and gotestprogram.sh)
> under the llvm/tools/gollvm/gotools/. Should the missing files (e.g.
> buildid.go) be there?
>
> Thanks.
>
> On Wednesday, May 8, 2019 at 8:50:23 PM UTC+8, Than McIntosh wrote:
>>
>> Hi,
>>
>> From the error output it sounds like something went wrong with the
>> initial cmake run -- the error from match.sh seems nonsensical (it suggests
>> that the script is looking for gotools sources in the wrong location).
>>
>> One possibility would be that you don't have "sed" installed on your
>> system?
>>
>> Thanks, Than
>>
>>
>> On Tue, May 7, 2019 at 9:56 PM Ting Yuan  wrote:
>>
>>> Hello Than,
>>> when I using ninja to build gollvm, just like
>>>
>>> % cmake -DCMAKE_INSTALL_PREFIX=/home/yt/LLVMsvn/install -
>>> DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold
>>> -G "Ninja" ../llvm
>>> % ninja gollvm
>>>
>>> the build system still reports an error:
>>>
>>> ninja: error:
>>> '/home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gotools/buildid.go',
>>> needed by 'tools/gollvm/gotools/buildid', missing and no known rule to
>>> make it
>>>
>>> I notice that some warnings are raised during the configuration like:
>>>
>>> /home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gofrontend/libgo/match.sh:138:
>>> no such file or directory:  action.go build.go buildid.go exec.go gc.go
>>> gccgo.go init.go security.go testgo.go
>>>
>>> Is there something I missing ?
>>>
>>>
>>>
>>> 在 2019年5月7日星期二 UTC+8下午9:48:48，Than McIntosh写道：

 Hello,
 For the gollvm build ninja is recommended (using "make" is untested and
 I doubt if it will work).
 Thanks, Than


 On Tue, May 7, 2019 at 9:27 AM  wrote:

> I try to build gollvm on ubuntu(x64) following these commands in
> https://go.googlesource.com/gollvm/ :
>
> % cd workarea
> % mkdir build-debug
> % cd build-debug
> % cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold ../llvm
> ...
> % make gollvm -j4
> ...
> %
>
> but I got
>
> -- Targeting X86
> -- starting libgo configuration.
> /home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gofrontend/libgo/match
> .sh:138: no such file or directory:  common.go format.go reader.go
> stat_actime1.go stat_actime2.go stat_unix.go strconv.go writer.go
> /home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gofrontend/libgo/match
> .sh:138: no such file or directory:  reader.go register.go struct.go
> writer.go
> ..
> -- Performing Test HAVE_STEADY_CLOCK -- success
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/yt/LLVMsvn/llvm-project/
> debug
> ...
> [  0%] Built target LLVMDemangle
> [  0%] Built target GoDumpSpecMacroParser
> ...
> [ 50%] Building Go package 'runtime' (non-PIC)
> /home/yt/LLVMsvn/llvm-project/debug/tools/gollvm/libgo/sigtab.go:5:21:
> error: use of undefined type 'sigTabT'
> /home/yt/LLVMsvn/llvm-project/debug/tools/gollvm/libgo/sigtab.go:7:12:

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

['Michael Knyszek' via golang-nuts]

I'm glad to hear it! What went into Go 1.12.5 should supersede that patch
anyway.

On Wed, May 8, 2019 at 3:48 AM Rémy Oudompheng 
wrote:

> Hello,
>
> I didn't have time to try the patch, but as Go 1.12.5 is out with another
> fix, I can confirm with high certainty that the problem is now gone, and I
> am pretty much confident that the situation is even better than Go 1.11,
> which is consistent with the fact that the bug was already there, but
> milder because it only applied to large allocations.
>
> Thanks a lot,
>
> Rémy
>
> Le mar. 16 avr. 2019 à 19:11, Michael Knyszek  a
> écrit :
>
>> Hey Rémy,
>>
>> If you have a chance, could you please try out this patch
>> ? It's been known
>> to help the other application Austin mentioned with virtual memory
>> footprint and it should patch cleanly onto the go1.12. Let me know what you
>> see! It'd help us to confirm the root cause of the VSS growth.
>>
>> Thanks,
>> Michael
>>
>> On Tue, Apr 16, 2019 at 11:03 AM Austin Clements 
>> wrote:
>>
>>> On Tue, Apr 16, 2019 at 1:23 AM Rémy Oudompheng <
>>> remyoudomph...@gmail.com> wrote:
>>>
 Thanks Austin,

 The application workload is a kind of fragmentation torture test as it
 involves a mixture of many long-lived small and large (>100 MB)
 objects, with regularly allocated short-lived small and large objects.
 I have tried creating a sample synthetic reproducer but did not
 succeed at the moment.

 Regarding the max_map_count, your explanation is very clear and I
 apparently missed the large comment in the runtime explaining all of
 that.
 Do you expect a significant drawback between choosing 2MB or 16MB as
 the granularity of the huge page flag manipulation in the case of huge
 heaps ?

>>>
>>> Most likely this will just cause less use of huge pages in your
>>> application. This could slow it down by putting more pressure on the TLB.
>>> In a sense, this is a self-compounding issue since huge pages can be highly
>>> beneficial to huge heaps.
>>>
>>> Regarding the virtual memory footprint, it changed radically with Go
 1.12. It basically looks like a leak and I saw it grow to more than
 1TB where the actual heap total size never exceeds 180GB.
 Although I understand that it is easy to construct a situation where
 there is repeatedly no available contiguous interval of >100MB in the
 address space, it is a significant difference from Go 1.11 where the
 address space would grow to 400-500GB for a similar workload and stay
 flat after that, and I could not find an obvious change in the
 allocator explaining the phenomenon (and unfortunately my resources do
 not allow for an easy live comparison of both program lifetimes).

 Am I right saying that scavenging method or frequency does not
 (cannot) affect at all virtual memory footprint and dynamics ?

>>>
>>> It certainly can affect virtual memory footprint because of how
>>> scavenging affects the allocator's placement policy. Though even with the
>>> increased VSS, I would expect your application to have lower RSS with 1.12.
>>> In almost all cases, lower RSS with higher VSS is a fine trade-off, though
>>> lower RSS with the same VSS would obviously be better. But it can be
>>> problematic when it causes the map count (which is roughly proportional to
>>> the VSS) to grow too large. It's also unfortunate that Linux even has this
>>> limit; it's the only OS Go runs on that limits the map count.
>>>
>>> We've seen one other application experience VSS growth with the 1.12
>>> changes, and it does seem to require a pretty unique allocation pattern.
>>> Michael (cc'd) may be zeroing in on the causes of this and may have some
>>> patches for you to try if you don't mind. :)
>>>
>>> Regards,
 Rémy.

 Le mar. 2 avr. 2019 à 16:15, Austin Clements  a
 écrit :
 >
 > Hi Rémy. We often fight with vm.max_map_count in the runtime, sadly.
 Most likely this comes from the way the runtime interacts with Linux's
 transparent huge page support. When we scavenge (release to the OS) only
 part of a huge page, we tell the OS not to turn that huge page frame back
 into a huge page since that would just make that memory used again.
 Unfortunately, each time we do this counts as a separate "mapping" just to
 track that one flag. These "mappings" are always at least 2MB, but you have
 a large enough virtual address space to reach the max_map_count even then.
 You can see this in /proc/PID/smaps, which should list mostly contiguous
 neighboring regions that differ only in a single "VmFlags" bit.
 >
 > We did make memory scavenging more aggressive in Go 1.12 (+Michael
 Knyszek), though I would have expected it to converge to roughly the same
 "huge page flag fragmentation" as before over the course of five to ten
 minutes. Is your application's virtual 

Re: [go-nuts] Could someone tell me how to build gollvm?

[Ting Yuan]

Hi Than,

On my system the version of sed is 4.4. Is the version mismatch?

I found there are only two files (CMakeLists.txt and gotestprogram.sh) 
under the llvm/tools/gollvm/gotools/. Should the missing files (e.g. 
buildid.go) be there?

Thanks.

On Wednesday, May 8, 2019 at 8:50:23 PM UTC+8, Than McIntosh wrote:
>
> Hi,
>
> From the error output it sounds like something went wrong with the initial 
> cmake run -- the error from match.sh seems nonsensical (it suggests that 
> the script is looking for gotools sources in the wrong location).
>
> One possibility would be that you don't have "sed" installed on your 
> system?
>
> Thanks, Than
>
>
> On Tue, May 7, 2019 at 9:56 PM Ting Yuan > 
> wrote:
>
>> Hello Than,
>> when I using ninja to build gollvm, just like
>>
>> % cmake -DCMAKE_INSTALL_PREFIX=/home/yt/LLVMsvn/install -
>> DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold 
>> -G "Ninja" ../llvm
>> % ninja gollvm
>>
>> the build system still reports an error:
>>
>> ninja: error: 
>> '/home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gotools/buildid.go', 
>> needed by 'tools/gollvm/gotools/buildid', missing and no known rule to 
>> make it
>>
>> I notice that some warnings are raised during the configuration like:
>>
>> /home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gofrontend/libgo/match.sh:138:
>>  
>> no such file or directory:  action.go build.go buildid.go exec.go gc.go 
>> gccgo.go init.go security.go testgo.go
>>
>> Is there something I missing ?
>>
>>
>>
>> 在 2019年5月7日星期二 UTC+8下午9:48:48，Than McIntosh写道：
>>>
>>> Hello,
>>> For the gollvm build ninja is recommended (using "make" is untested and 
>>> I doubt if it will work).
>>> Thanks, Than
>>>
>>>
>>> On Tue, May 7, 2019 at 9:27 AM  wrote:
>>>
 I try to build gollvm on ubuntu(x64) following these commands in 
 https://go.googlesource.com/gollvm/ :

 % cd workarea
 % mkdir build-debug
 % cd build-debug
 % cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold ../llvm
 ...
 % make gollvm -j4
 ...
 %

 but I got

 -- Targeting X86
 -- starting libgo configuration.
 /home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gofrontend/libgo/match.
 sh:138: no such file or directory:  common.go format.go reader.go 
 stat_actime1.go stat_actime2.go stat_unix.go strconv.go writer.go
 /home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gofrontend/libgo/match.
 sh:138: no such file or directory:  reader.go register.go struct.go 
 writer.go
 ..
 -- Performing Test HAVE_STEADY_CLOCK -- success
 -- Configuring done
 -- Generating done
 -- Build files have been written to: /home/yt/LLVMsvn/llvm-project/
 debug
 ...
 [  0%] Built target LLVMDemangle
 [  0%] Built target GoDumpSpecMacroParser
 ...
 [ 50%] Building Go package 'runtime' (non-PIC)
 /home/yt/LLVMsvn/llvm-project/debug/tools/gollvm/libgo/sigtab.go:5:21: 
 error: use of undefined type 'sigTabT'
 /home/yt/LLVMsvn/llvm-project/debug/tools/gollvm/libgo/sigtab.go:7:12: 
 error: reference to undefined name '_SigNotify'
 /home/yt/LLVMsvn/llvm-project/debug/tools/gollvm/libgo/sigtab.go:7:25: 
 error: reference to undefined name '_SigKill'
 /home/yt/LLVMsvn/llvm-project/debug/tools/gollvm/libgo/sigtab.go:8:12: 
 error: reference to undefined name '_SigNotify'
 ...
 tools/gollvm/libgo/CMakeFiles/libgo_runtime.dir/build.make:64: recipe 
 for target 'tools/gollvm/libgo/runtime.o' failed
 make[3]: *** [tools/gollvm/libgo/runtime.o] Error 3
 CMakeFiles/Makefile2:16487: recipe for target 
 'tools/gollvm/libgo/CMakeFiles/libgo_runtime.dir/all' failed
 make[2]: *** [tools/gollvm/libgo/CMakeFiles/libgo_runtime.dir/all] 
 Error 2
 CMakeFiles/Makefile2:11625: recipe for target 
 'tools/gollvm/CMakeFiles/gollvm.dir/rule' failed
 make[1]: *** [tools/gollvm/CMakeFiles/gollvm.dir/rule] Error 2
 Makefile:3475: recipe for target 'gollvm' failed
 make: *** [gollvm] Error 2

 I have no idea about this problem. Should I switch make to ninja (like 
 the document said)?


 -- 
 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 to golan...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/4529d46b-caf4-475f-bcda-273c1bca5016%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>> 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 to golan...

[go-nuts] Re: the Dominance of English in Programming Languages

[K.S. Bhaskar]

For historical reasons, languages and activities tend to be associated. Is 
the need for programmers to know relevant English technical terms any 
different from opera singers needing to know relevant Italian technical 
terms or fencers needing to know relevant French technical terms?

Regards
– Bhaskar

On Tuesday, May 7, 2019 at 12:33:46 PM UTC-4, skinne...@gmail.com wrote:
>
> When I first used IBM's UniComal the manual was Danish but the keywords 
> were English. Sometimes the function names in the examples were Danish. I 
> un derstand your problem.
>
> However, I do think that language is irrellevent. The keywords are tokens 
> that can be replaced programmatically with SED or AWK. You can display all 
> programs in your native language and write code in your native language, 
> when you save your code, it then translates that language source to English 
> language source and then when to edit the English language source you 
> translate it back to your native language source.
>
> I once wrote a process in Comal that would read a legal contract defining 
> a database program, it would parse the file, convert it to C++ code, that 
> would then compile into a working program. If the program did not perform 
> as needed, I sometimes had to write new C++ code but more often the sale 
> person would have to do a change order on the contract for the software.
>
> I do think that all programmers are multi-lingual, they have their native 
> language and one or more computer languages. Sometimes it is easier to 
> learn a new language than to build the tools needed to remain in ones 
> current comfort zone.
>
> My final comment is a bit off topic, I do not consider English to be a 
> language, it has over 120,000 words. If you have a vocabulary of 500 words 
> of Latin you can read most any ancient history. ESL speakers typically have 
> a subset of only 3k words. Most native English speakers use only 10k-20k 
> words depending on their training and locale. Native English speakers can 
> sometimes be incomprehensible to ESL or other English dialects. Vocabulary 
> can be vastly different depending upon class, heritage, region, training. 
>
> On Monday, April 29, 2019 at 12:36:37 AM UTC-5, Chris Burkert wrote:
>>
>> I recently read an article (German) about the dominance of English in 
>> programming languages [1]. It is about the fact that keywords in a language 
>> typically are English words. Thus it would be hard for non English speakers 
>> to learn programming - argue the authors.
>>
>> I wonder if there is really demand for that but of course it is weird to 
>> ask that on an English list.
>>
>> I also wonder if it would be possible on a tooling level to support 
>> keywords in other languages e.g. via build tags: // +language german
>>
>> Besides keywords we have a lot of names for functions, methods, structs, 
>> interfaces and so on. So there is definitely more to it.
>>
>> While such a feature may be beneficial for new programmers, to me it 
>> comes with many downsides like: readability, ambiguous naming / clashes, 
>> global teams ...
>>
>> I also believe the authors totally miss the point that learning Go is 
>> about to learn a language as it is because it is the language of the 
>> compiler.
>>
>> However I find the topic interesting and want to hear about your opinions.
>>
>> thanks - Chris
>>
>> 1: 
>>
>> https://www.derstandard.de/story/2000101285309/programmieren-ist-fuer-jeden-aber-nur-wenn-man-englisch-spricht
>>
>

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f9e6b57b-7c71-4664-9456-70ba55be804c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Could someone tell me how to build gollvm?

['Than McIntosh' via golang-nuts]

Hi,

>From the error output it sounds like something went wrong with the initial
cmake run -- the error from match.sh seems nonsensical (it suggests that
the script is looking for gotools sources in the wrong location).

One possibility would be that you don't have "sed" installed on your system?

Thanks, Than


On Tue, May 7, 2019 at 9:56 PM Ting Yuan  wrote:

> Hello Than,
> when I using ninja to build gollvm, just like
>
> % cmake -DCMAKE_INSTALL_PREFIX=/home/yt/LLVMsvn/install -
> DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold
> -G "Ninja" ../llvm
> % ninja gollvm
>
> the build system still reports an error:
>
> ninja: error:
> '/home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gotools/buildid.go',
> needed by 'tools/gollvm/gotools/buildid', missing and no known rule to
> make it
>
> I notice that some warnings are raised during the configuration like:
>
> /home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gofrontend/libgo/match.sh:138:
> no such file or directory:  action.go build.go buildid.go exec.go gc.go
> gccgo.go init.go security.go testgo.go
>
> Is there something I missing ?
>
>
>
> 在 2019年5月7日星期二 UTC+8下午9:48:48，Than McIntosh写道：
>>
>> Hello,
>> For the gollvm build ninja is recommended (using "make" is untested and I
>> doubt if it will work).
>> Thanks, Than
>>
>>
>> On Tue, May 7, 2019 at 9:27 AM  wrote:
>>
>>> I try to build gollvm on ubuntu(x64) following these commands in
>>> https://go.googlesource.com/gollvm/ :
>>>
>>> % cd workarea
>>> % mkdir build-debug
>>> % cd build-debug
>>> % cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold ../llvm
>>> ...
>>> % make gollvm -j4
>>> ...
>>> %
>>>
>>> but I got
>>>
>>> -- Targeting X86
>>> -- starting libgo configuration.
>>> /home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gofrontend/libgo/match.
>>> sh:138: no such file or directory:  common.go format.go reader.go
>>> stat_actime1.go stat_actime2.go stat_unix.go strconv.go writer.go
>>> /home/yt/LLVMsvn/llvm-project/llvm/tools/gollvm/gofrontend/libgo/match.
>>> sh:138: no such file or directory:  reader.go register.go struct.go
>>> writer.go
>>> ..
>>> -- Performing Test HAVE_STEADY_CLOCK -- success
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to: /home/yt/LLVMsvn/llvm-project/debug
>>> ...
>>> [  0%] Built target LLVMDemangle
>>> [  0%] Built target GoDumpSpecMacroParser
>>> ...
>>> [ 50%] Building Go package 'runtime' (non-PIC)
>>> /home/yt/LLVMsvn/llvm-project/debug/tools/gollvm/libgo/sigtab.go:5:21:
>>> error: use of undefined type 'sigTabT'
>>> /home/yt/LLVMsvn/llvm-project/debug/tools/gollvm/libgo/sigtab.go:7:12:
>>> error: reference to undefined name '_SigNotify'
>>> /home/yt/LLVMsvn/llvm-project/debug/tools/gollvm/libgo/sigtab.go:7:25:
>>> error: reference to undefined name '_SigKill'
>>> /home/yt/LLVMsvn/llvm-project/debug/tools/gollvm/libgo/sigtab.go:8:12:
>>> error: reference to undefined name '_SigNotify'
>>> ...
>>> tools/gollvm/libgo/CMakeFiles/libgo_runtime.dir/build.make:64: recipe
>>> for target 'tools/gollvm/libgo/runtime.o' failed
>>> make[3]: *** [tools/gollvm/libgo/runtime.o] Error 3
>>> CMakeFiles/Makefile2:16487: recipe for target
>>> 'tools/gollvm/libgo/CMakeFiles/libgo_runtime.dir/all' failed
>>> make[2]: *** [tools/gollvm/libgo/CMakeFiles/libgo_runtime.dir/all] Error
>>> 2
>>> CMakeFiles/Makefile2:11625: recipe for target
>>> 'tools/gollvm/CMakeFiles/gollvm.dir/rule' failed
>>> make[1]: *** [tools/gollvm/CMakeFiles/gollvm.dir/rule] Error 2
>>> Makefile:3475: recipe for target 'gollvm' failed
>>> make: *** [gollvm] Error 2
>>>
>>> I have no idea about this problem. Should I switch make to ninja (like
>>> the document said)?
>>>
>>>
>>> --
>>> 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 to golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/4529d46b-caf4-475f-bcda-273c1bca5016%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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 to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ed517fe7-e180-4d0b-b134-f8ee76427ebf%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubs

Re: [go-nuts] How many Go compilers are out there?

[Harald Weidner]

Hello,

On Thu, Apr 25, 2019 at 08:54:57AM -0700, Ian Lance Taylor wrote:
> On Thu, Apr 25, 2019 at 8:29 AM JuciÊ Andrade  wrote:
> >
> > These are the ones I am aware of:
> >
> > . GC toolchain
> > . GCC
> > . gopherjs
> >
> > By Go compiler I mean any tool that understands Go source files and 
> > generates executable code.
>
> There is also llgo (though I'm not sure if that one still works) and GoLLVM.

There is also Joy, another Go-to-JS Compiler.
https://mat.tm/joy/

EmGo and TinyGo are two Embedded Go (cross) compilers.
https://github.com/ziutek/emgo
https://github.com/tinygo-org/tinygo

The SSA interpreter and gomacro are also somewhat related to a Go compiler.
https://godoc.org/golang.org/x/tools/go/ssa/interp
https://github.com/cosmos72/gomacro

Regards,
Harald

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20190508120306.esfver4pqjezkxn7%40hweidner.de.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: A question about A sync.Once implementation.

[roger peppe]

It seems clear to me that C ("can run but has not implemented the singleton
pattern, function f may run multi times") is not the correct answer,
because I'm pretty sure that f cannot run more than once.

However, it's still not a correct Once implementation, because as has
already been pointed out, the Do method can return before the function has
completed.

The reason why f cannot run more than once is that if you *don't* have the
initial non-atomic test of o.done, then the function cannot run more than
once, and the extra condition only reduces the number of times that f can
be called.

The implementation would be incorrect even if the `o.done = 1` assignment
was moved before the call to f, because there's no happens-before
relationship between the `o.done == 1` check and either of the statements
within the mutex. This means that it's possible for the `o.done == 1` check
to report true but for the caller to see memory that indicates that f
hasn't been called.

If you run this code with the race detector enabled, it will report an
error. That should be good enough reason not to use code like this.

Here's a complete example: https://play.golang.org/p/vWVXzRBPMNe
The question is: according to the Go memory model, what's the set of
possible things that that program can print?

I think it could print "unexpected value 0" but not "unexpected value 2".


On Wed, 8 May 2019 at 05:49, Kurtis Rader  wrote:

> On Tue, May 7, 2019 at 9:42 PM White Pure  wrote:
>
>> Hi,
>> Thanks for your reply.
>> The second bug is a known issue, so let’s ignore that. In that case,
>> I think function f still can only be executed once.
>> But why does the load and store of o.done need to be done using
>> atomic operations? I suppose there’s mutex assuring the happens-before.
>>
>
> You seem to be using two different email accounts to comment on this
> thread. That is confusing, at best, and sock puppeting, at worst. Don't do
> that.
>
> Also, your text in the message I am replying to is in a very light grey
> color. Which makes it hard to read on a white background. Please don't use
> styled text that modifies the colors on a general purpose mailing list. Not
> everyone is using color preferences compatible with your preferences.
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> --
> 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 to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD8hZAt0DRyrTEnunU2%3D6_y2hheDB48RZft7BAS4a7fEcg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJhgacgLC-H3oGR_QY7inU%3DqBDdxZeZsEDhRHSrALTX30wgm1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: How many Go compilers are out there?

[JuciÊ Andrade]

One of the reasons I like Go is the very professional approach to its 
development. Work is well done since the inception.
Having a language specification appears to be a simple matter, yet many 
other languages doesn't have such document.
It turns out that this very artefact is essential for writing decent tools 
and I am glad Go has several independently developed compilers.

Thanks.

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4422704c-ae7c-4a8e-8a60-ddbaeafa3e9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to run a go method on multiple cores ?

[Nitish Saboo]

Hi Marvin,

Thanks for your response.

"Do you mean "log/syslog" from the standard library?  What does
initialize do?"

>>I have installed syslog-ng parser on my Linux box and I am planning you
use syslog-ng parser and wanted to initialise it's engine for parsing the
data.

so initialise() method in my Go code calls  C code that is wrapper around
syslog-ng C header files.So ,I am making use of cgo

*Following is my Go code:*

func (obj Syslogparser) initialise{

X := C.CString(obj.X)
defer C.free(unsafe.Pointer(X))
Y := C.CString(obj.Y)
defer C.free(unsafe.Pointer(Y))
C.initialize_engine(X, Y,
(C.key_value_cb)(unsafe.Pointer(C.callOnMeGo_cgo)));
}

*And following is my C method 'initialize_engine':*

int initialize_engine(const gchar* X, const gchar* Y, key_value_cb cb) //
cb is callback function
{
// does some operation for initialising the engine of syslog-ng parser
  return 0;
}

1)I want two instances of syslog-ng engine running on two different
processors.How can I achieve this?

2)I made the following change :

func main {
var obj1 Syslogparser  = initalize() // This initialises syslog-ng engine.call
to a C library via cgo
var obj2 Syslogparser// Not a package-level variable
obj1.ParseMessage(program,msg)// this will parse the data and get the result
if result["Z"] == "unknown"{ // On the basis of this result I want to
initialise a new engine
go func() {
 opts := Syslog{}
obj2 = initalize() //call to a C library via cgo
obj2.ReloadPatternDB(opts)  //call to a C library via cgo
obj2.ParseMessage(program, msg) //call to a C library via cgo
}()
}
}

Will this initialise two different syslog-ng engines for me ?

3)I understand goroutines are not OS threads and they just run on OS
threads.Can we extract the process id of the running syslog-ng engines
within the go routine where it spawned the syslog-ng engine ?

Thanks


On Wed, May 8, 2019 at 3:01 AM Marvin Renich  wrote:

> * Nitish Saboo  [190507 14:07]:
> > Thanks Michel for your detailed response.
> > I am initialising the syslog engine.
>
> Do you mean "log/syslog" from the standard library?  What does
> initialize do?
>
> > var obj1 parser  = initalize()
> > var obj2 parser
> > go func() {
> > obj2 = initalize()
> > }()
>
> You have initialized obj1, then you create a go routine that initializes
> obj2.  Assuming the initialization step takes a relatively short amount
> of time and terminates, and does not itself create another go routine,
> obj2 is not "on another go routine" (or thread or CPU or anything else).
> It is simply another variable whose value was assigned by a different go
> routine, but that go routine terminated immediately after obj2 was given
> its value.
>
> Note that obj2 is a variable, not a running function; it is not
> associated with a specific go routine, at least not in the sense that
> you appear to be thinking.  If obj2 is declared at the package level,
> than any function in the package can reference it regardless of the go
> routine in which that function is running.
>
> > if obj1 engine fails:
> > go func() {
> > obj2.ReloadPattern(opts)
> > }()
> >
> > My question is, will obj2.ReloadPattern reload the pattern on the second
> > syslog-engine , how can I verify that?Because I am not maintaining the
> > engine info. I am just having the parser object.
> > Will parser object obj2 go and reload the respective syslog engine that
> was
> > initialised by it? I guess yes, but still need clarification on this .
>
> A new go routine will be created (possibly unnecessarily, but you don't
> give enough information), and the ReloadPattern method of obj2 will be
> invoked in that go routine.  When ReloadPattern terminates, the go
> routine will also terminate.  obj2 is still a package-level variable (or
> associated with whatever scope in which it was declared).
>
> > Since I was not able to identify the exact syslog engine, I was trying to
> > identify it using the processor.
>
> Since you don't give enough information, I'm going to take some guesses,
> which could be completely wrong.  I am guessing that you are using the
> standard library "log/syslog" package, and you have encapsulated the
> result of either NewLogger, New, or Dial from that package in your own
> structure which is returned by initialize.  Your structure has
> additional fields and methods, and some of the methods call appropriate
> methods on the value obtained from the syslog package.
>
> I don't know what your structure has or what initialize does, but the
> result of one of those functions from syslog is not an "engine" in the
> sense of code that runs in a loop waiting for requests to do some work.
> The result of those functions from syslog is a variable containing
> state.  When you invoke a method on one of those results, the method
> runs in the current go routine, not the go routine where NewLogger, New,
> or Dial was run.
>
> > Can we execute any linux command within goroutine to get some sort of
> info
> > on this ?
>
>

Re: [go-nuts] How to detect source of a dependency in go.mod

[Dan Kortschak]

Try github.com/sirupsen/logrus@v1.4.1

At some point the capitalisation was changed.

On Tue, 2019-05-07 at 19:16 -0700, tamal wrote:
> I am trying to convert https://github.com/appscode/voyager from glide
> to go 
> mod.
> 
> I am getting an error like below:
> ```
> go: github.com/Sirupsen/logrus@v1.4.1: parsing go.mod: unexpected
> module 
> path "github.com/sirupsen/logrus"
> go: error loading module requirements
> ```
> 
> How do I find out the source of this old Sirupsen module?
> 

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1557302159.4298.1.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

[Rémy Oudompheng]

Hello,

I didn't have time to try the patch, but as Go 1.12.5 is out with another
fix, I can confirm with high certainty that the problem is now gone, and I
am pretty much confident that the situation is even better than Go 1.11,
which is consistent with the fact that the bug was already there, but
milder because it only applied to large allocations.

Thanks a lot,

Rémy

Le mar. 16 avr. 2019 à 19:11, Michael Knyszek  a
écrit :

> Hey Rémy,
>
> If you have a chance, could you please try out this patch
> ? It's been known to
> help the other application Austin mentioned with virtual memory footprint
> and it should patch cleanly onto the go1.12. Let me know what you see! It'd
> help us to confirm the root cause of the VSS growth.
>
> Thanks,
> Michael
>
> On Tue, Apr 16, 2019 at 11:03 AM Austin Clements 
> wrote:
>
>> On Tue, Apr 16, 2019 at 1:23 AM Rémy Oudompheng 
>> wrote:
>>
>>> Thanks Austin,
>>>
>>> The application workload is a kind of fragmentation torture test as it
>>> involves a mixture of many long-lived small and large (>100 MB)
>>> objects, with regularly allocated short-lived small and large objects.
>>> I have tried creating a sample synthetic reproducer but did not
>>> succeed at the moment.
>>>
>>> Regarding the max_map_count, your explanation is very clear and I
>>> apparently missed the large comment in the runtime explaining all of
>>> that.
>>> Do you expect a significant drawback between choosing 2MB or 16MB as
>>> the granularity of the huge page flag manipulation in the case of huge
>>> heaps ?
>>>
>>
>> Most likely this will just cause less use of huge pages in your
>> application. This could slow it down by putting more pressure on the TLB.
>> In a sense, this is a self-compounding issue since huge pages can be highly
>> beneficial to huge heaps.
>>
>> Regarding the virtual memory footprint, it changed radically with Go
>>> 1.12. It basically looks like a leak and I saw it grow to more than
>>> 1TB where the actual heap total size never exceeds 180GB.
>>> Although I understand that it is easy to construct a situation where
>>> there is repeatedly no available contiguous interval of >100MB in the
>>> address space, it is a significant difference from Go 1.11 where the
>>> address space would grow to 400-500GB for a similar workload and stay
>>> flat after that, and I could not find an obvious change in the
>>> allocator explaining the phenomenon (and unfortunately my resources do
>>> not allow for an easy live comparison of both program lifetimes).
>>>
>>> Am I right saying that scavenging method or frequency does not
>>> (cannot) affect at all virtual memory footprint and dynamics ?
>>>
>>
>> It certainly can affect virtual memory footprint because of how
>> scavenging affects the allocator's placement policy. Though even with the
>> increased VSS, I would expect your application to have lower RSS with 1.12.
>> In almost all cases, lower RSS with higher VSS is a fine trade-off, though
>> lower RSS with the same VSS would obviously be better. But it can be
>> problematic when it causes the map count (which is roughly proportional to
>> the VSS) to grow too large. It's also unfortunate that Linux even has this
>> limit; it's the only OS Go runs on that limits the map count.
>>
>> We've seen one other application experience VSS growth with the 1.12
>> changes, and it does seem to require a pretty unique allocation pattern.
>> Michael (cc'd) may be zeroing in on the causes of this and may have some
>> patches for you to try if you don't mind. :)
>>
>> Regards,
>>> Rémy.
>>>
>>> Le mar. 2 avr. 2019 à 16:15, Austin Clements  a
>>> écrit :
>>> >
>>> > Hi Rémy. We often fight with vm.max_map_count in the runtime, sadly.
>>> Most likely this comes from the way the runtime interacts with Linux's
>>> transparent huge page support. When we scavenge (release to the OS) only
>>> part of a huge page, we tell the OS not to turn that huge page frame back
>>> into a huge page since that would just make that memory used again.
>>> Unfortunately, each time we do this counts as a separate "mapping" just to
>>> track that one flag. These "mappings" are always at least 2MB, but you have
>>> a large enough virtual address space to reach the max_map_count even then.
>>> You can see this in /proc/PID/smaps, which should list mostly contiguous
>>> neighboring regions that differ only in a single "VmFlags" bit.
>>> >
>>> > We did make memory scavenging more aggressive in Go 1.12 (+Michael
>>> Knyszek), though I would have expected it to converge to roughly the same
>>> "huge page flag fragmentation" as before over the course of five to ten
>>> minutes. Is your application's virtual memory footprint the same between
>>> 1.11 and 1.12 or do that grow?
>>> >
>>> > You could try disabling the huge page flag manipulation to confirm
>>> and/or fix this. In $GOROOT/src/runtime/internal/sys/arch_amd64.go (or
>>> whichever GOARCH is appropriate), set HugePageSize t

[go-nuts] Re: Need help to make autocert working

['alex' via golang-nuts]

> This site can’t be reached
> site took too long to respond.

Where is this coming from, some kind of a client?

> How come the autocert TLS handshake trying to connect my home IP address
autocert doesn't connect anywhere except the ACME directory, Let's Encrypt 
being most common I guess.
Most likely you've tried connecting to your server from home and that's 
where your own IP would show up.

Make sure the domain name points to a publicly accessible IP address where 
your box is running.
The ACME CA will try to connect to it while verifying proof of domain 
control. If it can't, the validation fails and autocert won't be able to 
complete TLS handshake. 

On Wednesday, 8 May 2019 03:07:36 UTC+2, Tong Sun wrote:
>
> Hi, 
>
> I've been trying to get an TLS server up and running for the past several 
> days without success. I've used the following guides as reference:
>
>
> https://goenning.net/2017/11/08/free-and-automated-ssl-certificates-with-go/
>  
>
> https://blog.kowalczyk.info/article/Jl3G/https-for-free-in-go-with-little-help-of-lets-encrypt.html
>
> and many more. 
> But for all of them I'm getting
>
>
> This site can’t be reached
> site took too long to respond.
>
>
> The latest code that I tried is 
> https://gist.github.com/samthor/5ff8cfac1f80b03dfe5a9be62b29d7f2
>
> whose console log was:
>
> 2019/05/07 20:27:16 Serving http/https for domains: [my.domain.com]
> 2019/05/07 20:28:05 http: TLS handshake error from 99.xx.xx.221:43662: EOF
>
> The previous errors I got from console log were:
>
> 2019/05/07 11:11:11 http: TLS handshake error from 99.xx.xx.221:40820: 
> context deadline exceeded
> 2019/05/07 11:11:11 http: TLS handshake error from 99.xx.xx.221:40826: 
> acme/autocert: missing certificate
> . . . 
>
>
> The console log looked very strange to me -- 
>
> - I have a real site with real DNS name. 
> - I ssh into the box as me, and start the program as:
>
>  sudo ./autocert-server my.domain.com
>
> However, that 99.xx.xx.221 from all logs is my own home IP address (with a 
> different domain name). 
> How come the autocert TLS handshake trying to connect my home IP address, 
> instead of the remote server that I run the web site from and provide the 
> real DNS name with? 
>
> thx
>
>

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1fb619b1-cdf7-49bf-9a42-61e961d36c8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.