[go-nuts] Re: Experience report on a large Python-to-Go translation

This is a belated addition to my notes on the Go translation of reposurgeon. I'll be adding it to the revised version I post to golang-dev. One extremely positive thing I must say before closing. Translation from Python, which is a dreadful language to try to do concurrency in due to its globa

[go-nuts] Re: Experience report on a large Python-to-Go translation

On Thursday, January 30, 2020 at 2:05:17 AM UTC-5, Liam wrote: > > I'd suggest re-posting this on golang-dev; I almost missed it as I rarely > read -nuts. > That's a good idea. I think what I'll do is revise it lightly in view of some of the feedback I've gotten here and post it there. -- You

[go-nuts] Golang on UnixWare

I've received a feeler about a most interesting reposurgeon-related consulting engagement from the company that currently owns the historical Unix sources. I'm not going to go into the gory details in a public forum as they might be considered company confidential, but it gives me reason to as

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

On Monday, January 27, 2020 at 9:51:43 AM UTC-5, Philip Boampong wrote: > > I assumed the ugliness is about the recover logic being exposed in the > catch signature and in the handler function. If you change catch to > take the exception handler as a callback you can hide the recover > logic w

[go-nuts] Re: Experience report on a large Python-to-Go translation

On Sunday, January 26, 2020 at 7:14:50 PM UTC-5, pboam...@gmail.com wrote: > > log.Fatal and os.Exit have the same problem. They are not "terminating > statements", so if you want them at the bottom of a function with result > parameters you have to add a panic("unreachable"). > Excellent poin

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

On Sunday, January 26, 2020 at 9:06:47 PM UTC-5, Robert Engels wrote: > > I think trying to write Python in Go is problematic. > Of course it is. If I were starting a Go program from scratch I certainly wouldn't try to code as though the language were Python. The real burden of my experience

[go-nuts] Re: Experience report on a large Python-to-Go translation

I spotted a typo: On Saturday, January 25, 2020 at 3:46:19 AM UTC-5, Eric Raymond wrote: > > The Go translation of reposurgeon is better - more maintainable - code > than the Python original, not just faster. And this is because I > rewrote or refactored as I went; as I've e

[go-nuts] Re: Experience report on a large Python-to-Go translation

On Saturday, January 25, 2020 at 5:43:24 AM UTC-5, Brian Candler wrote: > > 1. When the issue of keyword arguments has come up before, usually someone > suggests passing a struct as the function argument. Did you try this? It > might be worth mentioning in your analysis, if only to give an ex

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

On Saturday, January 25, 2020 at 10:04:19 AM UTC-5, Robert Engels wrote: > > Whenever I see a type switch it screams to me “use an interface and > restructure. “ > You may be right. On the other hand, I think I've already gone far enough down the interface road to have collected most of the ga

[go-nuts] Experience report on a large Python-to-Go translation

Most of the remainder of this post is asciidoc source, because that's easy to quote. If you want to look at a nicely rendered version, see https://gitlab.com/esr/reposurgeon/blob/master/GoNotes.adoc = Notes on the Go translation of Reposurgeon = version 1.8, 2020-01-25 This is an experience re

Re: [go-nuts] Re: C++ 11 to Golang convertor

On Friday, January 4, 2019 at 2:41:19 PM UTC-5, robert engels wrote: > > I still think it would be a nearly impossible task given the C code in the > wild - outside of threading, the common usage of ‘unions’ - there is no > way I know of to map these to a simple Go struct, or even several - y

[go-nuts] Re: C++ 11 to Golang convertor

On Thursday, January 3, 2019 at 12:11:06 PM UTC-5, Jake Montgomery wrote: > > I would note that any tool that ports from C++, or even C, to Go is going > to produce ugly, unmaintainable, and non-idiomatic code, at best. > These are two different cases. I agree that graceful C++ to Go transpilat

Re: [go-nuts] Example of setting a struct field value via reflection requested

On Monday, November 5, 2018 at 6:18:27 PM UTC-5, kortschak wrote: > > https://play.golang.org/p/EtXlOCR1fDY > Thanks, I was able to adapt that into working code. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group a

[go-nuts] Example of setting a struct field value via reflection requested

I need an equivalent of Python setattr() - that is, set a struct member by string name - but the only example I've found on line (SetField in oleiade/reflections on GitHub) panics and dies due to what looks like a spurious Elem() call. I thought I could see how to fix it, but the resulting cod

