Re: [go-nuts] Is it possible to build a Go binary without the runtime ?

[Raffaele Sena]

Yes, but there are tools to access the object files. I.e. you can do "go
tool objdump module.a" and get the assembly for your module.


On Tue, Jan 23, 2024 at 4:14 PM Def Ceb  wrote:

> Interesting proposition, though from what I can tell, you're just going
> to end up with goobj files, a somewhat obscure internal format of the
> compiler, rather than a more typical object file format.
>
> Raffaele Sena:
> > Well, if it's a package/module you could build it as a library archive
> > (go build -buildmode=archive) and then disassemble/decompile the library.
> >
> >
> > On Tue, Jan 23, 2024 at 3:18 PM Def Ceb  > <mailto:mikk.mar...@gmail.com>> wrote:
> >
> > No, this is not possible. This is the case for practically every
> other
> > language, even C. Unless you intend on inspecting assembly text
> instead
> > of a real working binary.
> > The symbol table + debug symbols built into the binary by default
> > should
> > make finding the `main.main` function trivial with just about any
> > reverse engineering tool.
> >
> > 'Karolina GORNA' via golang-nuts:
> >  > Hi everyone,
> >  >
> >  > I would like to build my Go program and to reverse-engineer it. I
> > would
> >  > find it easier to build it without the runtime and to statically
> > analyse
> >  > only the binary of the program.
> >  >
> >  > Is it possible and if yes, how please ?
> >  >
> >  > Thank you for your time.
> >  >
> >
>  
> >  > Les informations contenues dans ce message électronique ainsi que
> > celles
> >  > contenues dans les documents attachés sont strictement
> > confidentielles
> >  > et sont destinées à l'usage exclusif du (des) destinataire(s)
> > nommé(s).
> >  > Toute divulgation, distribution ou reproduction, même partielle,
> > en est
> >  > strictement interdite sauf autorisation écrite et expresse de
> > l’émetteur.
> >  > Si vous recevez ce message par erreur, veuillez le notifier
> >  > immédiatement à son émetteur par retour, et le détruire ainsi que
> > tous
> >  > les documents qui y sont attachés.
> >  >
> >  > The information contained in this email and in any document
> > enclosed is
> >  > strictly confidential and is intended solely for the use of the
> >  > individual or entity to which it is addressed.
> >  > Partial or total disclosure, distribution or reproduction of its
> >  > contents is strictly prohibited unless expressly approved in
> > writing by
> >  > the sender.
> >  > If you have received this communication in error, please notify us
> >  > immediately by responding to this email, and then delete the
> > message and
> >  > its attached files from your system.
> >  >
> >
>  
> >  >
> >  > --
> >  > 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
> > <mailto:golang-nuts%2bunsubscr...@googlegroups.com>
> >  > <mailto:golang-nuts+unsubscr...@googlegroups.com
> > <mailto:golang-nuts%2bunsubscr...@googlegroups.com>>.
> >  > To view this discussion on the web visit
> >  >
> >
> https://groups.google.com/d/msgid/golang-nuts/9e309ee6-18ca-48b2-bf6b-e5a9e7325838n%40googlegroups.com
> <
> https://groups.google.com/d/msgid/golang-nuts/9e309ee6-18ca-48b2-bf6b-e5a9e7325838n%40googlegroups.com>
> <
> https://groups.google.com/d/msgid/golang-nuts/9e309ee6-18ca-48b2-bf6b-e5a9e7325838n%40googlegroups.com?utm_medium=email_source=footer
> <
> https://groups.google.com/d/msgid/golang-nuts/9e309ee6-18ca-48b2-bf6b-e5a9e7325838n%40googlegroups.com?utm_medium=email_source=footer
> >>.
> >
> > --
> > 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
> > <mailto:golang-nuts%2bunsubscr...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/golang-nuts/a7746ded-49cb-4a8c-aa00-e2bb8676b23a%40gmail.com
> <
> https://groups.google.com/d/msgid/golang-nuts/a7746ded-49cb-4a8c-aa00-e2bb8676b23a%40gmail.com
> >.
> >
>

-- 
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/CANKfucame_mkBpvGf_3iH7cwr_8NeBh7BdbD43-JGooxZcfzTg%40mail.gmail.com.

Re: [go-nuts] Is it possible to build a Go binary without the runtime ?

[Raffaele Sena]

Well, if it's a package/module you could build it as a library archive (go
build -buildmode=archive) and then disassemble/decompile the library.


On Tue, Jan 23, 2024 at 3:18 PM Def Ceb  wrote:

> No, this is not possible. This is the case for practically every other
> language, even C. Unless you intend on inspecting assembly text instead
> of a real working binary.
> The symbol table + debug symbols built into the binary by default should
> make finding the `main.main` function trivial with just about any
> reverse engineering tool.
>
> 'Karolina GORNA' via golang-nuts:
> > Hi everyone,
> >
> > I would like to build my Go program and to reverse-engineer it. I would
> > find it easier to build it without the runtime and to statically analyse
> > only the binary of the program.
> >
> > Is it possible and if yes, how please ?
> >
> > Thank you for your time.
> > 
> > Les informations contenues dans ce message électronique ainsi que celles
> > contenues dans les documents attachés sont strictement confidentielles
> > et sont destinées à l'usage exclusif du (des) destinataire(s) nommé(s).
> > Toute divulgation, distribution ou reproduction, même partielle, en est
> > strictement interdite sauf autorisation écrite et expresse de l’émetteur.
> > Si vous recevez ce message par erreur, veuillez le notifier
> > immédiatement à son émetteur par retour, et le détruire ainsi que tous
> > les documents qui y sont attachés.
> >
> > The information contained in this email and in any document enclosed is
> > strictly confidential and is intended solely for the use of the
> > individual or entity to which it is addressed.
> > Partial or total disclosure, distribution or reproduction of its
> > contents is strictly prohibited unless expressly approved in writing by
> > the sender.
> > If you have received this communication in error, please notify us
> > immediately by responding to this email, and then delete the message and
> > its attached files from your system.
> > 
> >
> > --
> > 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/9e309ee6-18ca-48b2-bf6b-e5a9e7325838n%40googlegroups.com
> <
> https://groups.google.com/d/msgid/golang-nuts/9e309ee6-18ca-48b2-bf6b-e5a9e7325838n%40googlegroups.com?utm_medium=email_source=footer
> >.
>
> --
> 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/a7746ded-49cb-4a8c-aa00-e2bb8676b23a%40gmail.com
> .
>

-- 
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/CANKfucabsHWfxsMhcnPvVFhs3ePYNLH%2BNe6G0VsJQ%2BGXNyEnzA%40mail.gmail.com.

Re: [go-nuts] a simple linux audio player pkg?

[Raffaele Sena]

I have used github.com/jfreymuth/oggvorbis to read the ogg file (and
convert to PCM) and github.com/ebitengine/oto/v3 to play the PCM.
I don't know of a full ogg player in Go


On Wed, Nov 22, 2023 at 2:02 PM 'Mark' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Is there a simple vorbis/oga audio player package for Go that works on
> Linux.
> The only API I need is something like this:
>
> player.SetFilename(string) error // string is say tune.ogg; stops playing
> previous if any
> player.Play(float32) error // plays current filename from given second
> e.g. 0.0 for the beginning
> player.Pause() (float32, error) // pauses current playing and returns
> position
> player.Resume() error // resumes playing
> player.Secs() float32 // returns current position
>
> The ones I've seen on awsome go either don't seem to play ogg format or
> are far more sophisticated than I need.
>
> --
> 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/a38e3a9b-a357-4c85-aa4d-a7a4322ec216n%40googlegroups.com
> 
> .
>

-- 
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/CANKfucYOa0VRf%3DqX1-wvggqLxRGTvN2k40yhAHsAHTFx668bxQ%40mail.gmail.com.

Re: [go-nuts] when doing a WalkDir of a FileSystem, how do you get access to the path that you are working on

[Raffaele Sena]

