Re: [go-nuts] GoAWK: an AWK interpreter written in Go
I've "finished" my Go AWK interpreter and released v1.0.0 now. I've fixed
several bugs, and also sped up the interpreter significantly, primarily by:
1) Resolving variable names to integers at parse time so we can do []value
lookups instead of map[string]value lookups at runtime
2) Using normal error returns instead of panic/recover internally for
interpreter errors (but oh for the proposed "check" keyword to make this
less verbose!)
3) Using switch/case to switch on binary operation type instead of looking
up the operation in a map of functions
4) Avoiding allocations in many instances
Here's a write-up about GoAWK for those that are interested:
https://benhoyt.com/writings/goawk/
It's pretty much a toy project, not being used for anything real, but it
seems to be in a good shape. Feedback welcome!
-Ben
On Fri, Aug 24, 2018 at 5:13 PM Ben Hoyt wrote:
> I recently wrote an AWK interpreter in Go:
> https://github.com/benhoyt/goawk
>
> It's a pretty simple implementation: hand-rolled lexer, recursive-descent
> parser, and tree-walk interpreter. It's pretty complete according to the
> POSIX spec, and it passes the AWK ("one true awk") test suite as well as my
> own unit tests.
>
> In some quick tests I ran, I/O speed is on a par or better than AWK but
> the interpreter itself is quite slow -- about 5x slower for a lot of
> things. I hope to add some proper benchmarks soon. I have a pretty good of
> why and how to fix it: variable lookup and assignment is slow, and I'm
> planning to fix by resolving more things at parse time.
>
> One thing that's a bit funky about AWK is its type handling: string values
> can be real strings or "numeric strings" (numbers that came from user
> input). I'm currently passing the "value" struct (see interp/value.go)
> around by value. I still need to test if that's a good idea
> performance-wise or not.
>
> I'd love to hear any comments, bug reports, or -- especially -- code
> reviews.
>
> -Ben
>
> --
> 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/kYZp3Q1KKfE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] compiling from within vim not working
Hi. I'm interested in trying the internal compiling option for Go. Vim 7.4. Ubuntu 16.04 amd64 go 1.11.2 I'm using the version of vim that gets installed by apt. When I type :make from a window showing a buffer containing Go code, I get this error: /bin/bash: go: command not found .vimrc set ignorecase laststatus=2 mouse=a clipboard=unnamed wrapmargin=10 autowrite hlsearch incsearch set statusline=%02n:%<%f\ %h%m%r%=%-14.(%l,%c%V%)\ %P set nocompatible filetype plugin on set path+=,~/Documents, Yet, I have no trouble compiling from a command prompt as the go binary is in my path. I suspect that this would be fixed by me symlinking the go binary somewhere, but I don't know where. Thanks for any help. --rob solomon -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: HTTP client CheckRedirect behavior for the first redirect
I took another look at this and realized what I'd gotten wrong: each Request given to CheckRedirect, including req and each of via, has a nested Response that caused the request, *not* the response to that request, as I had assumed. This is mentioned in the documentation: // Response is the redirect response which caused this request // to be created. This field is only populated during client // redirects. So the response to via[0] (first redirect) is via[1].Response, and the response to via[len(via)-1] (last redirect) is req.Response. On Fri, Nov 16, 2018 at 7:43 PM Caleb Spare wrote: > > It seems like http.Client's CheckRedirect hook only populates the > via[n].Response for n>0 (i.e., not for the first hop). This is useful if, for > instance, you want to check the status code (301, 302, etc) of each redirect. > > Here's a playground demo: https://play.golang.org/p/cKoWVhdjKwf > > I can file an issue, but I feel like I'm missing something, because this is > the most obvious thing to want to do with CheckRedirect and nobody else seems > to have complained about it. Can someone clue me in? > > Caleb -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] GoAWK: an AWK interpreter written in Go
That looks nice! I wonder if it makes sense, to expose more of the interpreter to go. E.g.: register a user function or add an action written in go. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] GoAWK: an AWK interpreter written in Go
This is great, both as an "étude"---a challenge for sharpening your
technique---and as an exemplary write-up of the process of building
something non-trivial and making it both correct and fast. Nice work.
I'm sure you knew already, but Peter Weinberger (the W in AWK) is on the Go
team at Google.
On 17 November 2018 at 12:44, Ben Hoyt wrote:
> I've "finished" my Go AWK interpreter and released v1.0.0 now. I've fixed
> several bugs, and also sped up the interpreter significantly, primarily by:
>
> 1) Resolving variable names to integers at parse time so we can do []value
> lookups instead of map[string]value lookups at runtime
> 2) Using normal error returns instead of panic/recover internally for
> interpreter errors (but oh for the proposed "check" keyword to make this
> less verbose!)
> 3) Using switch/case to switch on binary operation type instead of looking
> up the operation in a map of functions
> 4) Avoiding allocations in many instances
>
> Here's a write-up about GoAWK for those that are interested:
>
> https://benhoyt.com/writings/goawk/
>
> It's pretty much a toy project, not being used for anything real, but it
> seems to be in a good shape. Feedback welcome!
>
> -Ben
>
>
> On Fri, Aug 24, 2018 at 5:13 PM Ben Hoyt wrote:
>
>> I recently wrote an AWK interpreter in Go: https://github.com/benhoyt/
>> goawk
>>
>> It's a pretty simple implementation: hand-rolled lexer, recursive-descent
>> parser, and tree-walk interpreter. It's pretty complete according to the
>> POSIX spec, and it passes the AWK ("one true awk") test suite as well as my
>> own unit tests.
>>
>> In some quick tests I ran, I/O speed is on a par or better than AWK but
>> the interpreter itself is quite slow -- about 5x slower for a lot of
>> things. I hope to add some proper benchmarks soon. I have a pretty good of
>> why and how to fix it: variable lookup and assignment is slow, and I'm
>> planning to fix by resolving more things at parse time.
>>
>> One thing that's a bit funky about AWK is its type handling: string
>> values can be real strings or "numeric strings" (numbers that came from
>> user input). I'm currently passing the "value" struct (see interp/value.go)
>> around by value. I still need to test if that's a good idea
>> performance-wise or not.
>>
>> I'd love to hear any comments, bug reports, or -- especially -- code
>> reviews.
>>
>> -Ben
>>
>> --
>> 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/kYZp3Q1KKfE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.