Re: [go-nuts] Failed iterator proposals?

Thank you, that was a helpful response. -- 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://

[go-nuts] Failed iterator proposals?

I have a real-world case where I need Python style iterators for performance. It's not good to eager-evaluate an event-list 259K items when you know that in the typical case you're only going to select two or three orders of magnitude fewer of them to be passed to a work function. (The list

[go-nuts] Re: [ANN] pygor: yet another Python to Go regurgitator

On Saturday, October 20, 2018 at 12:17:16 AM UTC-4, Raffaele Sena wrote: > > Inspired by ESR pytogo (and tired of writing python code), I went the > complete opposite way and came up with pygor: > Bravo. I am amused by the name - puts me in mind of Discworld Igors. And if my sadly departed f

[go-nuts] Avoiding overloading

I think Ian Denhardt is right to argue that fear of operator overloading is driving people in the generics debate to complicated, ugly workarounds that should not be. I myself do not actually want overloading as a surface feature of the language. In my original "implements" proposal, I accept

[go-nuts] Re: Proposed changes to the Go draft generics design in the light of feedback received

On Friday, October 19, 2018 at 1:48:36 PM UTC-4, alanfo wrote: > > In the light of all the feedback there's been, I've put together a > proposal which sticks closely to the original design and only changes what > most people consider needs to be changed in some way. Some recent ideas > which s

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Wednesday, October 17, 2018 at 11:12:19 AM UTC-4, Ian Denhardt wrote: > > My instinct here is to be conservative; we've got a boatload of use > cases for < and ==, a few obvious ones for +, *, / etc, and a long-tail > for operators after that. Eric's proposal makes it trivial to add more >

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:52:54 PM UTC-4, Ian Denhardt wrote: > > The trouble is that (in the case where you compile using the implements > <, rather than throwing an error) the type signature no longer tells you > what the constraints actually are; this information is only in the body

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:41:53 PM UTC-4, Dave MacFarlane wrote: > > Now I'm confused about what problem regarding generics you're trying > to solve with operator overloading. If you can't assume anything about > the meaning of an operator other than "it returns a bool", how could a >

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:17:36 PM UTC-4, Ian Denhardt wrote: > > What is this intended to buy us? Is this as Ian T suggests in lieu of > any kind of contract system? Oh , no. You *need* a contract system (or at least my implements clause) so you can know if a < b has a meaning when

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:03:16 PM UTC-4, Ian Lance Taylor wrote: > > It's a feasible approach. But unless I misunderstand, testing > arguments at the call site means that you've discarded contracts. > I don't understand that claim. A contract (in my plan, an "implements" clause) is

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

(Sorry about the post fragment that got away from me.) On Tuesday, October 16, 2018 at 3:33:58 PM UTC-4, Ian Denhardt wrote: > > > The alternative though is having to implement several different methods > with obvious implementations in terms of one another, and make sure > they're consistent.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 3:33:58 PM UTC-4, Ian Denhardt wrote: > > > The partial vs. total order thing brings up another issue that I think > needs to be kept in mind: what are the contracts for the various > operators? > I don't undetstand rte q -- You received this message because

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 1:23:20 PM UTC-4, Dave MacFarlane wrote: > > Why is the implements keyword a better solution than magic names? > Because you get syntactic uniformity with primitive types without claiming namespace you don't need. It's more minimalist. Would there be any rule

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 12:24:59 PM UTC-4, alanfo wrote: > > With regard to your reply to Ian, I'm afraid I can't agree with you that > the type parameters shouldn't be specified 'up front'. That's just too > 'dynamic' for me and not very go-like. I'd imagine it would give the > compil

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 9:44:23 AM UTC-4, Ian Lance Taylor wrote: > > It's not clear to me what other aspects of various generic proposals > you are picking up here. The answer is "none of them". That wasn't my goal, because all the previous generics proposals I have seen struck me as

[go-nuts] Re: Generics with adaptors

On Tuesday, October 16, 2018 at 6:34:10 AM UTC-4, Patrick Smith wrote: > > Yet another generics discussion at > https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302 > > This one looks at what programmers would be able to do if very basic > generics were added to Go, without contr

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 6:33:26 AM UTC-4, alanfo wrote: > > However, I think it's important to learn the lessons of the past and not > follow languages such as C++ or Scala where you can overload virtually > anything or even make up your own operators which can result in confusing > or e

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Monday, October 15, 2018 at 11:59:44 PM UTC-4, Ian Denhardt wrote: > > I'm not in love with the inconsistency, and expect it to cause some > confusion with newbies, but I'd have to use it to see how big of a > footgun it is in practice. There are certainly worse ideas. > Yes. If that's th

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 12:16:16 AM UTC-4, Beoran wrote: > > For niw, I don't see what complelling benefits allowing operators in > generic contracts would bring. > Consider Ian Lance Taylor's smoke test for generics. It is: can we implement min() and max() on a generic type. What

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Monday, October 15, 2018 at 11:32:23 PM UTC-4, Eric Raymond wrote: > > Fair enough. I am completely willing to discard the possibility of > overloading && and || > A little thought showed me that this is not required. The straightforward way to write the contract of

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Monday, October 15, 2018 at 11:02:18 PM UTC-4, Ian Denhardt wrote: > > > There are other operators in the language that don't behave like > functions or methods (e.g. boolean operators like && and ||, which > short-circut), but the rest of them are things that don't have gobs of > use cases

[go-nuts] Generics: an unwelcome conclusion and a proposal

Recent discussion of possible generics designs has forced me to a conclusion I'm not happy with, because it requires a feature-cluster that I thought I was glad to be leaving behind in Python. That is this: The simplest and most effective way to solve the generics problem is to embrace operat

[go-nuts] pytogo 1.2 has shipped

I am pleased to announce the release of pytogo 1.2. https://gitlab.com/esr/pytogo New features in this release: * PEP484 type hints are now converted into Go type signatures. * Without PEP484 hints, return types of functions are now sometimes deduced. * Docstrings are moved to the godoc-prefer

Re: [go-nuts] Announcing pytogo. a crude but surprisingly effective Python to Go translator

On Thursday, October 4, 2018 at 4:26:44 AM UTC-4, Peter Waller wrote: > > My approach is a bit different, and works by printing the Python AST in > Go. There is an overlap in our philosophy of 'produce standalone code' and > 'help a human do the translation into idiomatic Go'. However, mine was

[go-nuts] Re: Rule-swarm attacks can outdo deep reasoning

On Wednesday, October 3, 2018 at 4:05:30 PM UTC-4, Michael Ellis wrote: > > Nice writeup. Thanks. Based on today's xkcd , I > think Randall Munroe must have read it, too ;-) > Seems likely. Randall and I have been friendly. -- You received this message because you

[go-nuts] Rule-swarm attacks can outdo deep reasoning

Is promised in the thread on pytogo, I have blogged on the general topic of rule-swarm attacks in the domain of language transformation. http://esr.ibiblio.org/?p=8153 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this gro

[go-nuts] Re: Announcing pytogo. a crude but surprisingly effective Python to Go translator

I've fixed the bug in handling of multiline strings. 1.1 also translate commion for-loop patterns to Go, including traversing lists and dictionaries and doing enumerates. On Sunday, September 30, 2018 at 6:02:21 PM UTC-4, Michael Ellis wrote: > > I'd love to make use of pytogo my own project. I

[go-nuts] Re: Announcing pytogo. a crude but surprisingly effective Python to Go translator

Thanks, I'll fix the bug and add that to my test loads. > > I discovered earlier today that an incautious rule steps on lambda expressions and some kinds of slice indexing. The risks of not using a parser... Until I ship 1.1 (shortly, probably tomiorrow), I recommend filtering your file in sma

[go-nuts] Announcing pytogo. a crude but surprisingly effective Python to Go translator

I have mentioned before on this list that I am engaged in source translation of a largeish Python prgram - 14KLOC - to Go. I found the automated AST-based translation tools already available unsatisfactory; they don't produce a quality of Go code I would consider maintainable. So I wrote my o

Re: [go-nuts] Interaction of signals with defer

MR and CLA submitted. -- 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/

Re: [go-nuts] Interaction of signals with defer

On Tuesday, September 18, 2018 at 6:14:54 PM UTC-4, Ian Lance Taylor wrote: > > > Under "Default behavior of signals in Go programs" in the Signals > package > > documentation, the one sentence "Defer hooks are *not* fired after > signal > > receipt." would head off potential confusion on this

Re: [go-nuts] Interaction of signals with defer

On Tuesday, September 18, 2018 at 4:10:52 PM UTC-4, Ian Lance Taylor wrote: > > Signals in Go never interrupt functions. > Thank you, that was an admirably clear reply. I think this needs to be documented more prominently. Can I file an MR against the Go documentation? Web search is not telli

[go-nuts] Interaction of signals with defer

If interruption of a function with defers is interrupted by an uncaught signal (say, ^C from the keyboard) do its defer hooks fire? What about defer hooks in functions up the call stack? If the interrupt happens during a defer hook's execution, do the remaining hooks in the implied LIFO queue

[go-nuts] Re: Gitlab CI loses its marbles attempting go get.

On Monday, September 10, 2018 at 5:56:23 PM UTC-4, Uli Kunitz wrote: > > Use > > GOPATH= go get *-u* golang.org/x/crypto/ssh/terminal > > The package golang.org/x/sys/unix is probably old and requires updating. > I have no problems on my machine to go get -u > golang.org/x/crypto/ssh/termi

[go-nuts] Gitlab CI loses its marbles attempting go get.

Anyone seen behavior like this before? GOPATH=/builds/esr/reposurgeon go get golang.org/x/crypto/ssh/terminal # golang.org/x/sys/unix src/golang.org/x/sys/unix/env_unix.go:30: undefined: syscall.Unsetenv src/golang.org/x/sys/unix/ioctl.go:18: undefined: runtime.KeepAlive src/golang.org/x/sys/unix/

Re: [go-nuts] Reflecting on an outer struct from a method of an inner one.

On Thursday, September 6, 2018 at 9:45:37 PM UTC-4, Nigel Tao wrote: > > Asking about embedding and reflection sounds like an XY problem > (http://xyproblem.info/). Can you elaborate on what "walk through the > user-defined methods of a Cmd-like interpreter instance" is? > Sure. My reposurge

[go-nuts] Reflecting on an outer struct from a method of an inner one.

This question is intended to assist implementation of a Go workalike for the Python Cmd library. This workalike will be made publicly available, The attached program lists Inner id as expected - that is, the fieldnames of the Outer structure. But ListFields is a method of Inner. In the attac

Re: [go-nuts] Space-optimization question

On Wednesday, September 5, 2018 at 10:38:16 AM UTC-4, Jan Mercl wrote: > > On Wed, Sep 5, 2018 at 4:23 PM Eric Raymond > wrote: > > > Matters in my case because the deserialization of a repository history > can contain hundreds of thousands of constants like

Re: [go-nuts] Space-optimization question

On Wednesday, September 5, 2018 at 10:12:51 AM UTC-4, Jan Mercl wrote: > > On Wed, Sep 5, 2018 at 4:00 PM Eric Raymond > wrote: > > > If I have multiple occurrences of a string constant in source code - > say, "M" - can I count on the compiler to create

[go-nuts] Space-optimization question

If I have multiple occurrences of a string constant in source code - say, "M" - can I count on the compiler to create one static instance and pass references to it everywhere? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

Re: [go-nuts] Reference to type satisfying a specified interface

On Tuesday, September 4, 2018 at 7:13:50 AM UTC-4, Jan Mercl wrote: > > I'm worried the suggested editing pass could make the docs better for > newbies and less useful for non-newbies in the same time. Maybe the docs > for beginner's should be the edited, but separate _version_ of the current

Re: [go-nuts] Reference to type satisfying a specified interface

On Friday, August 31, 2018 at 6:55:28 AM UTC-4, ohir wrote: > > On Thu, 30 Aug 2018 18:41:48 -0700 (PDT) > Eric Raymond > wrote: > > > Oh, actually, I have one other issue; how to translate virtual methods > in a > > Python base class into Go's object m

Re: [go-nuts] Reference to type satisfying a specified interface

On Friday, August 31, 2018 at 12:06:44 AM UTC-4, Nigel Tao wrote: I'm only guessing, but I think Ian's "which docs did you look at" was referring to your previous "I was unable to extract this enlightenment from the documentation, despite sweating over it pretty hard" Well, that could be. I gro

Re: [go-nuts] Some background on reposurgeon and my Go translation problem

On Friday, August 31, 2018 at 4:30:08 AM UTC-4, Jan Mercl wrote: > > In case you haven't heard it before, Google was thinking on the same lines > and released Grumpy last year: > https://opensource.googleblog.com/2017/01/grumpy-go-running-python.html. > I never used the tool and it may possibl

[go-nuts] Some background on reposurgeon and my Go translation problem

There's been enough interest here in the technical questions I've been raising recently that a bit of a backgrounder seems in order. Back in 2010 I noticed that git's fast-import stream format opened up some possibilities its designers probably hadn't anticipated. Their original motivation was

Re: [go-nuts] Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 8:31:44 PM UTC-4, Ian Lance Taylor wrote: > > > That was helpful. I feel like I have a more solid grasp now, though > I'm a > > bit worried about what details might have changed. Is there any chance > of > > getting the author to update this and add it to th

Re: [go-nuts] Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 7:25:10 PM UTC-4, Nigel Tao wrote: > > On Fri, Aug 31, 2018 at 4:18 AM Burak Serdar > wrote: > > If b is an interface to a *Blob, what's stored in the slice is {Type: > > *Blob, Value: pointer to the object}. A copy of this interface value > > is also in the ma

Re: [go-nuts] Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 3:00:18 PM UTC-4, Burak Serdar wrote: > > If you're porting from another language, you're likely to encounter > this situation soon, if not already. > Right, and because Python code often makes aggressive use of runtime polymorphism it's *particularly *likely

Re: [go-nuts] Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 2:18:38 PM UTC-4, Burak Serdar wrote: > > If b is an interface to a *Blob, what's stored in the slice is {Type: > *Blob, Value: pointer to the object}. A copy of this interface value > is also in the map. So you have two copies of the interface value, > both poi

Re: [go-nuts] Reference to type satisfying a specified interface

> > If Event is your interface and EventImpl is your struct, what you need > is a map[string]Event, not map[string]*Event. Make sure you put > &EvenImpl{} to your slices and maps, not EventImpl{} > > Here'a what is confusing me. Yes, I can write _mark_to_object map[string]Event and b.re

[go-nuts] Re: Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 1:32:18 PM UTC-4, Akram Ahmad wrote: > > Your work on porting *reposurgeon* (from Python into Go) for improved > performance sounds very cool, Eric (BTW, your work in, and musings on, Lisp > and UNIX have been a huge influence on my evolution as a programmer. Kud

Re: [go-nuts] Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 1:14:25 PM UTC-4, Jan Mercl wrote: > > On Thu, Aug 30, 2018, 18:57 Eric Raymond > > wrote: > >> I'm trying to translate this to Go in a type-safe way. To do this, I need >> to be able to write two declarations: "Slice of p

[go-nuts] Reference to type satisfying a specified interface

I apologize if this seems like an elementary question, but web searches and reading the Go documentation is not turning up an answer. I'm in the process of translating reposurgeon, an editor for version-control histories, from Python into Go for improved performance, .The central data structure

Re: [go-nuts] Re: Unexpected behavior of %+02d in Sprintf() and friends

On Wednesday, August 29, 2018 at 7:57:23 AM UTC-4, Borman, Paul wrote: > > Is it possible you used the format string “+%02d” vs “%+02d”? The first > will give you the +00 you expected while the second is +0, as discussed. > Alas, no. Here's the line from my test program: fmt.Printf("%s: %+02d

[go-nuts] More trouble with date formatting

The attached program emits go1.10.1: value '2010-10-27 18:43:32 + +' error on my system. Note the duplicated zone field. Is this expected? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiv

[go-nuts] Re: Unexpected behavior of %+02d in Sprintf() and friends

On Tuesday, August 28, 2018 at 4:49:02 PM UTC-4, peterGo wrote: > > "Width is specified by an optional decimal number immediately preceding > the verb. If absent, the width is whatever is necessary to represent the > value. " > > https://golang.org/pkg/fmt/ > > Width is two. > Thanks for the cla

[go-nuts] Unexpected behavior of %+02d in Sprintf() and friends

Under Go 1.10.1, feeding an 0 value to a %+02d specifier sometimes yields "+0", not "+00". The attached tiny Go program may reproduce this behavior. I say "may" because I first observed it in a series of unit tests of date format conversions - in different format strings %+02d expanded differ