Error using regexp.Match
Archos
because is the same than in the next code:
***
package main
import (
"fmt"
"regexp"
)
func main() {
line := []byte("=======\n")
CHAR_HEADER := "="
fmt.Println(line)
reHeader := regexp.MustCompile(fmt.Sprintf("^%s+\n", CHAR_HEADER))
if reHeader.Match(line) {
println("OK")
}
}
***
[61 61 61 61 61 61 61 10]
OK
***
In that code it's matched, and as you can see, the ASCII value of '='
is 61 and for '\n' is 10.
But it fails in my program where I've anything as::
http://github.com/kless/gowizard/blob/master/gowizard/replace.go#L32
http://github.com/kless/gowizard/blob/master/gowizard/replace.go#L85
***
var reHeader = regexp.MustCompile(fmt.Sprintf("^%s+\n", CHAR_HEADER))
if reFirstOldName.Match(line) {
fmt.Println("In")
/*
Another Code
*/
fmt.Println(line, '=')
if reHeader.Match(line) {
println("HEADER")
***
The output is:
***
In
[61 61 61 61 61 10] 61
***
which shows that it's a line like above's one, but that it isn't
matched.
* * *
Any idea? Because I cann't debug it of another way.
chris dollin
> I've a problem with an expression regular which should be correct
> because is the same than in the next code:
The code in `replace.go` doesn't compile, because there are several
undefined names including CHAR_HEADER.
So I suspect that whatever your're running doesn't define the RE
you think it does.
Chris
--
Chris "allusive" Dollin
Archos
On Sep 3, 10:20 am, chris dollin <ehog.he...@googlemail.com> wrote:
>
> > I've a problem with an expression regular which should be correct
> > because is the same than in the next code:
>
> The code in `replace.go` doesn't compile, because there are several
> undefined names including CHAR_HEADER.
Makefile.
Thanks for check it! It compiles on my system without any problem
(else I don't write this post). Although since I'm compiling via gofr
I'm going to check if this error is by it.
Archos
On Sep 3, 10:38 am, Archos <raul....@sent.com> wrote:
> On Sep 3, 10:20 am, chris dollin <ehog.he...@googlemail.com> wrote:> On 3 September 2010 10:42, Archos <raul....@sent.com> wrote:
>
> > > I've a problem with an expression regular which should be correct
> > > because is the same than in the next code:
>
> > The code in `replace.go` doesn't compile, because there are several
> > undefined names including CHAR_HEADER.
>
> `CHAR_HEADER` is defined on main.go, and both files are included in
> Makefile.
>
> Thanks for check it! It compiles on my system without any problem
> (else I don't write this post). Although since I'm compiling via gofr
> I'm going to check if this error is by it.
it on my system using *sudo -E make install* so I don't know why you
get that error.
chris dollin
>
> It isn't necessary to check if it's a gofr error because I can install
> it on my system using *sudo -E make install* so I don't know why you
> get that error.
You didn't make it clear that replace.go was incomplete and that
you expected the gowizard git to be cloned. So I cloned it, go into
gowizard, make install:
6g -o _go_.6 main.go error.go flag.go metadata.go replace.go
template.go tmpl-data.go util.go
flag.go:20: can't find import: github.com/kless/go-readin/readin
make: *** [_go_.6] Error 1
OK so I have to do two goinstalls first. Then I can compile it, but
I don't know how to provoke it to get the error you mention.
Probably best if you can cut it down to a minimal example.
Chris
PS The README starts:
Tired of adding the same files every time you create a new Go project?
to which my automatic reply is "no" ...
--
Chris "allusive" Dollin
Archos
On Sep 3, 11:04 am, chris dollin <ehog.he...@googlemail.com> wrote:
>
> > It isn't necessary to check if it's a gofr error because I can install
> > it on my system using *sudo -E make install* so I don't know why you
> > get that error.
>
> You didn't make it clear that replace.go was incomplete and that
> you expected the gowizard git to be cloned. So I cloned it, go into
> gowizard, make install:
>
> 6g -o _go_.6 main.go error.go flag.go metadata.go replace.go
> template.go tmpl-data.go util.go
> flag.go:20: can't find import: github.com/kless/go-readin/readin
> make: *** [_go_.6] Error 1
>
> OK so I have to do two goinstalls first. Then I can compile it, but
> I don't know how to provoke it to get the error you mention.
## Installation
$ [sudo -E] goinstall github.com/kless/goconfig/config
$ [sudo -E] goinstall github.com/kless/go-readin/readin
$ git clone git://github.com/kless/gowizard.git
$ cd gowizard/gowizard && sudo -E make install
$ make data ; cd -
### example
$ gowizard -Project-name=goFoo -Author="John Foo" -Author-
email="e...@mail.com"
-Project-type=lib -License=gpl-3 -vcs=git && cd gofoo
$ gowizard -u -Project-name=goBar -License=bsd-2 -v
Russ Cox
Yes you can, and you should.
Think about what your program is doing.
Put print statements in to verify that you're right.
If that's not enough, make a copy of your program,
edit it to hard-code whatever is necessary to trigger
the bug, and then run
make && 6.out
The bug should happen. Then start throwing away
code, moving things into a single file, and throwing
away more code, simplifying the program as much
as possible without eliminating the bug. During this
process it helps to be running
make && 6.out
after each change, ready to undo if you've lost the bug.
Repeat this until you've got the example cut down to
a single file program that is less than 20 lines long.
It's likely you'll figure out the bug before you get there,
in which case you can stop, fix it in the original, verify
that it's fixed, and then throw away the mangled copy.
But if you do get to a single file program that is less
than 20 lines, *then* mail the list, and include the entire
program, so that we can reproduce the bug too.
If it's not worth your time to go through this process,
to isolate the deterministic problem in a simple demonstration
program (and it's your program!), then it's likely not worth
our time either. Meet us halfway: we're happy to help but
you have to give us better examples.
The most important benefit of this process is that
nine times out of ten, you find the bug on your own,
which in the long term is typically more helpful than
just being told where the bug is.
Russ
Archos
On Sep 3, 9:42 am, Archos <raul....@sent.com> wrote:
> I've a problem with an expression regular which should be correct
> because is the same than in the next code:
>
> ***
> package main
>
> import (
> "fmt"
> "regexp"
> )
>
> func main() {
> line := []byte("=======\n")
> CHAR_HEADER := "="
>
> fmt.Println(line)
>
> reHeader := regexp.MustCompile(fmt.Sprintf("^%s+\n", CHAR_HEADER))
>
> if reHeader.Match(line) {
> println("OK")
> }}
>
> ***
> [61 61 61 61 61 61 61 10]
> OK
> ***
> In that code it's matched, and as you can see, the ASCII value of '='
> is 61 and for '\n' is 10.
>
> But it fails in my program where I've anything as::
$ cat > foo.txt << 'EOF'
wetsand
=======
EOF
http://www.gopaste.net/?id=1577
Archos
It has been very difficult to find it. The problem is that I was
passing to the regexp. a character instead of a string.
// const CHAR_HEADER = '=' // Wrong
const CHAR_HEADER = "="
var reHeader = regexp.MustCompile(fmt.Sprintf("^%s+\n", CHAR_HEADER))
* The conclussion is that such errors (related to reg. exp.) are very
hard to catch :(
Archos
On Sep 3, 5:06 pm, Archos <raul....@sent.com> wrote:
> Found!
>
> It has been very difficult to find it. The problem is that I was
> passing to the regexp. a character instead of a string.
>
> // const CHAR_HEADER = '=' // Wrong
> const CHAR_HEADER = "="
>
> var reHeader = regexp.MustCompile(fmt.Sprintf("^%s+\n", CHAR_HEADER))
const CHAR_HEADER = '='
var reHeader = regexp.MustCompile(fmt.Sprintf("^%c+\n", CHAR_HEADER))
chris dollin
> Found!
>
> It has been very difficult to find it. The problem is that I was
> passing to the regexp. a character instead of a string.
>
> // const CHAR_HEADER = '=' // Wrong
> const CHAR_HEADER = "="
>
> var reHeader = regexp.MustCompile(fmt.Sprintf("^%s+\n", CHAR_HEADER))
>
> * The conclussion is that such errors (related to reg. exp.) are very
> hard to catch :(
That's what unit tests are for ...
(regexp gotchas are of course not specific to Go.)
Archos
On Sep 3, 6:04 pm, chris dollin <ehog.he...@googlemail.com> wrote:
>
> > Found!
>
> > It has been very difficult to find it. The problem is that I was
> > passing to the regexp. a character instead of a string.
>
> > // const CHAR_HEADER = '=' // Wrong
> > const CHAR_HEADER = "="
>
> > var reHeader = regexp.MustCompile(fmt.Sprintf("^%s+\n", CHAR_HEADER))
>
> > * The conclussion is that such errors (related to reg. exp.) are very
> > hard to catch :(
>
> That's what unit tests are for ...
>
> (regexp gotchas are of course not specific to Go.)
http://groups.google.com/group/golang-nuts/browse_thread/thread/1ae271fae1a8b41c
Russ Cox
>
> http://groups.google.com/group/golang-nuts/browse_thread/thread/1ae271fae1a8b41c
It did show a warning.
You passed that warning to the regexp parser.
Russ
Jessta
There seems to be something wrong with the documentation for fmt.Sprintf
http://golang.org/pkg/fmt/#Sprintf
func Sprintf(format string, a ...interface{}) string
Sprintf formats according to a format specifier and returns the
resulting string. It returns the number of bytes written.
But, It doesn't seem to "return the number of bytes written" at all.
The same problem exists with Sprintln and Sprint.
- jessta
--
=====================
http://jessta.id.au
Rob 'Commander' Pike
-rob