The function you implement (WalkDirFunc should receive "p" as the path to
the parent  (that seems to be what you want) and "d" as the current
directory entry.
I am not sure why in your example you are showing full paths to the file
for "p".



On Sat, Jan 14, 2023 at 3:39 PM Pat Farrell  wrote:

> I'm using the reasonably new FileSystem style to do the usual directory
> walk
> processing every file in the usual recursive manner.
> I can't figure out how to get the directory data (the path up to the last
> /)
> even though I can see it in the output.
>
> I am missing the proper name of the getter, or perhaps a cast/type
> assertion
>
>
> Playground:
> https://go.dev/play/p/Fde-rAA5YZI
>
> The key code is
> fsys := os.DirFS(".")
> fs.WalkDir(fsys, ".", func(p string, d fs.DirEntry, err error) error {
> fmt.Printf("%s  struct: %T  %v\n", p, d, d)
>
> which prints "'p" the current file name and extension
> the type of the fs.DirEntry and then the fsDirEntry structure
>
> Something like this:
> csvtsd/csvtsd.go  struct: *os.unixDirent  &{../csvtsd csvtsd.go 0 }
> csvtsd/csvtsd_test.go  struct: *os.unixDirent  &{../csvtsd csvtsd_test.go
> 0 }
> csvtsd/go.mod  struct: *os.unixDirent  &{../csvtsd go.mod 0 }
>
> You can see that the "p" is typically the path and filename
> csvtsd/csvtsd.go
> the type is a  *os.unixDirent
> and there are four fields in the Dirent, the path (up to the last /)
> the filename and extension, and two other fields.
>
> Thanks
>
> --
> 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/99c9d821-be0e-4763-ab40-72e3af61c511n%40googlegroups.com
> 
> .
>

-- 
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/CANKfucZx3QZdJ4heXEXLO6LuB5eE71UwQg3rYNH6BiQzhrvgvg%40mail.gmail.com.

Re: [go-nuts] WebAssembly and Filesystem access

[Raffaele Sena]

tinygo now has a "wasi" target that you can try.



On Fri, Dec 16, 2022 at 2:10 PM 'Kevin Chowski' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I recently learned that WASI (
> https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-intro.md)
> supports filesystem abstractions directly for WASM code.
>
> Is there an plan to integrate this into Go?
>
> On Saturday, November 5, 2022 at 5:59:08 AM UTC-6 Konstantin Khomoutov
> wrote:
>
>> On Fri, Nov 04, 2022 at 02:08:08PM -0700, 'Kevin Chowski' via golang-nuts
>> wrote:
>>
>> [...]
>> > I am on a project which primarily ships a Go command line interface
>> (CLI),
>> > but we have aspirations of using the wasm compilation mode to also
>> > distribute a simple webapp version of it, while sharing most of the
>> code.
>> [...]
>> > The next big hurdle is the fact that we cache things on disk
>> > for later reuse, so things are failing out-of-the-box any time we
>> attempt
>> > to touch the filesystem. Luckily, in our case, the fact that we are
>> > touching the filesystem is a bit incidental (its used as a cache for
>> making
>> > consecutive CLI invocations faster), and as long as the system was
>> > consistent for the lifetime of the main Go process things will work
>> just
>> > fine.
>> >
>> > We /could/ pass a filesystem object across the codebase, and maybe we
>> will
>> > one day we will anyway for some other reasons, but I'd rather not have
>> to
>> > do that just to get further with this webapp prototype: it's a lot of
>> > tedious plumbing, and there is a nontrivial amount of code to touch.
>> >
>> > So instead I decided to try some global-mutable-at-startup variables
>> for
>> > things like os.OpenFile, os.Remove, etc, that should be easy to cleanup
>> if
>> > we decide not to move forward with the prototype; but even then, there
>> are
>> > plenty of random things I have to do to get this to work. I've spent
>> about
>> > 2 hours on this direction so far and I keep hitting unexpected
>> roadblocks -
>> > thus this email seeking out a new strategy.
>> >
>> > Are there any plans to automatically support filesystems on
>> wasm-compiled
>> > Go applications? Even an ephemeral, in-memory filesystem would
>> basically
>> > solve all of my problems without having to change any code on my end,
>> which
>> > would be nice.
>>
>> I'm not a Go developer, but I'd say it is unlikely due to the combination
>> of
>> these two facts:
>>
>> - The os package was implemented as a sort-of grab bag of many features
>> one expects on a typical OS (hence the name). The fact the filesystem
>> operations were implemented in that package directly and not elsewhere
>> is the direct manifestation of that approach.
>> An environment in which WASM runs in a browser is too different from that
>> provided by a typical OS, so I cannot see how one could sensibly
>> implement
>> in GOOS=js.
>>
>> - Even if some sort of FS emulation were to be implemented for GOOS=js,
>> the question is: which one exactly? Keeping stuff in memory in just one
>> way of doing things. While I'm not a web developer, I know of at least
>> session storage and local storage which provide for two levels of
>> persistence beyond keeping stuff in memory. Which one to pick for
>> implementing stuff from the os package?
>>
>> > In lieu of that, does anyone have any tips about how I could go about
>> doing
>> > this in a better way?
>>
>> If you need a hard-and-fast solution, I'd propose you're trying to
>> abstract
>> your stuff away on a wrong level. I think it would be cleaner to factor
>> out
>> your persistence code into a set of functions "store this stuff" and
>> "load
>> that stuff"; the default implementations would call out to the os
>> package, and
>> the wasm implementation would use either approach you select: keeping
>> things
>> in memory, using local storage etc.
>>
>> I mean, trying to implement and pass around through the whole codebase
>> something like a "filesystem accessor" switchable at runtime is only
>> worth it
>> if your code makes heavy use of the filesystem in nontrivial way. I'd say
>> that
>> it's better to abstract away high-level store/load operations.
>>
>> --
> 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/dd8306ab-75bf-4bb6-a9ac-3c9f778665a7n%40googlegroups.com
> 
> .
>

-- 
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 

Re: [go-nuts] [CGO] How can I convert GoString to wchar_t?

[Raffaele Sena]

wchar_t is a 16 bits value representing a UTF16 character so you could
convert Go strings to and from UTF16 using the unicode/utf16 package.


On Sat, Sep 26, 2020 at 11:39 AM Sean  wrote:

> Hi gophers,
>
> I'm trying to write the Golang wrapper for a dll with CGO.
>
> A wrapper that will only work in windows.
>
> I need to be able to send UTF-8 or unicode strings to c.
>
> This issue was never asked on platforms like stackoverflow.
>
> So I couldn't find a solution.
>
> https://github.com/dkager/tolk/blob/master/src/Tolk.h#l72
> line 72
>
> https://github.com/dkager/tolk/blob/master/src/Tolk.h#l100
> line 100
>
> I am adding the code I tried below:
>
>
> package talker
>
> //#cgo windows  CFLAGS: -DGO_WINDOWS -Iinclude
> //#cgo windows  LDFLAGS: -Llib/x64 -lTolk
> //#include "Tolk.h"
> import "C"
> //  import "unsafe"
>
>
> func Load() {
> C.Tolk_Load()
> }
>
> func IsLoaded() bool {
> if C.Tolk_IsLoaded() == false {
> return false
> }
> return true
> }
>
>
> func Unload() {
> C.Tolk_Unload()
> }
>
>
> // problem: the function I can't find a solution for.
> func DetectScreenReader() string{
> return C.GoString(C.Tolk_DetectScreenReader())
> }
>
> func HasBraille() bool{
> b := C.Tolk_HasBraille()
> if (b == false) {
> return false }
> return true
> }
>
> // problem: the second function I can't find a solution for ..
> func Output(text string, interrupt bool) {
> b := C.bool(bool)
> C.Tolk_Output((*C.wchar_t)(text), b)
> }
>
>
>
> error: .\talker.go:39:28: cannot convert text (type string) to type
> *_Ctype_ushort
>
> Sean
>
>- Email: seantolstoyev...@protonmail.com
>
>- GitHub: SeanTolstoyevski 
>
> ‍羚 I’m a software developer. I coding often Python, sometimes Go and
> rarely (C)/C++.
>
> --
> 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/aeaba06b-bb41-3e3a-3ee4-7993b8bb4596%40gmail.com
> 
> .
>

-- 
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/CANKfucbP61nRLwsca1UsQSYq6qq-mMC-ZC8i6mHEGKqra72eAQ%40mail.gmail.com.

Re: [go-nuts] hook into os.Stdout / os.Stderr

[Raffaele Sena]

You can create your own writer and overwrite os.Stdout/Stderr (just supply your 
own write method with the appropriate before/after hooks)

Sent from my iPhone

> On Sep 19, 2020, at 12:38 PM, Alexander Mills  
> wrote:
> 
> Forgive me for this pigeon code, I am looking to do something like:
> 
> os.Stdout.BeforeWrite(func (){
> 
> });
> 
> os.Stderr.AfterWrite(func(){
> 
> })
> 
> so I can hook into the system and clear the terminal before hand, and write a 
> status line, after wards. Is this possible?
> -- 
> 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/86ecac37-cf19-436c-87ed-3f415ca157c4n%40googlegroups.com.

-- 
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/61DE7EF5-0882-4F8E-8DE6-C75A0FBF935D%40gmail.com.

Re: [go-nuts] Re: How to print arrays with commas and brackets

[Raffaele Sena]

One option is to use json.Marshal or json.Encoder.Encode

fmt.Printf("%q", []string{"Hello", "world", "!") would quote the separate
strings and put the square brackets, but doesn't comma separate the items.


On Thu, Aug 6, 2020 at 9:24 AM  wrote:

> Hello Michele
>
> This won't print in the array format rather it would print it in other way.
> stringArray := []string{"Hello", "world", "!"}
> fmt.Printf("[%s]", strings.Join(stringArray , ","))
>
> Output [Hello,world,!]
>
>
>
> On Thursday, October 10, 2019 at 10:41:59 PM UTC+5:30, Michele Caci wrote:
>>
>> Hello Nalin,
>>
>> If you use a slice of strings to hold your data, as an alternative you
>> could go with
>>
>> fmt.Printf("[%s]", strings.Join(your_slice_of_strings, ","))
>>
>> Cheers!
>
> --
> 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/10afc2a5-bbc9-4a21-ab14-112b1cd3e74co%40googlegroups.com
> 
> .
>

-- 
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/CANKfucbi5_%3DfsD99xvMWqMj1ME6r-vu%3D%2B4r0J_y%2Bu55xSLvfgQ%40mail.gmail.com.

Re: [go-nuts] Equivalent of os.Args but on custom input

[Raffaele Sena]

I do something similar for some of my interactive tools and ended up
writing this: https://github.com/gobs/args.
If interested the command parser is here: https://github.com/gobs/cmd.

-- Raffaele

On Mon, Apr 20, 2020 at 10:23 AM Kurtis Rader  wrote:
>
> os.Args simply exposes the arguments passed to the program by the operating 
> system. On UNIX this is typically called "argv" in C/C++ programs. The 
> parsing of those strings into two arguments is done by the shell that runs 
> your elvish program. It is not done by os.Args. I'm not aware of any 
> functionality in the standard Go runtime that does what you want. There are 
> probably third-party packages which do it that you could import. Or, roll 
> your own CLI parser as shown in the stackoverflow question.
>
> On Mon, Apr 20, 2020 at 9:27 AM Michał Łowicki  wrote:
>>
>> Hi,
>>
>> I'm working on a program which will have a prompt to enter commands like:
>>
>> add "foo bar"
>>
>> I need what os.Args provides but on custom input so to above input I would 
>> like to get:
>>
>> []string{"add", "foo bar"}
>>
>> Package os uses runtime_args(), and it isn't exported nor accepts input. Any 
>> idea what can I use instead? As a fallback, I can always implement something 
>> like https://stackoverflow.com/a/46973603, but maybe there is a smarter way 
>> to do it.
>>
>> --
>> BR,
>> Michał Łowicki
>>
>> --
>> 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/CAKu9hcexcyMdjPaWUNd84q0Yhs_PoHCe-jczvhC04vqiU7LPwQ%40mail.gmail.com.
>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> --
> 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/CABx2%3DD8yDKak6DR7-7wrm-W40PFEKXTFv-Hn45OqKicft%2BvMVw%40mail.gmail.com.

-- 
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/CANKfucbJhcS2eGyGFYvTYTvV4j0QThJNJMtfbeR5ptiCWeDuFw%40mail.gmail.com.

Re: [go-nuts] Golang on UnixWare

[Raffaele Sena]

There are instructions on how to bootstrap the toolchain in here:
https://golang.org/doc/install/source
Look for "Bootstrap toolchain".

-- Raffaele

On Mon, Jan 27, 2020 at 4:20 PM Eric Raymond  wrote:
>
> 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  ask 
> the following:
>
> What is the procedure for porting Golang to a reasonably well-behaved, 
> standards-conformant Unix variant?  UnixWare in this case. You can assume the 
> target platform hosts GCC.  It it possible to use gccgo to port the reference 
> compiler? If so, is this procedure documented anywhere?
>
> --
> 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/21750718-83b3-4c30-b3df-85a083961eb7%40googlegroups.com.

-- 
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/CANKfucbrP47eXqfxOv%3D%3D-N%2BYLZiAB7XCrwPJwKSQ2bWWx4M5mg%40mail.gmail.com.

Re: [go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[Raffaele Sena]

Completely agree about "Generics are useful except when their syntax
becomes cryptic". But reading this proposal (quickly, while doing a bunch
of other stuff :), the syntax is very clean and the proposal is very well
thought.


On Thu, May 30, 2019 at 10:44 AM Michal Strba  wrote:

> I agree with that. What exactly do you consider cryptic, though, about
> my proposal? I thought the syntax was very clean. Furthermore,
> regarding relating this to C++, I quote:
>
> > Just to make it clear, you aren't allowed to use operators like +, -, <,
> call methods, or access struct fields of a generic value
>
> I'm just not sure how your sentiment relates to the proposal.
>
> št 30. 5. 2019 o 19:41  napísal(a):
> >
> > Sorry again for the power failure...let me try one last time
> >
> > one of the annoying things you have to deal with as a team member is
> being assigned an "update" of code written by someone who no longer works
> for the team.
> > What makes this annoying is possibility of running into code sections
> that contain "crytic" statements that require lots of effort to understand.
> >  After looking at the link you provided, based on my history dealing
> with unnecessary and avoidable 'cryptic C++,
> >  my input  is:  Generics are a great idea EXCEPT when they allow use of
> cryptic syntax
> >
> > On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
> >>
> >> Hi Gophers! :)
> >>
> >> I've been thinking about generics in Go 2 ever since the original
> contracts proposal and few days ago, ideas finally clicked. One of the main
> things about this proposal is that it deliberately omits the ability to
> restrict the set of types a function can work with. This is a limitation,
> but I hope to convince you that we can still do a vast majority of the
> things we were missing, when we were missing generics.
> >>
> >> I'd love to share my proposal with you and engage in a good faith
> conversation.
> >>
> >> Link to the proposal.
> >>
> >> Here's what the proposal covers:
> >>
> >> 1. Syntax of a new gen keyword.
> >> 2. Generic functions.
> >> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the
> built-in new function).
> >> 4. Semantics of generic values (ability to use them as map keys, ...).
> >> 5. Generic array lengths.
> >> 6. Reflection and interface{}.
> >> 7. Generic types (with two examples: List and Matrix).
> >> 8. Generic methods and their limitations due to reflection.
> >> 9. Generic interfaces.
> >> 10. List of things this proposal can't do.
> >>
> >> Thanks,
> >> faiface
> >
> > --
> > 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/4e266f34-32d8-4b3d-8f45-55da5651ed9e%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAO6k0usA%3D6EdH6mpTPqYnpnEBWNu8GST%2Bam-G2rQEZNPGUPC7A%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANKfuca%2B_CYJ59nSfB8n3zq8D0acXEcfHvV3HtyQEHmZ9xnAAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [ANN] Gio: portable immediate mode GUI programs in Go for iOS/tvOS, Android, macOS, Linux, Windows

[Raffaele Sena]

While I do find it odd that this project doesn't use github, because github
requires an account, but SourceHut currently also requires to sign up for
an account to submit issues or to submit to the mailing list, I don't think
the fact that the demo asks for a GitHub token is really "nefarious".

The demo runs even without passing the token (you get a bunch of messages,
but you also get some results) and looking at the code, the token is
currently only used to authenticate the GitHub library in order to get
extra capacity.

And I guess you can always fork the code clean up the nastiness :)

