Re: [go-nuts] bodyless functions in standard libary
https://golang.org/doc/asm -- Aram Hăvărneanu -- 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] go process memory limits and gurantees
On Sun, Aug 7, 2016 at 4:37 AM, gaurav <gauravagarw...@gmail.com> wrote: > Please let me know if there is something I have missed to read regarding > this or if there is already a way to achieve this? There is not. -- Aram Hăvărneanu -- 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] Where can I find the format definition of stack trace?
On Wed, Jun 29, 2016 at 3:28 PM, Jingguo Yao <yaojing...@gmail.com> wrote: > Could you point out where you find the format information? As far as I know, it is not formally documented anywhere (and can change at any time). -- Aram Hăvărneanu -- 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] Where can I find the format definition of stack trace?
> What is the meaning of +0x2d following the line number? The address of the assembly instruction relative to the start of the function. > And what is the meanings of the numbers in > Commit(0xc8201a86e0, 0x0, 0x0)? Those are the function arguments. -- Aram Hăvărneanu -- 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] Go Fonts: request for feedback
On Fri, Feb 3, 2017 at 8:12 PM, roger peppe <rogpe...@gmail.com> wrote: > Perhaps a slightly esoteric request: I'd love to see the fonts made > available in Plan 9 (acme compatible) font format. I tried doing the > conversion and all bar one font size looked terrible. I also ask for this, and confirm that the conversion done by fontsrv (using either FreeType or Quartz) is not great. Thanks, -- Aram Hăvărneanu -- 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] cross-compilation for go-gl applications
Those packages use cgo, so you will need a gcc-based toolchain for your target platform. Either you will have to build it yourself (doing that on Windows is probably challenging), or perhaps you can find a prebuilt gcc (good luck with that). Make sure to install the relevant OpenGL headers and libraries for your target and that your cross-compiler can find them. Then you can just do something like (substitute for your target): CGO_ENABLED=1 CC=sparcv9-solaris2.12-gcc GOOS=solaris GOARCH=sparc64 go build foo Depending on a few other factors you might or might not need to explicitely set internal or external linking. CGO_ENABLED=1 CC=sparcv9-solaris2.12-gcc GOOS=solaris GOARCH=sparc64 go build -ldflags='-linkmode=external' foo If I were you, I would rather find a way to build natively. -- Aram Hăvărneanu -- 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] Cross Compiling and Go Native and "What is a C library"
On Thu, Jan 26, 2017 at 7:00 PM, Jan Mercl <0xj...@gmail.com> wrote: > or any POSIX-like OS for that matter On Solaris the syscall interface is a private, unstable interface (just like on Windows), and the only supported way to interact with the system is through the vendor-supplied libc. Go on Solaris always uses libc, it doesn't make system calls directly like on Linux. In fact macOS is just like Solaris here (except the syscall interface breaks even more often), but we just ignore it and hope for the best (which is a shame, because Go binaries for macOS will never be forward-compatible this way) . -- Aram Hăvărneanu -- 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] Cross compilation to see assembly outputs with go tool compile
You might also be interested in GOOS=linux GOARCH=arm go build -gcflags='-S' foo or GOOS=linux GOARCH=arm go build -gcflags='-S' -asmflags='-S' foo -- Aram Hăvărneanu -- 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] Cross-compilation of golang assembly via 'go tool asm'
On Tue, Sep 13, 2016 at 6:19 AM, <pcj...@gmail.com> wrote: > My interpretation of golang's assembly is that it represents an intermediate > pseudo-language that is transformed via "instruction selection" to a > concrete form. Correct, but this pseudo-language is not portable between architectures. > Therefore, is it possible to re-write the above to a cross-compilable form? The assembly in the Go distribution is already cross-compilable, but looking at your example you are not concerned whether the assembly is cross-compilable or not (that depends on the toolchain, and not on the assembly code), but you want the assembly to be portable between architectures. Apart from the most trivial of cases, this is not possible. Different targets use different instructions and different registers. The Go assembler uses the same *syntax* on every architecture, so it can be parsed and processed by a single program, however the assembly code required for each target is very different. -- Aram Hăvărneanu -- 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] How to fork or create a subprocess?
You can't use fork in multithreaded programs (except to call exec), and all Go programs are multithreaded. You can use os/exec to start new programs, however. -- Aram Hăvărneanu -- 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] Generating x/sys/unix cross-platform
In general, the z files are generated on the target platforms; if you need to generate ppc64 files, you need a ppc64. They usually don't cross-generate, so to speak. However, by obtaining a cross-compiler, setting CC, and modifying the generation scripts, they can be generated on any host. After all, that is how they were originally generated, before Go ran on that platforms. -- Aram Hăvărneanu -- 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] Re: Ideas for a Go interpeter, feedback requested
On Mon, Aug 22, 2016 at 1:48 PM, Seb Binet <seb.bi...@gmail.com> wrote: > do you think it would be feasable to have a GOARCH=vm backend which would > just be the portable "Ken's National 32000" ASM, have all the ssa > optimizations from the gc toolchain, and have a vm interpret this? Everything is possible, it's just software. Some people thing everything is feasible too, that's the problem with our industry; however, in this case what you describe is very feasible. I have semi-concrete plans for such a port after I am done with sparc64 and arm64 SSA. -- Aram Hăvărneanu -- 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] Stalking people online for thought crimes! This is what the Go project has succumbed to!
ur dark agenda of manipulation, control and deceit. But you are not fooling everyone, you are not fooling me. I will not be controlled by a neo-puritan organization. If there's anyone left who still has the power and courage to say no to these bullies, consider who you should prosecute: 1) a thief who makes money from stolen intellectual property 2) someone who realized the thief's command of the English language is so poor, he cannot be understood. Thank you. PS: I suspect it's the thief himself who reported me to your organization, and because your extrajudicial court works so well, you have managed to sentence the wrong person. -- Aram Hăvărneanu Go contributor Not a thief Critical thinker -- 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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
> On Mon, Oct 17, 2016 at 8:29 PM, Liam Breck <networkimp...@gmail.com> wrote: >> bytes.Replace(s []byte, pos int, len uint, new []byte) > > I have no idea what this bizarre hypothetical function does. It's an > awful interface that aims to solve an unknown problem nobody has > claimed to have. > > Also, bytes.Replace already exists. > Also, slice lengths are signed integers, not unsigned integers. I suggest you familiarize more with slices before suggest these "improvements". -- Aram Hăvărneanu -- 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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
On Mon, Oct 17, 2016 at 8:29 PM, Liam Breck <networkimp...@gmail.com> wrote: > bytes.Replace(s []byte, pos int, len uint, new []byte) I have no idea what this bizarre hypothetical function does. It's an awful interface that aims to solve an unknown problem nobody has claimed to have. Also, bytes.Replace already exists. -- Aram Hăvărneanu -- 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] Re: Tooling experience feedback
On Wed, Oct 19, 2016 at 7:27 PM, Nate Finch <nate.fi...@gmail.com> wrote: > Please give us an easy way to ensure all tests in a list of packages compile Do something like this: go test -toolexec wrapper -exec success pkgs... Where wrapper is a binary that dispatches to the compiler, but a nop when called with the linker, and success is a binary that just exits successfully. -- Aram Hăvărneanu -- 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] Re: Deleting the /r/golang subreddit
The disconnect between what the Go team acting as moderators think about themselves, and what the reddit thinks about the moderator is disconcerting, and it proves that these people are the wrong people for the job. Because some guy (not associated with either Go or /r/golang) abused his power, their solution is to abuse **their** moderator powers to nuke /r/golang from orbit (shit, who cares about the 25k+ people there, let's not even inform them). Wow. A moderator is a servant to a community and answers to it. He is not the *owner* of a community. His job is to remove spam and ban spammers, not to delete reddits. You are not the owners of /r/golang. The people there are. You are some guys hired to do a job. If you don't want it anymore, no problem, I'm sure there are plenty of candidate replacements. If you don't like /r/golang, no problem, there's a community for every type of individual. It does not mean you have the right to delete it. -- Aram Hăvărneanu -- 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] Avoiding function call overhead in packages with go+asm implementations
On Fri, Nov 18, 2016 at 4:41 AM, Caleb Spare <cesp...@gmail.com> wrote: > Aram gave me the idea of using //go:linkname as a hacky workaround; > this doesn't work within a single package What do you mean exactly? It works here, in fact, I use this. -- Aram Hăvărneanu -- 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] Golang asm to real asm table/doc/tool
Hi Matt, There isn't any such document, but you can read the source code or use objdump. -- Aram Hăvărneanu -- 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] Golang asm to real asm table/doc/tool
On Tue, Nov 29, 2016 at 8:59 PM, matt <matthew.horsn...@gmail.com> wrote: > Where in the source code does it map say MOVBU.P to ldrb post increment? It's complicated, there's no trivial easily-visible mapping (although for this one instruction the actual concrete mapping chosen is probably trivial), there's relatively complex code that decides what to do with an instruction like MOVBU.P. Look in oplook, buildop and asmout. However, for the vast majority of instruction that still doesn't actually say "ldrb post increment" anywhere in the code. You just have to follow the code and functions like oprrr, opmvl, etc, and then read the bits. It's much easier to use objdump if you are unsure of a particular instruction. However, you rarely have to use objdump. Mostly only to add new instructions. Go uses consistent calling convention and syntax between architectures, and a large class of consistent pseudo-instructions like MOVW, MOVD, etc; the only things that vary are the more-specialized instructions and the name of the register. If you need a specialized instruction it's easy. It usually has the same name as the one from the platform manual (there are exceptions). If you don't need specialized instructions, just use generic instructions with whatever addressing mode that you want. If a particular address mode is not supported, or a multi-instruction sequence is not generated for a particular architecture and complex addressing mode the assembler will complain. You can always know what code means semantically, so there's no problem. Sometimes you want to see the actual generated code without any pseudo-instructions, when this is the case, just use objdump. I understand all this is not ideal, but it really isn't that bad. I write more assembly than Go these days, and I never have a problem with the lack of this mapping. That being said, for sparc64 there is indeed a much better documented mapping. -- Aram Hăvărneanu -- 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] Connect to a mainframe
go get ibm.com/mainframe -- 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] Re: Go on Solaris 10 amd64
What's the question? Go works on Solaris 11 and later only (including illumos). It does not work on Solaris 10 and likely never will because Solaris 10 lacks event ports. -- Aram Hăvărneanu -- 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] why golang's tuntime.gogo not restore normal registers
Because in Go general purpose registers are caller save. -- Aram Hăvărneanu -- 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] Re: Go one-line installer
> most Linux users are used to setting environment variables and > installing from tarballs. No, most Linux users are used to installing from package managers. Unless you were referring to installing Go in particular, where I conjecture that most Linux users who don't use some package manager to install Go, are installing from source. > The era of executable installers has not died on Windows or on Mac. I can't speak for Windows, but macOS (or OS X, or Mac OS X) never had executable installers like Windows had. It had .pkg installers, which are not the same thing at all, and even those are pretty rare today, restricted mostly to software that has to install kernel components and such. Most programs install by copying from zip/dng files or by installing from the App Store (a package manager). Mac users most certainly aren't used to executable installers. > I think it would be a lot more productive to spend that time working > on the technical problem The problem you are mentioning is the halting problem. There is no way reliably set configuration variables without solving the halting problem. I do not consider time spent on the halting problem to be productive time. Sorry. -- Aram Hăvărneanu -- 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] few questions about runtime implementation
> 1. Is there any noticeable benchmark difference between internal > linking and external linking? A benchmark testing what? > IIUC, when I use external linking, runtime/cgo is used for OS thread > creation. In that case Go doesn't allocate the system stack itself. It's more complicated than that. By default, user-usage of cgo (when *you* import "C") uses external linking, stdlib-usage of cgo (e.g. os/user) uses internal linking, and non-cgo builds tend to use internal linking, however the type of linking (internal or external) is orthogonal to whether cgo (so runtime/cgo) is used or not. You can also use cgo with internal linking (except on systems which don't support it), and you can use cgo with internal linking (on system that support it). So your question is really about cgo, and not about linking. That being said, using runtime/cgo will indeed change the thread creation method on some systems, but not on others. On Solaris threads are always created the same way irrespective whether cgo is used or not. Plan 9 doesn't have cgo at all, so the point is moot. On Windows threads are created very similarly in both cgo and non-cgo cases, but there is a slight difference. On these three platforms the kernel always provides the system stack even when internal linking is used. On other systems like Linux and FreeBSD there indeed are fundemental differences to how threads are created and how stacks are allocated in the cgo and non-cgo cases. As you've surely discovered, on these other systems (most systems, really) Go allocates the system stacks before creating the threads, which are instructed to use this already-created stack. > So, I assume there are some difference related to memory usage. On Solaris there is no difference because they create threads the same way in all cases. On Windows, when cgo is used, the default thread stack size of 2MB is used for the system stack. When cgo is not used the threads are created with a 128kB stack instead. On other systems like Linux and FreeBSD some multiple of 8kB (usually 1) is used for the system stacks in the non-cgo case. In the cgo case, the default thread stack size is used (probably 2MB). I am ignoring non-standard build modes like c-shared for this discussion. The exact details vary in those cases but its the same fundamental idea. However one must note that this is virtual memory, not physical memory. These stacks only use address space, they only use as much physical memory as needed, usually one or two pages of memory (a page is usually 4kB but different from system to system), possibly with the exception of Windows which might require the use of use more physical memory. In principle, if you explicitely use cgo (make actual use of it) you might cause more physical memory to be mapped onto your stacks, than if you don't explicitely use cgo, but if you compare a pure Go program that uses runtime/cgo, with the same one that doesn't (perhaps due to changing linking method), there shouldn't be any difference in physical memory usage to a first approximation > Is runtime.newosproc0 reachable? IIUC, newosproc0 is called by > _rt0_$GOARCH_$GOOS_lib if runtime/cgo is not used. However, > _rt0_$GOARCH_$GOOS_lib is invoked only if buildmode=c-shared or > buildmode=c-archive. In addition, c-shared and c-archive always use > external linking. When is newosproc0 actually called? You are correct that on ELF platforms using c-shared or c-archive seems to force external linking, but just as I explained earlier about cgo, the build mode and the link mode are more or less conceptually orthogonal. That being said I do not know if c-shared and c-archive can be made to work with internal linking or not, nor what are the specific implications of that configuration. On Windows c-shared and c-archive don't seem to force external linking, but I am not sure whether internal linking is supposed to work or not. -- Aram Hăvărneanu -- 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] few questions about runtime implementation
> nitpick. os3_solaris.go.go set stack size by itself, instead of > using default one. is it intentional? You mean why does it explicitely ask for a 2MB stack when 2MB stacks are the default? I can't remember the exact reason I did that but it was a workaround for some sort of bug. -- Aram Hăvărneanu -- 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] pet peeve: it's Go not golang
And certainly neither Google Go nor Google golang. -- Aram Hăvărneanu -- 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] Reading stdlib for education about go?
The good parts. -- Aram Hăvărneanu -- 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] Does golang support SystemTap well?
I would not use systemtap, its design is fundamentally flawed and requires special kernels. Linux supports now eBPF in mainline, which is a superior technical solution. Note that NO TRACER can support function return tracing in Go (including DTrace), for the reasons outlined above. In order to support function return we would have to change the Go calling convention. -- Aram Hăvărneanu -- 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: [golang-dev] Go += Package Versioning
[+cc golang-nuts, it was lost at some point] I find it unexpected that to compute a version you need information not from one, but from two places that use very similar but ultimately different syntax. In vgo the major version has to be specified in Go import paths, and the minor version needs to be specified in go.mod file, which is not Go code but looks very similar to Go code. Why not just use Go code throughout? We could extend Go syntax in a backwards-compatible way to be able to express all the information contained in the go.mod file. The bulk of the code would continue to import old-style, "bare", imports, while a single, or perhaps a small number of Go files would encode the information required for version management using new-style imports. Perhaps this file, or files could have standardized names, zmod.go, or whatever (please don't bikeshed the name). These files could be guarded by build-tags, so old compilers ignore them, just like how old compilers ignore the go.mod file. -- Aram Hăvărneanu -- 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] Re: Go += Package Versioning
> Ah… yes, that would probably let me work on it. Didn’t occur to me > — thanks for pointing it out. It seems unpleasant to deal with, > though, especially since there is a non-zero chance that you then > commit your go.mod file with that change inadvertently. See my proposal here: https://github.com/golang/go/issues/23972#issuecomment-368077927 -- Aram Hăvărneanu -- 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] go build -o option not creating a standalone executable, pls help
I can guess that you are building a mac binary and then try to run it on Linux. You need to cross-compile your binary for linux/amd64: GOOS=linux GOARCH=amd64 go build foo. -- Aram Hăvărneanu -- 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] Go 1.8 or higher on Solaris sparc64.
The solaris/sparc64 Go port project has been discontinued until further notice. -- Aram Hăvărneanu -- 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] Go fonts for linux (plan9port) acme?
Window's font rendering is simply wrong. Linux's is very similar to macOS's. I tried the Go fonts in acme, but reverted to Lucida Grande. -- Aram Hăvărneanu -- 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] How to add a new operator
Start with go/src/cmd/compile/internal/syntax and go from there. -- Aram Hăvărneanu -- 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] go language sensitive editor?
On Thu, Nov 22, 2018 at 8:54 AM Bakul Shah wrote: > What would be helpful is if 'go doc' had an -n option to show > filename:linenumer next to the go definitions its shows so that I > can right click on it and see the source file with cursor on the > right line! I subscribe to that idea. -- Aram Hăvărneanu -- 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] Are there typed variables?
I hope so. -- Aram Hăvărneanu -- 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] Any non-split 'print' functions available?
For this type of thing I'd recommend a debugger. -- Aram Hăvărneanu -- 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/CAEAzY38F9C1%3DYM-xnvOo9h9%2Bn8SQqyO52im%2BYWdsU4mvhCUYJw%40mail.gmail.com.
[go-nuts] Typed DSL in Go (or sum types and GADTs in Go)
Dear Go community, For your delight, bemusement, or horror, I present to you generalized algebraic data types in Go: https://play.golang.org/p/83fLiHDTSdY | This file implements a deep embedding of a typed-DSL in Go. | The representation is type-safe (we cannot construct ill-typed | terms) and accepts multiple interpretations. The type system | of the target language is identity-mapped to the Go type | system such that type checking of the DSL is hoisted up to | type-checking the Go code that contains the target language | expression. | | Normally this requires either GADTs or higher-rank types. | I show that it is possible to encode it in Go, a language | which doesn't have GADTs (nor regular ADTs for that matter), | nor higher-rank types. I exploit the duality between universal | and existential quantification and encode sum types using | the existential dual of the Boehm-Berarducci isomorphism. | Unlike the Boehm-Berarducci encoding, my encoding is not | universally-quantified, but existentially quantified, and | does not require higher-rank polymorphism capitalizing on | the fact that Go interfaces are existential types. | | Just like an algebraic data type, my encoding is closed, | its usage is type safe, and the match operations are checked | at compile-time for exhaustivness. | | A related, alternative encoding would be to encode the GADT | into tagless-final style. This requires polymorphic terms, | which in Go can only be functions, which are not serializable. | My encoding is bidirectionally serializable. | | As presented, the encoding is closed because I want to show | that I can encode every GADT property. It is also possible, | and perhaps desirable to make the encoding open, which | solves the Expression Problem. | | Although GADT invariants are encoded using Go generics | (which are a form of universal quantification) the encoding | does not require that the Curry–Howard isomorphism holds, | it is purely existential. In fact, if one only wants plain | ADTs, generics are not needed at all. Go can encode sum | types, and was always able to. You will need Go tip to compile this. -- Aram Hăvărneanu -- 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/CAEAzY381kQ0hptu1GbPwKHWAjyUXCj31HoVnOVcCvuXZhSo4rw%40mail.gmail.com.
Re: [go-nuts] Have you seen any static analysis checker for sync.Mutex.Unlock() call?
Congratulations on solving the halting problem! PS: use defer otherwise you aren't panic-safe. -- Aram Hăvărneanu -- 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/CAEAzY38W4miPRdbZZnogYF7KNjEOdAK0KCi4ukbdwhmo%2BZSP6Q%40mail.gmail.com.
[go-nuts] Re: Typed DSL in Go (or sum types and GADTs in Go)
And now updated to Go 1.18: https://gotipplay.golang.org/p/kmLRcsXGxSs | This file implements a deep embedding of a typed-DSL in Go. | The representation is type-safe (we cannot construct ill-typed | terms) and accepts multiple interpretations. The type system | of the target language is identity-mapped to the Go type | system such that type checking of the DSL is hoisted up to | type-checking the Go code that contains the target language | expression. | | Normally this requires either GADTs or higher-rank types. | I show that it is possible to encode it in Go, a language | which doesn't have GADTs (nor regular ADTs for that matter), | nor higher-rank types. I exploit the duality between universal | and existential quantification and encode sum types using | the existential dual of the Boehm-Berarducci isomorphism. | Unlike the Boehm-Berarducci encoding, my encoding is not | universally-quantified, but existentially quantified, and | does not require higher-rank polymorphism capitalizing on | the fact that Go interfaces are existential types. | | Just like an algebraic data type, my encoding is closed, | its usage is type safe, and the match operations are checked | at compile-time for exhaustivness. | | A related, alternative encoding would be to encode the GADT | into tagless-final style. This requires polymorphic terms, | which in Go can only be functions, which are not serializable. | My encoding is bidirectionally serializable. | | As presented, the encoding is closed because I want to show | that I can encode every GADT property. It is also possible, | and perhaps desirable to make the encoding open, which | solves the Expression Problem. | | Although GADT invariants are encoded using Go generics | (which are a form of universal quantification) the encoding | does not require that the Curry–Howard isomorphism holds, | it is purely existential. In fact, if one only wants plain | ADTs, generics are not needed at all. Go can encode sum | types, and was always able to. While this code looks like performance art, it establishes an important result. We always felt that generics are extremely powerful in Go and one of the reasons why we could achieve so much in Go without generics. But this shows this is true in a strict mathematical sense, not just in our intuition. More importantly, I think, is that this shows to other prospective programming language researchers that designing their future language starting from existential types instead of universal types (as it is usually done), is both feasible and perhaps even desirable. What's missing is a way to abstract over type constructors, and it is an open research problem how a language based on existential types, but with abstraction over type constructors would look and feel like. We know in a practical setting Go interfaces "don't blow up", while it's very easy for code that uses generics to "blow up". It is unclear whether this property will continue to hold if we introduce abstraction over type constructors. -- Aram Hăvărneanu -- 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/CAEAzY39f5HD3N%2BxmHehYh4Q4qvFBd4J-2p0QgdsWAG889UWmjA%40mail.gmail.com.
