In the section "# ../test/bench/shootout", it shows
***
Package libpcre was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpcre.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpcre' found
regex-dna
***
So, does package regexp is using C-bindings to trick the regex-dna benchmark in (http://benchmarksgame.alioth.debian.org/u64/performance.php?test=regexdna) ?
On 13 August 2014 17:37, Archos <raul...@sent.com> wrote:
In the section "# ../test/bench/shootout", it shows
***
Package libpcre was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpcre.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpcre' found
regex-dna
***
So, does package regexp is using C-bindings to trick the regex-dna benchmark in (http://benchmarksgame.alioth.debian.org/u64/performance.php?test=regexdna) ?
Why don't you look at the source code and see for yourself? It took me all of 5 seconds to perform that search.
PCRE is used by test/bench/shootout/regex-dna.c which is a C program used to compare PCRE against Go's regexp package. (See recent timings.)I don't see what we could possibly gain by gaming the shootout benchmarks.
--
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...@googlegroups.com.
Go's performance on that benchmark is related the simple implementation of the regexp package. It could be made faster, but you could also use PCRE bindings if you really care.You should know this by now. It has come up many times before, and you have been posting here for four years.
Good job!
Just a small type at the release notes page: "compiler and the the runtime"
--
You received this message because you are subscribed to the Google Groups "golang-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-announ...@googlegroups.com.
Perhaps this is the point where you complete your transition to the Rust mailing list.
What, exactly, are you trying to achieve by this line of inquiry?
The question of Go's apparent deficiency with respect to Perl compatible regular expressions has been discussed since the beginning of the language.You have been a member of this list long enough to know this.
You also know that Go's regexp package will _NOT_ be altered to compete in this synthetic benchmark, the reasons for this have also been discussed repeatedly.
Perhaps this is the point where you complete your transition to the Rust mailing list.
Seriously, you guys should hire somebody outside of Google to handle community. Just like the Google Chrome team did, that community is great and vibrant. Go's community is really sad to watch. There is just too much lack of empathy and intolerance.
On Wednesday, August 13, 2014 3:52:02 AM UTC-4, Andrew Gerrand wrote:On 13 August 2014 17:37, Archos <raul...@sent.com> wrote:
In the section "# ../test/bench/shootout", it shows
***
Package libpcre was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpcre.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpcre' found
regex-dna
***
So, does package regexp is using C-bindings to trick the regex-dna benchmark in (http://benchmarksgame.alioth.debian.org/u64/performance.php?test=regexdna) ?
Why don't you look at the source code and see for yourself? It took me all of 5 seconds to perform that search.
PCRE is used by test/bench/shootout/regex-dna.c which is a C program used to compare PCRE against Go's regexp package. (See recent timings.)I don't see what we could possibly gain by gaming the shootout benchmarks.Andrew
--
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...@googlegroups.com.
On 13 August 2014 22:26, Camilo Aguilar <camilo....@gmail.com> wrote:
Seriously, you guys should hire somebody outside of Google to handle community. Just like the Google Chrome team did, that community is great and vibrant. Go's community is really sad to watch. There is just too much lack of empathy and intolerance.
Hi Camilo,Thanks for calling me on this. I should have been patient in replying to Archos' original message.
After a long day preparing the release, I'll admit that I was exasperated when I saw the first reply to my release announcement was an accusation that we were rigging the benchmarks. And who was it from? The fifth-most prolific poster to this group, a long-time member of this community, and someone who I thought should know better. (There is history at play, here.)
In retrospect, I was wrong to assume malice, and probably should have dealt with it off-list. People overlook simple things all the time, and I should have been more charitable. I apologise for being snippy.
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/CF5wyVEjEaY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
Most of the time I don't respond to threads unless I can help or need help. This time I just wanted to speak up and say that Go is awesome and the team is awesome. I look forward to the posts the team members blog, their tweets, and their YouTube videos on Go. The amount of negativity on this list ebbs and flows, but overall I think it's very good and could be amazing if people stopp feeding trolls, and also remind themselves regularly that newsgroup posts often fail to convey the intended tone. Especially when written by programmer-types.
--
--
package main//#include "tokudb.h"import "C"type Tx struct {tx *C.DB_TXN}func main() {return}
# command-line-arguments
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x15672]
goroutine 16 [running]:
runtime.panic(0x1dae60, 0x31b9e4)
/usr/local/go/src/pkg/runtime/panic.c:279 +0xf5
main.(*typeConv).Type(0x2083bc2c0, 0x220837fbd0, 0x2083d4060, 0xb2, 0x1)
/usr/local/go/src/cmd/cgo/gcc.go:1288 +0x1632
main.(*typeConv).Type(0x2083bc2c0, 0x220837fb98, 0x2083d4000, 0xb2, 0x0)
/usr/local/go/src/cmd/cgo/gcc.go:1189 +0x3dd6
main.(*typeConv).Struct(0x2083bc2c0, 0x208372cc0, 0xb2, 0x6, 0x0, 0x0, 0x8)
/usr/local/go/src/cmd/cgo/gcc.go:1551 +0x70b
main.(*typeConv).Type(0x2083bc2c0, 0x220837fc08, 0x208372cc0, 0xb2, 0x2084133e0)
/usr/local/go/src/cmd/cgo/gcc.go:1234 +0x3038
main.(*typeConv).Type(0x2083bc2c0, 0x220837fbd0, 0x208393dd0, 0xb2, 0x1)
/usr/local/go/src/cmd/cgo/gcc.go:1269 +0x1301
main.(*Package).loadDWARF(0x20836f1e0, 0x20837c100, 0x2083a6510, 0x2, 0x2)
/usr/local/go/src/cmd/cgo/gcc.go:541 +0xfb4
main.(*Package).Translate(0x20836f1e0, 0x20837c100)
/usr/local/go/src/cmd/cgo/gcc.go:182 +0x150
main.main()
/usr/local/go/src/cmd/cgo/main.go:259 +0xef1
gcc -v
Target: x86_64-apple-darwin13.2.0
Thread model: posix
gcc version 4.9.0 (Homebrew gcc49 4.9.0)
clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.2.0
Thread model: posix
Using go1.3, build crash message here:# command-line-arguments
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x15672]
goroutine 16 [running]:
runtime.panic(0x1dae60, 0x31b9e4)
/usr/local/go/src/pkg/runtime/panic.c:279 +0xf5
main.(*typeConv).Type(0x2083bc2c0, 0x220837fbd0, 0x2083d4060, 0xb2, 0x1)
/usr/local/go/src/cmd/cgo/gcc.go:1288 +0x1632