-- Raffaele

On Sun, Mar 31, 2019 at 5:33 PM Wojciech S. Czarnecki 
wrote:

> On Sun, 31 Mar 2019 06:16:43 -0700 (PDT)
> m...@eliasnaur.com wrote:
>
> > Hi,
> > I'm very happy to announce the first public release of Gio, a project
> for
> > writing portable, hardware accelerated, immediate mode GUI programs in
> Go.
>
> @elias_naur
> Sounds interesting. **BUT**
>
> [Quote from README.md in the repo]
>
> > supply a Github token with the `-token` flag:
> > $ go run gioui.org/apps/gophers -token 
>
> I will gladly translate "supply a Github token...":
>
> "If you want to see my demo trust me and possibly give
> me access to all your repositories hosted on github.
> Remember to trust me!"
>
> Because my code is not on github but sits somewhere in Philadelphia
> datacenter bunker under domain registered on Haitan TLD by an unknown
> European private person. Uph! At least https://gioui.org/ points to G
> cloud
> 216.239.32.0/19 network... but it then redirects to Quonix, Philly.
>
> I recognize real Elias Naur name from this list and other places.
> I do not recall him loudly going out of github, but I know real
> Elias Naur still commits to the Go source tree and other github places.
>
> So — regarding this announcement — I may assume that at best it might
> be a kind of research in "password for chocolate"[1] style. But what if it
> is not?
>
> I wish I was mistaken.
>
> [1] https://www.sciencedaily.com/releases/2016/05/160512085123.htm
>
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> 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.
>

-- 
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: Starlight - run python inside Go to extend your applications - easily

[Raffaele Sena]

If you want a full python interpreter, you should look at
https://github.com/go-python/gpython, but gpython also doesn't have a full
standard library implemented.

-- Raffaele


On Mon, Dec 10, 2018 at 1:58 AM Justin Israel 
wrote:

>
>
> On Mon, Dec 10, 2018, 9:39 PM  wrote:
>
>>
>>
>> On Friday, December 7, 2018 at 9:05:02 PM UTC+1, Nate Finch wrote:
>>>
>>> I’d like to announce starlight -
>>> https://github.com/starlight-go/starlight.
>>>
>>>
>>> Starlight wraps google’s Go implementation of the starlark python
>>> dialect  (most notably found in
>>> the Bazel build tool). Starlight makes it super easy for users to extend
>>> your application by writing simple python scripts that interact seamlessly
>>> with your current Go code… with no boilerplate on your part.
>>>
>>
>> Do you think it is suitable for porting python applications?
>> Usually you go through cgo like this
>> https://www.datadoghq.com/blog/engineering/cgo-and-python/ it could be
>> an interesting alternative.
>>
>>
>
> The documentation for Starlark says it is a subset of python, originally
> targeted at being a configuration language for Bazel. So it wouldn't be
> complete enough to straight port full Python applications, unless you
> really backed alot of it with Go code. The cgo approach gives you full
> access to the CPython API and to embed an interpreter.
>
> Starlight does sound interesting though for allowing specific extension
> scripts for a Go application.
>
>
>>> *Parser by google*
>>>
>>> The parser and runner are maintained by google’s bazel team, which write
>>> starlark-go. Starlight is a wrapper on top of that, which makes it so much
>>> easier to use starlark-go. The problem with the starlark-go API is that it
>>> is more built to be a used as configuration, so it assumes you want to get
>>> information out of starlark and into Go. It’s actually pretty difficult to
>>> get Go information into a starlark script…. unless you use starlight.
>>>
>>> *Easy two-way interaction*
>>>
>>>
>>> Starlight has adapters that use reflection to automatically make any Go
>>> value usable in a starlark script. Passing an *http.Request into a
>>> starlark script? Sure, you can do name = r.URL.Query()["name"][0] in
>>> the python without any work on your part.
>>>
>>> Starlight is built to *just work* the way you hope it’ll work. You can
>>> access any Go methods or fields, basic types get converted back and forth
>>> seamlessly… and even though it uses reflection, it’s not as slow as you’d
>>> think. A basic benchmark wrapping a couple values and running a starlark
>>> script to work with them runs in a tiny fraction of a millisecond.
>>>
>>> The great thing is that the changes made by the python code are
>>> reflected in your go objects, just as if it had been written in Go. So, set
>>> a field on a pointer to a struct? Your go code will see the change, no
>>> additional work needed.
>>>
>>> *100% Safe*
>>>
>>>
>>> The great thing about starlark and starlight is that the scripts are
>>> 100% safe to run. By default they have no access to other parts of your
>>> project or system - they can’t write to disk or connect to the internet.
>>> The only access they have to the outside is what you give them. Because of
>>> this, it’s safe to run untrusted scripts (as long as you’re not giving them
>>> dangerous functions to run, like os.RemoveAll). But at the same time,
>>> if you’re only running trusted scripts, you can give them whatever you want
>>> (http.Get? Sure, why not?)
>>>
>>> *Caching*
>>>
>>>
>>> In a production environment, you probably want to only read a script
>>> once and parse it once. You can do that with starlight’s Cache. This
>>> cache takes a list of directories to look in for scripts, which it will
>>> read and parse on-demand, and then store the parsed object in memory for
>>> later use. It also uses a cache for any load() calls the scripts use to
>>> load scripts they depend on.
>>>
>>> *Work Ongoing*
>>>
>>>
>>> Starlight is still a work in progress, so don’t expect the API to be
>>> perfectly stable quite yet. But it’s getting pretty close, and there
>>> shouldn’t be any earth shattering changes, but definitely pin your imports.
>>> Right now it’s more about finding corner cases where the starlight wrappers
>>> don’t work quite like you’d expect, and supporting the last few things that
>>> aren’t implemented yet (like channels).
>>>
>>>
>>> *Example*
>>>
>>>
>>> Here's a simple example of how easy it is to extend the behavior of your
>>> application with a python script.  Just pass starlight whatever go values
>>> you want your python script to act on, and any changes the python code
>>> makes get reflected in your go code.
>>>
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "log"
>>> "time"
>>>
>>> "github.com/starlight-go/starlight"
>>> )
>>>
>>> // Starlight makes it easy to get values in and out of your starlark
>>> scripts.
>>> // Just pass in pointers 

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

[Raffaele Sena]

Inspired by ESR pytogo (and tired of writing python code), I went the
complete opposite way and came up with pygor:

 https://github.com/raff/pygor

pygor is written in Go, using the Python parser and AST from
https://github.com/go-python/gpython (so right now it only targets Python
3.4). The origin of this was actually a python implementation that I
started  a long time ago, using Python ast, but hat didn't go very far
because it was hard to do Go things in python.

It doesn't generate runnable code, but aspire to generate at least code
that passes the smell test of "go fmt" (with the problem that if "go fmt"
fails to correctly format the code, the translation fails).

pygor also attempt to convert some of the python magic (list and dict
comprehension, for example) to Go, again mainly in order to generate
formatted code. And it also comes with a concept of "runtime"
(automatically imported when needed) to implement a couple of things that
are hard to do inline.

Enjoy,

  Raffaele

-- 
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] Strange behavior of range over composite literal.

[Raffaele Sena]

Thanks for the answers. I tried to read the specs, but didn't go as far as
the parsing ambiguity section :(

-- Raffaele

On Mon, Oct 8, 2018 at 12:20 PM Ian Lance Taylor  wrote:

> On Mon, Oct 8, 2018 at 12:10 PM, Raffaele Sena  wrote:
> >
> > I found a strange behavior (well, I would call it a bug) of for-range
> over a
> > composite literal where the literal type is a user type (or alias). This
> is
> > true for both maps and array/slices, but the following example is with a
> > slice.
>
> For future notice, when asking about a strange behavior, it's always
> extremely helpful to say what the strange behavior is.  There are many
> reasons why we might not see the same behavior.
>
> In this case, search for "parsing ambiguity" in
> https://golang.org/ref/spec#Composite_literals .
>
> Ian
>

-- 
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] Strange behavior of range over composite literal.

[Raffaele Sena]

I found a strange behavior (well, I would call it a bug) of for-range over
a composite literal where the literal type is a user type (or alias). This
is true for both maps and array/slices, but the following example is with a
slice.

My guess is that at the compiler level the for-range statement is expecting
[] followed by {} in order to recognize the composite literal, and misses
the case when the literal type is a user type (i.e. type List []int). Bug
or feature ? :)

-- Raffaele

package main


import "fmt"


type Int int

type List []int


func main() {

// this works

source := List{1, 2, 3, 4, 5}

for _, x := range source {

fmt.Println(x)

}


// this works

for _, x := range []int{1, 2, 3, 4, 5} {

fmt.Println(x)

}


// this works

for _, x := range []Int{1, 2, 3, 4, 5} {

fmt.Println(x)

}


// this doesn't

for _, x := range List{1, 2, 3, 4, 5} {

fmt.Println(x)

}

}

-- 
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] Announcing pytogo. a crude but surprisingly effective Python to Go translator

[Raffaele Sena]

I also, for this kind of things that seems to be coming out once in a
while, tend to start from AST and a "pretty printer". This has limitations
since AST doesn't give you type informations (not that it matters much for
Python) but it's good for a "first pass" of translation.

Here is my latest attempt, prompted by this thread:
https://github.com/raff/gopyr. The initial implementation was in Python,
but then I found https://github.com/go-python/gpython, and I decided to
rewrite it in Go. Not completely done yet.  Next big thing would be making
object methods real object methods (easy, just need to get it done). Then I
would like to move nested classes or nested function to the outer scope.
And then, I am not sure of far I should take. I did list and dict
comprehension, as anonymous function. But should I do generators ?
(anonymous function returning a channel fed by a goroutine ?). Certainly
feasible but at what point would it be better to just leave the code as is
and let the human write idiomatic Go ?

-- Raffaele





On Thu, Oct 4, 2018 at 2:25 AM Eric Raymond  wrote:

>
>
> 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  a
>> Saturday morning project which was never used in anger, so it is naturally
>> quite incomplete.
>>
>>>
>>>
> Oh, good.  We now have direct competition between a swarm-rule approach
> and a deep-reasoning approach. It will be very interesting to see which
> does better in the long run.
>
> --
> 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.
>

-- 
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] Bizarre Error Message (Go 1.9.2)

[Raffaele Sena]

Or you use the "standard" unix trick:

go run ls.go -- ls.go


On Thu, Nov 2, 2017 at 1:55 PM, Ian Lance Taylor  wrote:

> On Thu, Nov 2, 2017 at 10:37 AM, Jon Forrest  wrote:
> >
> > I'm learning Go. Whenever I learn a new programming language I like to
> try
> > to recreate the Unix 'ls' command
> > in that language. I've found that such an exercise is often a good way to
> > get familiar with what a language offers.
> >
> > Here's my environment:
> >
> > $ go version
> > go version go1.9.2 linux/amd64
> > $ cat /etc/redhat-release
> > CentOS Linux release 7.4.1708 (Core)
> >
> > Consider the following trivial program which I've saved as "ls.go":
> >
> > package main
> >
> > import (
> > "fmt"
> > "os"
> > )
> >
> > func main() {
> > for _, arg := range os.Args[1:] {
> > fi, err := os.Stat(arg)
> > if err != nil {
> > fmt.Println(err)
> > return
> > }
> > switch mode := fi.Mode(); {
> > case mode.IsRegular():
> > fmt.Println("regular file")
> > case mode.IsDir():
> > fmt.Println("directory")
> > }
> > }
> > }
> >
> >
> > When I run 'go build ls.go' and then './ls ls.go' I see the output I
> expect,
> > which is
> > 'regular file'.
> >
> > However, when I run 'go run ls.go ls.go' I get the bizarre message
> >
> > can't load package: package main: case-insensitive file name collision:
> > "ls.go" and "ls.go"
> >
> > This is on an xfs filesystem.
> >
> > I don't understand why this error message appeared, nor what it's trying
> to
> > tell me.
> > Plus, I don't understand why running the result of 'go build' works, but
> > building
> > and running the program using 'go run' fails.
>
> `go run` takes multiple files as arguments.  When you type `go run
> ls.go ls.go` you are asking the go tool to build a Go program that
> consists of the contents of ls.go repeated twice.  Before it even gets
> to that point, it says "wait, you've told me the same file name twice,
> that can't be right" and then it starts talking about a
> case-insensitive file name which is certainly confusing.  This is kind
> of hard to avoid using `go run`, as it takes any argument that ends
> with ".go" as meaning a Go file to compile.
>
> Ian
>
> --
> 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.
>

-- 
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 -> C++ transpiler idea: Miracle child or horrible abomination?

[Raffaele Sena]

go get github.com/raff/walkngo 

If you use --lang=c it will actually generate c++ code.

It's not perfect but it does the bulk of the conversion. Unfortunately working 
with only the ast has it's limits (and I wrote this before the ssa stuff was 
available)

-- Raffaele

> On Mar 24, 2017, at 6:22 PM, Brad  wrote:
> 
> Interested in any feedback about the idea of making a Go -> C++ transpiler.  
> Here's the rationale:
> 
> * Go as a language has lots of awesome things that make it highly productive. 
>  Lots of Gophers would love to use Go for more projects but some common 
> issues include:
> * Trying to convince your team or management to adopt Go over a "more 
> traditional" language can be a tough sell: Your PHB is likely to tell you 
> it's not worth the risk, because the next developer he hires may not like Go 
> and he'll be screwed, whereas he knows he can find someone who will write C++ 
> or Java.
> * And there is also the issue of the environments in which Go will run.  On 
> embedded platforms (e.g. Parallax Propeller, Arduino) you can write C++, but 
> you're not going to get a Go compiler for it.
> * There's also the fact in a scenario where Go co-exists with C or C++, Go 
> has to have the main function and has to build the executable. Unless you 
> build a shared library, you can't just start implementing parts of your 
> project in Go and gradually phase things over.
> 
> It's also worth noting that some of these scenarios just will never support 
> all the features of the Go language, and so full support will not happen.  
> You probably won't get goroutines on an Arduino, for example. But, that 
> doesn't mean it wouldn't be useful to be able to write Go code in these cases 
> that doesn't use that feature and is otherwise 100% correct Go.
> 
> So, what if the following existed:
> 
> * Tool that converts Go to C++:
> * Comments and formatting are preserved - the resulting C++ is readable.  You 
> can tell your boss "there's no loss here - if this doesn't work, we'll throw 
> away the Go code and keep working on the C++", even though you know you will 
> burn in hell for doing that ;)
> * Language constructs which have an obvious simple mapping are just directly 
> converted (byte -> uint8_t, structs are structs, etc.)
> * Things that can be done with C++ code but are just ugly (e.g. defer, 
> implemented with goto) would be done like that - the transpiler would just 
> emit that code.
> * Features that are syntactic sugar around runtime implementations are emits 
> as calls to a stripped down version of the runtime that just does the bare 
> minimum to support what's needed: e.g. maps and slices are implemented with a 
> C++ template - the template is the same one that is just dropped in the 
> output as "map.h" and the transpiler emits code that uses it.
> * Heap allocations are mapped to a GC lib implemented in C++ - same as maps 
> above, just more complicated.  Same with channels.
> * Reflection could be done by emitting a bunch of type info and making all 
> that work, but probably wouldn't get around to doing this in a first version.
> * "go" gets mapped to pthread_create(), cognew() or whatever.
> * As much as possible this things are kept as some sort of simple template of 
> the corresponding C++ code to output, so you can easily adjust how 
> allocations or "go" or whatever are emitted for a particular environment.
> * The standard library would probably need to be forked, the things that are 
> heavily intertwined with the Go runtime ("runtime", "reflection", etc.) would 
> probably just not be available initially, and the ones that can be patched 
> and transpiled would be, and then some would probably just need a separate 
> implementation in C++ (e.g. "sync").  There would be an obvious way to do 
> this and it would be a normal thing in this scenario to say: "let's drop in 
> an implementation of fmt that supports only the barebones formatting for use 
> on embedded systems", etc.
> * Features/packages that are not supported would result in a transpiler 
> error.  I.e. some things "you just can't do" with this tool and that's okay.
> 
> Assuming this actually worked, it might considerably lower the bar for 
> adopting Go, and allow it to be used to develop in environments where we're 
> not likely to see a port of the compiler any time soon.  (Or where it's 
> literally impossible because there are things in the language that the 
> platform just can't do.)
> 
> I could potentially devote some time to building this out, but I wanted to 
> see if anyone had feedback on the concept.  I realize it's not a simple 
> project, but with the above setup it could be implemented incrementally.
> -- 
> 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 

[go-nuts] [ANN] Go client for Chrome devtools

[Raffaele Sena]

Now that headless support for Chrome is becoming available I decided I am 
fed-up trying to deal with phantomjs and related problems. And because I 
love Go and didn't see an available client, I decided to build my own: 
https://github.com/raff/godet

Still in the early stages (a week old ?), but it's usable. It doesn't 
really check for protocol.json but just assumes you are running a 
relatively new version of Chrome (again, I am planning to use for headless 
support, so it's going to be Chrome 57+).

In theory it should work everywhere but I am testing (for now) mainly on 
MacOS (where headless doesn't work, but I can test the protocol).

The example/command line should give you a good idea of how to use it (and 
it may be useful on its own).

Let me know what you think, and if you have any suggestions!

-- Raffaele

-- 
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] create dmg

[Raffaele Sena]

This uses some python modules, that should be ok if you are building your
installer on a mac:
http://dmgbuild.readthedocs.io/en/latest/



On Sat, Jul 30, 2016 at 4:00 PM, Joe Blue  wrote:

> recommended way for a gopher to make a dmg, so my users can install my
> golang app ?
>
> i searched for a pure golang solution, but go nada.
>
> thanks joe
>
> --
> 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.
>

-- 
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.