[go-nuts] Re: Experience Report building OCR in Go

[Egon]

Not sure why you had to build a GUI separately, there are already a few 
libs, although some of them are still barebones...

https://github.com/lxn/walk
https://github.com/andlabs/ui

Of course there are also bindings for gtk and qt.

On Monday, 15 January 2018 22:32:33 UTC+2, Tad Vizbaras wrote:
>
> Experience Report building OCR in Go:
>
> http://recoink.com/goreport
>
>
>

-- 
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: Experience Report building OCR in Go

[Egon]

As for getting andlabs/ui compiling the easiest I've found is to use 
msys2...


i.e. installation from scratch:

1. http://www.msys2.org/
2. open msys shell
3. pacman -Syu
3.1 close from X
4. pacman -Su
5. pacman -S mingw-w64-x86_64-go
6. pacman -S --needed base-devel mingw-w64-i686-toolchain 
mingw-w64-x86_64-toolchain

But, yeah... it could be much, much easier.

On Tuesday, 16 January 2018 10:41:23 UTC+2, Egon wrote:
>
> Not sure why you had to build a GUI separately, there are already a few 
> libs, although some of them are still barebones...
>
> https://github.com/lxn/walk
> https://github.com/andlabs/ui
>
> Of course there are also bindings for gtk and qt.
>
> On Monday, 15 January 2018 22:32:33 UTC+2, Tad Vizbaras wrote:
>>
>> Experience Report building OCR in Go:
>>
>> http://recoink.com/goreport
>>
>>
>>

-- 
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: Experience Report building OCR in Go

[Egon]

On Tuesday, 16 January 2018 14:27:44 UTC+2, Tad Vizbaras wrote:
>
> OCR project started 2 years ago. Then there was no usable exp/shiny. 
>

That makes sense. Although walk, libui, qml are all older than 2 years.
 

> I still think that GUI frameworks for Go are in baby stages even today. 
>

Totally agree.
 

> Why would I resort to some C libraries when "syscall" works with Windows 
> API well?
>

Few reasons, the C libs might provide more widgets and UI editor (i.e. qt + 
qml)...
or in case of libui, it would provide cross-platform support.

But, yeah, when targeting only Windows and controls are sufficient, then, 
yes, there's no point in introducing the complexity.


> On Tuesday, January 16, 2018 at 3:45:22 AM UTC-5, Egon wrote:
>>
>> As for getting andlabs/ui compiling the easiest I've found is to use 
>> msys2...
>>
>>
>> i.e. installation from scratch:
>>
>> 1. http://www.msys2.org/
>> 2. open msys shell
>> 3. pacman -Syu
>> 3.1 close from X
>> 4. pacman -Su
>> 5. pacman -S mingw-w64-x86_64-go
>> 6. pacman -S --needed base-devel mingw-w64-i686-toolchain 
>> mingw-w64-x86_64-toolchain
>>
>> But, yeah... it could be much, much easier.
>>
>> On Tuesday, 16 January 2018 10:41:23 UTC+2, Egon wrote:
>>>
>>> Not sure why you had to build a GUI separately, there are already a few 
>>> libs, although some of them are still barebones...
>>>
>>> https://github.com/lxn/walk
>>> https://github.com/andlabs/ui
>>>
>>> Of course there are also bindings for gtk and qt.
>>>
>>> On Monday, 15 January 2018 22:32:33 UTC+2, Tad Vizbaras wrote:
>>>>
>>>> Experience Report building OCR in Go:
>>>>
>>>> http://recoink.com/goreport
>>>>
>>>>
>>>>

-- 
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 compiler warning idea

[Egon]

Use govet and see https://golang.org/cmd/vet/#hdr-Shadowed_variables... Of 
course, there are more tools that can help 
you https://github.com/alecthomas/gometalinter

+ Egon

On Wednesday, 31 January 2018 02:05:57 UTC+2, Jacob Lancaster wrote:
>
> So, I'm new to Go, but I wanted to make a cli app that plays go fish with 
> another client over a network. While I was testing the main loop that takes 
> in the commands, I noticed that the program wouldn't exit when I entered 
> the exit command. Here is my code before I found the issue.
>
> var text string //Instantiating the variable that would hold the command 
> in a scope where the loop can check it
> for text != "exit\n" {
> fmt.Println("Enter command")
> text, err := reader.ReadString('\n') //This is where I realized the 
> error was. I create another text variable that is in the scope of the loop.
> }
>
> I know this was a beginner mistake, and looking back at it, I feel stupid, 
> but it got me thinking. Go gives a compiler error if you declare a variable 
> and don't use it. In this instance I did use the outer scope variable text, 
> but I never gave it a value in my code. Now, I don't know if there are 
> warnings already in place that will tell you this. If there aren't, 
> however, I think there should be at least a compiler warning. I was told to 
> post something here before I open an issue. So really this is just me 
> asking if a compiler warning for this would be a good idea, or is this just 
> a beginner mistake that no one runs into if they know what they're doing. 
>
>
>
>

-- 
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: “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[Egon]

I recommend re-writing them using real-world examples, where they really 
are the "best solution", rather than a facilitated example.

Often beginners learn from such facilitated examples and end-up misusing 
and getting the wrong idea about them. Using realistic examples helps to 
avoid those problems (to some degree).

On Friday, 2 February 2018 19:03:54 UTC+2, matthe...@gmail.com wrote:
>
> I’m looking at patterns summarized on Wikipedia from “Design Patterns: 
> Elements of Reusable Object-Oriented Software” and writing out a few as the 
> equivalent in Go.
>
> Visitor: https://play.golang.org/p/A5tNzxMmetH
>
> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>
> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>
> Facade: https://play.golang.org/p/forPdwy9VCi
>
> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>
> I’m curious how more experienced people rank these and the other patterns.
>
> Matt
>

-- 
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] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[Egon]

In practice it's seen together with two problems:

1. Emulating multiple dispatch with overloading: technically, it doesn't 
really solve the same problem as GoF described, but it looks a lot like it.

Example: https://en.wikipedia.org/wiki/Visitor_pattern#C++_example

2. Navigate a complex structure with callbacks:

Examples:
1. https://en.wikipedia.org/wiki/Visitor_pattern#Dynamic_Visitor
2. https://golang.org/pkg/go/ast/#Walk
3. https://golang.org/pkg/path/filepath/#Walk

When you put these two solutions together, you get the original "Visitor 
Pattern".

--

When the language doesn't support overloading, the implementation is 
usually done such that it doesn't require it. Instead of overloaded 
starting point in the structure, you'll have an specific one.

As a contrived example, you could convert the filepath.Walk into the 
original(ish) "Visitor Pattern" by having multiple callbacks instead of one 
or an interface:

type Handler interface {
HandleError(err error)
HandleFile(path string, info os.FileInfo) error
HandleDir(path string, info os.FileInfo) error
}

*In this case, it would be a worse solution and I wouldn't recommend it. *

--

I would like to rant about the badness of GoF Design Patterns... as Coplien 
said, there are no patterns in GoF book [1] 
. The problem with GoF can easily 
demonstrated by how hard it is to find good real-world examples of the 
patterns and that cannot be eliminated with different language. The best 
Patterns (as described by Alexander) are timeless and guide to a better 
solution and help you solve a problem that technology cannot fix.

[1] Are there any Patterns in GoF? (https://stackoverflow.com/a/24664544)

On Thursday, 8 February 2018 07:17:55 UTC+2, Rob 'Commander' Pike wrote:

> Isn't the visitor pattern just a way to implement type switch in languages 
> that don't implement type switch?
>
That's certainly how I saw it when using C++. Go has a type switch, and so 
> has no need for the visitor pattern, a perfect example of the principle 
> that a design pattern is just a way to work around shortcomings in the 
> language.
>
> -rob
>
>
> On Thu, Feb 8, 2018 at 2:14 PM, Josh Humphries  > wrote:
>
>> FWIW, it looks like someone else has gone through this exercise:
>> https://github.com/tmrts/go-patterns
>>
>> 
>> *Josh Humphries*
>> jh...@bluegosling.com 
>>
>> On Fri, Feb 2, 2018 at 12:03 PM, > 
>> wrote:
>>
>>> I’m looking at patterns summarized on Wikipedia from “Design Patterns: 
>>> Elements of Reusable Object-Oriented Software” and writing out a few as the 
>>> equivalent in Go.
>>>
>>> Visitor: https://play.golang.org/p/A5tNzxMmetH
>>>
>>> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>>>
>>> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>>>
>>> Facade: https://play.golang.org/p/forPdwy9VCi
>>>
>>> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>>>
>>> I’m curious how more experienced people rank these and the other 
>>> patterns.
>>>
>>> Matt
>>>
>>> -- 
>>> 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...@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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: All Forms of Wishful Generics

[Egon]

On Monday, 19 February 2018 12:06:09 UTC+2, RickyS wrote:
>
> Back when I first learned about the diamond problem with multiple 
> inheritance, I've known we need someone to invent the next and better thing 
> after inheritance. I do hope somebody smarter than me is somewhere trying. 
> Or even has succeeded.
>

There are many problems that are difficult in abstract, but easier in 
practice. As such I think that best solution to the diamond problem is not 
to use inheritance. The question becomes: what to do instead and which 
problems does the "alternative solutions" have. There are of course many 
known alternative solutions already: traits, Entity-Component-System, BOT 
architecture or DCI.

The problem is not "inheritance diamond", it's usually something else... 
for example, how to clearly and succinctly model complex entities in a 
game. When we just try to figure out the most flexible approach we may miss 
the mark by providing sufficient flexibility, but not the clarity in the 
problems.


> And back when I first learned about the code bloat that could result from 
> C++ generics/templates, I've known we need somebody invent the next and 
> better thing after "Generators". Generators, by the way, first appeared in 
> the 1950's, when they were considered a failure.
>
> It's been decades, and I'm still waiting. I would like to believe the Go 
> Authors are waiting for better solutions. Or even inventing them.
>

Swift for example has a solution that avoids code-bloat to some degree 
(https://www.youtube.com/watch?v=ctS8FzqcRug). Of course, this comes at the 
cost of performance.

In that sense, there is progress, although it is slow.


> N.B. All praise to the Go Authors for upgrading past the massive 
> inefficiency of #include files. Also for many other things.
>
> Well built software is easily modified. Easily-modified software is 
> modified and modified until it is incomprehensible and no longer easily 
> modified. Progress gets slower and slower and slower. Until it stops 
> entirely. Having the maturity and character to refrain from second-best 
> modifications is rare and wonderful. The ideas behind generics and 
> inheritance are basically: "Do this thing just like that other thing, 
> except differently here and here". Re-use code and concepts. I can feel the 
> passion for this goal. I have felt the sand in my gears as I drive the new 
> machine with 256 levers and switches.
>
>
> *On Friday, February 16, 2018 at 8:25:35 AM UTC+2, dc0d wrote:*
>>
>> *All forms of generics that I would love to have in Go: ...*
>>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go Programming Language Course

[Egon]

The main value is not adding complexity in your learning setup.
As value points you can show examples how to cross-compile from Windows to 
Linux.

Of course, as Jonathan mentioned compiling with C is bit annoying.

If you just need to use CGO, then TDM-GCC does a decent job.

If you need to link to existing libraries then you need MSYS2.
Which, has a bit more complicated setup.

On Wednesday, 21 February 2018 16:25:38 UTC+2, Dick Seabrook wrote:

> I'm putting together a 3-credit introduction to the Go programming 
> language at 
> the community college level. I will create (as a minimum) syllabus, 
> outline, 
> lecture notes, handouts, assignments, projects, quizzes and final exam. I 
> will
> probably start with the Donovan & Kernighan A-W 2015 text.
> Prerequisite: familiarity with personal computers and at least one 
> programming
> language, preferably C.
> I'd like to set it up in a shared Linux environment although I'll be 
> teaching
> exclusively in Windows 10 labs. Fortunately we've got a large Linux VM on 
> campus
> so the Linux base is do-able, however is there any value in teaching Go on
> Windows 10 natively?
>
> Any thoughts or suggestions?
> Thanks,
> Dick S.
>
>

-- 
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: Experience report on coming to Go from a C perspective

[Egon]

Few additional possible solutions:

1. use something similar to https://github.com/awalterschulze/goderive 
create appropriate func.
2. some IDE / tool should be able to figure these refactorings out... or at 
least find the places that need to be changed. Changing a field or method 
name is quite similar to this problem so I cannot see why an editor 
wouldn't be able to do it.

*As for the proposed solution "make(Set.members)", I like it :)*

On Thursday, 22 February 2018 23:58:25 UTC+2, Devon H. O'Dell wrote:
>
> Thanks for pointing this out; I wasn't aware of this new syntax. I 
> think this gets to about halfway of what I'd hope for. That said, I'd 
> really like to avoid needing to jump through the hoop of indirection 
> for this. I occasionally find it hard to recognize what the type of a 
> thing is due to heavy use of type inference, so I'd hope for something 
> that doesn't require me to do additional backtracking to figure out 
> what the real underlying type is. 
>
> 2018-02-22 12:31 GMT-08:00  >: 
> > Have you considered using the new type alias feature introduced in 1.9? 
> Line 
> > so: 
> > 
> > https://play.golang.org/p/6HK8qcuh9UU 
> > 
> > This would allow you to change the type of the map in a singe place (the 
> > type alias) and all the {} or make would adapt appropriately. 
> > Disclaimer: I am not espousing this style, just pointing out that it is 
> > possible. 
> > 
> > 
> > 
> > On Thursday, February 22, 2018 at 3:03:13 PM UTC-5, Devon H. O'Dell 
> wrote: 
> >> 
> >> Hi all, 
> >> 
> >> It's been some time since I really contributed much of anything to the 
> >> project (sorry!), but after 8 years, I'm finally writing Go outside of 
> >> the project itself (and outside of porting efforts). I was lamenting 
> >> to some coworkers about the lack of a comparable feature to C's 
> >> "malloc idiom" and they suggested I write an experience report on it. 
> >> I wrote the bulk of the article a month ago, but finally put in some 
> >> finishing touches and published. 
> >> 
> >> For whatever it's worth (probably not much): 
> >> https://9vx.org/post/a-malloc-idiom-in-go/ 
> >> 
> >> --dho 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Mac OS Bluetooth Gamepad

[Egon]

Usually controllers don't speak directly to your application nor browser.

Usually there is a driver that the controller has, this talks with the 
appropriate protocol to the device. The driver itself provides some common 
HID api that the OS has specified.

The reading and writing the input is effectively about communicating with 
the OS.

https://github.com/glfw/glfw/blob/master/src/linux_joystick.c
https://github.com/glfw/glfw/blob/master/src/win32_joystick.c

You can do those calls using syscall package, e.g. one for Windows

https://github.com/egonelbre/exp/blob/master/game/gamepad/xinput_windows.go

and a quick search on godoc.org revealed this:
https://godoc.org/?q=joystick
https://github.com/simulatedsimian/joystick

Of course since it's OS specific, you need to implement for all of them. 
Where each might their own quirks.

SDL and GLFW are both thoroughly tested. I'm not sure about the existing 
package, but it shouldn't be difficult to switch when you do encounter 
problems with the pure Go libs.

+ Egon

On Tuesday, 27 March 2018 05:19:24 UTC+3, Zellyn wrote:
>
> Inspired by a Wired article 
> <https://www.wired.com/story/xbox-one-x-and-xbox-one-deals/> mentioning 
> XBox One gamepads for $34, I finally got a game controller.
>
> Naturally, now I'm wondering how to read it from Go :-)
>
> It connects to Mac OS over Bluetooth. Various games seem to vary in 
> whether they recognize or even notice it, but it works flawlessly in Chrome 
> using http://html5gamepad.com/ 
> <http://www.google.com/url?q=http%3A%2F%2Fhtml5gamepad.com%2F&sa=D&sntz=1&usg=AFQjCNHgk2HZ9Nwso2KFkEVEFST54APnmQ>
>
> So, if there's anyone here who even begins to know how gamepads work… am I 
> about to wade into an ocean of pain? I'd *like* to avoid linking to sdl 
> as gobot seems to do for joysticks: it would be lovely to have something in 
> pure Go. Is that unlikely?
>
> How are games (and Chrome) even finding the controller? Do they have to 
> interrogate the Bluetooth stack, and then speak both Bluetooth and the XBox 
> controller protocol?
>
> Any help appreciated.
>
> Zellyn
>
>

-- 
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: Mac OS Bluetooth Gamepad

[Egon]

Ah, just noticed the Mac part...

https://github.com/glfw/glfw/blob/master/src/cocoa_joystick.m

Also Chromium source for the Gamepad implementation:

https://cs.chromium.org/chromium/src/device/gamepad/?q=gamepad&sq=package:chromium&dr

Unfortunately I didn't notice a Go gamepad implementation for Mac... 
however there might be one.

On Tuesday, 27 March 2018 15:02:10 UTC+3, Egon wrote:
>
> Usually controllers don't speak directly to your application nor browser.
>
> Usually there is a driver that the controller has, this talks with the 
> appropriate protocol to the device. The driver itself provides some common 
> HID api that the OS has specified.
>
> The reading and writing the input is effectively about communicating with 
> the OS.
>
> https://github.com/glfw/glfw/blob/master/src/linux_joystick.c
> https://github.com/glfw/glfw/blob/master/src/win32_joystick.c
>
> You can do those calls using syscall package, e.g. one for Windows
>
> https://github.com/egonelbre/exp/blob/master/game/gamepad/xinput_windows.go
>
> and a quick search on godoc.org revealed this:
> https://godoc.org/?q=joystick
> https://github.com/simulatedsimian/joystick
>
> Of course since it's OS specific, you need to implement for all of them. 
> Where each might their own quirks.
>
> SDL and GLFW are both thoroughly tested. I'm not sure about the existing 
> package, but it shouldn't be difficult to switch when you do encounter 
> problems with the pure Go libs.
>
> + Egon
>
> On Tuesday, 27 March 2018 05:19:24 UTC+3, Zellyn wrote:
>>
>> Inspired by a Wired article 
>> <https://www.wired.com/story/xbox-one-x-and-xbox-one-deals/> mentioning 
>> XBox One gamepads for $34, I finally got a game controller.
>>
>> Naturally, now I'm wondering how to read it from Go :-)
>>
>> It connects to Mac OS over Bluetooth. Various games seem to vary in 
>> whether they recognize or even notice it, but it works flawlessly in Chrome 
>> using http://html5gamepad.com/ 
>> <http://www.google.com/url?q=http%3A%2F%2Fhtml5gamepad.com%2F&sa=D&sntz=1&usg=AFQjCNHgk2HZ9Nwso2KFkEVEFST54APnmQ>
>>
>> So, if there's anyone here who even begins to know how gamepads work… am 
>> I about to wade into an ocean of pain? I'd *like* to avoid linking to 
>> sdl as gobot seems to do for joysticks: it would be lovely to have 
>> something in pure Go. Is that unlikely?
>>
>> How are games (and Chrome) even finding the controller? Do they have to 
>> interrogate the Bluetooth stack, and then speak both Bluetooth and the XBox 
>> controller protocol?
>>
>> Any help appreciated.
>>
>> Zellyn
>>
>>

-- 
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: Mac OS Bluetooth Gamepad

[Egon]

https://developer.apple.com/library/content/documentation/ServicesDiscovery/Conceptual/GameControllerPG/Introduction/Introduction.html

https://developer.apple.com/documentation/gamecontroller

I have no idea why they don't include some Gamepad thing in the settings 
panel.

On Tuesday, 27 March 2018 16:07:16 UTC+3, Zellyn wrote:
>
> Thanks for the pointers. I spent some time last night finding the gamepad 
> code in the Chromium sources, although I haven't had a chance to really 
> read it properly.
>
> It makes sense that you'd read against some kind of OS-specific 
> abstraction, but I was curious what it was because I don't see any gamepad 
> config or listing in the Mac OS Settings panels.
>
> Sounds like I'm going to be reading some source code… :-)
>
> Thanks again,
>
> Zellyn
>
>
> On Tuesday, March 27, 2018 at 8:31:23 AM UTC-4, Egon wrote:
>>
>> Ah, just noticed the Mac part...
>>
>> https://github.com/glfw/glfw/blob/master/src/cocoa_joystick.m
>>
>> Also Chromium source for the Gamepad implementation:
>>
>>
>> https://cs.chromium.org/chromium/src/device/gamepad/?q=gamepad&sq=package:chromium&dr
>>
>> Unfortunately I didn't notice a Go gamepad implementation for Mac... 
>> however there might be one.
>>
>> On Tuesday, 27 March 2018 15:02:10 UTC+3, Egon wrote:
>>>
>>> Usually controllers don't speak directly to your application nor browser.
>>>
>>> Usually there is a driver that the controller has, this talks with the 
>>> appropriate protocol to the device. The driver itself provides some common 
>>> HID api that the OS has specified.
>>>
>>> The reading and writing the input is effectively about communicating 
>>> with the OS.
>>>
>>> https://github.com/glfw/glfw/blob/master/src/linux_joystick.c
>>> https://github.com/glfw/glfw/blob/master/src/win32_joystick.c
>>>
>>> You can do those calls using syscall package, e.g. one for Windows
>>>
>>>
>>> https://github.com/egonelbre/exp/blob/master/game/gamepad/xinput_windows.go
>>>
>>> and a quick search on godoc.org revealed this:
>>> https://godoc.org/?q=joystick
>>> https://github.com/simulatedsimian/joystick
>>>
>>> Of course since it's OS specific, you need to implement for all of them. 
>>> Where each might their own quirks.
>>>
>>> SDL and GLFW are both thoroughly tested. I'm not sure about the existing 
>>> package, but it shouldn't be difficult to switch when you do encounter 
>>> problems with the pure Go libs.
>>>
>>> + Egon
>>>
>>> On Tuesday, 27 March 2018 05:19:24 UTC+3, Zellyn wrote:
>>>>
>>>> Inspired by a Wired article 
>>>> <https://www.wired.com/story/xbox-one-x-and-xbox-one-deals/> 
>>>> mentioning XBox One gamepads for $34, I finally got a game controller.
>>>>
>>>> Naturally, now I'm wondering how to read it from Go :-)
>>>>
>>>> It connects to Mac OS over Bluetooth. Various games seem to vary in 
>>>> whether they recognize or even notice it, but it works flawlessly in 
>>>> Chrome 
>>>> using http://html5gamepad.com/ 
>>>> <http://www.google.com/url?q=http%3A%2F%2Fhtml5gamepad.com%2F&sa=D&sntz=1&usg=AFQjCNHgk2HZ9Nwso2KFkEVEFST54APnmQ>
>>>>
>>>> So, if there's anyone here who even begins to know how gamepads work… 
>>>> am I about to wade into an ocean of pain? I'd *like* to avoid linking 
>>>> to sdl as gobot seems to do for joysticks: it would be lovely to have 
>>>> something in pure Go. Is that unlikely?
>>>>
>>>> How are games (and Chrome) even finding the controller? Do they have to 
>>>> interrogate the Bluetooth stack, and then speak both Bluetooth and the 
>>>> XBox 
>>>> controller protocol?
>>>>
>>>> Any help appreciated.
>>>>
>>>> Zellyn
>>>>
>>>>

-- 
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: Windows cgo complier

[Egon]

1. tdm-gcc (http://tdm-gcc.tdragon.net/) is the easiest to setup.
2. mingw64 gets you a newer gcc, but needs more work to setup.
3. msys2 supports better linking to more libraries, but it also requires 
you to work in a separate shell outside from Windows, and installation is 
separate from just installing Go.

If it works with tdm-gcc, then it will work in mingw64 and msys2. But not 
necessarily the other way around.

+ Egon

On Wednesday, 28 March 2018 16:17:32 UTC+3, Luke Mauldin wrote:
>
> Can someone please tell me what the golang team uses as the reference 
> windows x64 compiler? I have heard references to mingw64 but it would be 
> helpful to know the exact version they are using for their unit tests on 
> Windows. I am experiencing different cgo windows behavior in 1.10 than 
> 1.9.3 and I want to verify I am using the validated windows tool chain.
>
> Luke
>

-- 
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: parallel array processing question

[Egon]

When you have such questions, then run your code with the race 
detector. https://golang.org/doc/articles/race_detector.html

Otherwise, you are only reading from the slice, there is no racing possible.

Also, your max function looks very weird and has a small bug:
https://play.golang.org/p/8K-0ze3RdDt

The slice calculations has bugs as well, e.g. try running with 64 
goroutines.

+ Egon

On Thursday, 19 April 2018 14:35:20 UTC+3, l vic wrote:
>
> I have a program that calculates max value in integer array by breaking 
> the array into number of slices and calculating max in every slice inside 
> of go-routine.
> Do I still need to lock/unlock each slice with mutex inside of go-routine? 
> The code seems to be working but are any apparent problems with it?
>
> package main
>
>
> import (
>
> "fmt"
>
> "os"
>
> "strconv"
>
> "sync"
>
> )
>
>
> //returns maximum number found in provided slice
>
> func maxInSlice(numbers []uint) (uint, error) {
>
> if numbers == nil {
>
> return 0, fmt.Errorf("nil  numbers")
>
> }
>
>
> var max uint = 0
>
> for _, n := range numbers {
>
> for _, m := range numbers {
>
> if n > m {
>
> max = n
>
> }
>
> }
>
> }
>
>
> return max, nil
>
> }
>
>
> // finds  maximum  number  in  numbers  array  by   breaking  work  into  N  
> pieces
>
> // (where  N  is provided  as a command  line  argument)  and processing  the
>
> // pieces  in  parallel  goroutines func  main()
>
> func main() {
>
> parallelism, _ := strconv.Atoi(os.Args[1])
>
> fmt.Printf("ok,  i'll  use %d  goroutines\n", parallelism)
>
>
> numbers := []uint{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}
>
> wg := sync.WaitGroup{}
>
> mutex := sync.Mutex{}
>
> var allMax uint = 0
>
> perGoRoutine := len(numbers) / parallelism
>
> fmt.Printf("perGoRoutine=%d\n", perGoRoutine)
>
>
> for i := 0; i < parallelism; i++ {
>
> wg.Add(1)
>
> go func(i int) {
>
> defer wg.Done()
>
> fmt.Printf("==>index i = %d perGoRoutine in go func=%d\n", i, 
> perGoRoutine)
>
> startIndex := perGoRoutine * i
>
> endIndex := startIndex + perGoRoutine - 1
>
> //include last element
>
> if i == parallelism-1 {
>
> endIndex = len(numbers) - 1
>
>
> }
>
>
> fmt.Printf("startIndex=%d endIndex=%d\n", startIndex, endIndex)
>
> sliceMax, err := maxInSlice(numbers[startIndex:endIndex])
>
> mutex.Lock()
>
> if err != nil {
>
> fmt.Printf("error  finding  max  for  slice  %d  to  %d, 
> skipping  this  slice:  %s\n", err)
>
> return
>
> }
>
>
> fmt.Printf("goroutine  %d  (slice  %d  to  %d)  found  max  
> %d\n", i, startIndex, endIndex, sliceMax)
>
> if sliceMax > allMax {
>
> allMax = sliceMax
>
> }
>
> mutex.Unlock()
>
>
> }(i)
>
>
> }
>
> wg.Wait()
>
>
> fmt.Printf("maximum:  %d\n", allMax)
>
>
> }
>
>
>
>
>

-- 
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: Checking IP against CIDR ranges

[Egon]

See https://github.com/Kentik/patricia/

On Wednesday, 16 May 2018 03:38:26 UTC+3, XXX ZZZ wrote:
>
> Hello,
>
> I'm trying to check an IP against a list of several CIDR ranges, so far 
> the most obvious way to do it seems to parse both the IP and the cidr 
> ranges (ParseCIDR) and then do a net.contain() however, if we have more 
> than 1 CIDR we have to loop checking one by one which imho is incredible 
> unefficient + slow if the cidr range is big.
>
> Is there any more efficient way of achieving this? I have thought on 
> making a map[string]string with all the IPs (within the CIDR) but the 
> amount of required memory for big lists goes up to a few GB.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

[Egon]

On Tuesday, 11 September 2018 18:28:29 UTC+3, Robert Engels wrote:
>
>
> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com > wrote:
>
> [golang-nuts to CC, golang-dev to BCC]
>
> On Mon, Sep 10, 2018 at 5:33 PM robert engels  > wrote:
>
>> In the entire codebase of Docker I could find only one obvious use of 
>> interface{}, and no type casts.
>>
>
> Generics are not only useful for functions taking interface{}. They are 
> also useful for functions taking non-empty interfaces, for cases where you 
> could re-use an existing generic implementation and forego re-implementing 
> it for your concrete type and for reducing boilerplate across many types 
> (e.g. the famous sort.Interface).
>
>
> True, and reviewing cockroachdb shows the sort.Interface used a lot, and a 
> generic container could avoid that, but in most cases this could be solved 
> by only having to implement Less and having ’sort’ work on slices - as the 
> vast majority are slices to begin with.
>
> I am just attempting to point out that the original Go designers offered 
> ’typed’ collections (slice, map) as part of the language. They fall short 
> in some ways but it may be possible for a simpler solution to expand their 
> abilities, or add others, without resorting to generics. I like the 
> simplicity and readability “no surprises for the most part” of Go, and I 
> think it should try to stay that way.
>
>
> In my opinion, Go isn’t suitable for large enterprise systems with 
>> million+ lines of code
>>
>
> No offense, but empirically, the existence of such systems written in Go 
> seems to contradict you here. Kubernetes has 3.5M lines of code in just the 
> single main repository. And that's just open source software - most of the 
> actual million+ lines of code systems written in Go you won't know about, 
> because they are not open (I work on one of those).
>
>
> This seems to contradict this a bit, 
> https://stackoverflow.com/questions/41586501/why-is-kubernetes-source-code-an-order-of-magnitude-larger-than-other-container
>  but 
> it may be an indictment that Go’s lack of classes/inheritance/generics 
> leads to code bloat. I believe that you work on a large Go system, I am 
> just not positive it is pleasurable to maintain/refactor - maybe for high 
> knowledge original authors - but as I said I am going to leave that 
> criticism to another post, as it is not particular germane to the generics 
> discussion.
>
>
> The Java generic code is a pleasure to use, and maintain
>>
>
> I believe this is up to individual perception. Personally, I found working 
> on a large-scale Java codebase to be an unpleasant experience, because of 
> the generic code.
>
>
> I would be curious as to what the stumbling block was.  I’ve seen 
> Tuple used in public APIs in some code bases - where a typed 
> class that wraps it is for more appropriate - not good, and very poor 
> maintainability.
>
>
> But, people cry, boxing is SLOW, and we want Go to be FAST! This paper 
>> https://research.swtch.com/generic is citied multiple times as a charge 
>> against boxing.
>>
>
> Not quite. That article is cited to clarify that you need to *decide* on 
> what tradeoff you want to make and to justify it. Boxing - choosing "slow 
> programs" in the parlance of the article - is a reasonable choice to make, 
> but you should do so deliberately and make a good case for why it's the 
> right choice.
>
> It's also used as a reference to quickly explain one example of the 
> current design, which is that it makes that decision no longer a language 
> decision, but an implementation decision. i.e. we don't even know if 
> generics in Go will be boxed or not - we can decide that later and change 
> the decision at will.
>
>
> I disagree with your reading here. The statement from the article is "*do 
> you want slow programmers, slow compilers and bloated binaries, or slow 
> execution times?**”* 
>
> and as I pointed out, Go’s method dispatch is already slower than Java in 
> both the direct and interface cases. So citing Java and ‘slow execution 
> times’ as a problem with generics s incorrect by the author, and that 
> people keep citing it as fact is troublesome. People have proposed 
> interface based generics for Go, and the criticism is most of the time - 
> that will be slower...
>
>
I think you haven't seen what people need to do in Java to make it 
performant. As an example:

https://mechanical-sympathy.blogspot.com/2012/10/compact-off-heap-structurestuples-in.html

That example is more about value types, but also implicitly a problem with 
boxing.

The boxing overhead is most visible with having things like ArrayList.

Indeed there are places where Java can erase some of the performance 
overhead, even more so with GraalVM. (Not sure about the memory overhead)


> Now the reason for this is almost certainly that Java can inline across 
>> virtual function calls
>>
>
> I would say that the core advantage of Java is like

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

[Egon]

On Wednesday, 12 September 2018 15:47:14 UTC+3, Robert Engels wrote:
>
> I am well aware of mechanical sympathy and the techniques (like the 
> disrupter) used (I would counter that in many cases you are not writing 
> “Java” due to the object pooling ,etc.)
>
> What I’ve shown is that Java is already more performant than Go without 
> using those techniques for many application aspects - specifically in terms 
> of method dispatch, but still Go direct methods vs interface methods are 5x 
> faster, so you if you need ultra performance critical code you need to keep 
> that in mind, but RARELY is this the case (except for some people in HFT 
> but even they have moved on to FPGAs) and you are far better structuring 
> your code for maintainability and functionality rather than worrying about 
> slower method dispatch...
>

https://www.youtube.com/watch?v=rX0ItVEVjHc
 

>
> ArrayList is not “correct” Java - because you are going to encode 
> every byte as an object in an object[] behind the scenes, and each would 
> need to be managed as an Object. Java has arrays, you would simply use a 
> byte[]. If you need expandable arrays, you would probably use a ByteBuffer.
>

That is exactly the boxing overhead that the generics dilemma talks about. 
ByteBuffer is an example where the generics weren't good enough and people 
ended up manually implemented a specialized version.

Remember you shouldn't be comparing performance of Java generics vs Go 
status quo... you should be comparing Java generics vs C++ generics vs 
Swift generics vs D generics vs Zig generics. That way the trade-offs of 
different approaches becomes visible.
 

>
> Your point highlights an important consideration - most people don’t know 
> how to write REALLY performant software in a given language unless it is an 
> area of focus and experience, which is why I distribute the tests publicly 
> because I will grant that there may be techniques in Go that I am not 
> understanding or misusing - but at this point I think I have a pretty good 
> handle on the internal workings of Go.
>

I completely agree that most people can live with the current state.
 

>
> The biggest performance advantage for Go will be the garbage collector due 
> to the “value type” of array struct, since there is only a single reference 
> to be GC managed regardless of the number of elements. That is not possible 
> in Java - at least not now. That being said, there are Java VMs like Azul 
> Zing that are far more performant than Go in terms of GC pauses without any 
> restricting on the layout of the memory being managed. As soon as you start 
> using array of interface in Go, you are going to put pressure on the GC, as 
> the number of references that need to be managed expands proportional to 
> the size of the array - at least I think so - but there may be behind the 
> scenes escape analysis that determines if any references escape the array, 
> and if not it can still manage it is a single reference.
>
> But all of this is off-topic from the original post - which was to suggest 
> to keep it simple and use interfaces/closures at runtime to support 
> generics and not worrying about the performance overhead - the really 
> performance critical coders can always write non-generic/interface 
> containers if they absolutely think they need it, but most likely they 
> don’t...
>

I tend to agree, but having specializing generics makes some of that code 
easier to manage.
 

>  
>

> On Sep 11, 2018, at 11:57 PM, Egon > 
> wrote:
>
>
>
> On Tuesday, 11 September 2018 18:28:29 UTC+3, Robert Engels wrote:
>>
>>
>> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts > googlegroups.com> wrote:
>>
>> [golang-nuts to CC, golang-dev to BCC]
>>
>> On Mon, Sep 10, 2018 at 5:33 PM robert engels  
>> wrote:
>>
>>> In the entire codebase of Docker I could find only one obvious use of 
>>> interface{}, and no type casts.
>>>
>>
>> Generics are not only useful for functions taking interface{}. They are 
>> also useful for functions taking non-empty interfaces, for cases where you 
>> could re-use an existing generic implementation and forego re-implementing 
>> it for your concrete type and for reducing boilerplate across many types 
>> (e.g. the famous sort.Interface).
>>
>>
>> True, and reviewing cockroachdb shows the sort.Interface used a lot, and 
>> a generic container could avoid that, but in most cases this could be 
>> solved by only having to implement Less and having ’sort’ work on slices - 
>> as the vast majority are slices to begin with.
>>
>> I am just attempting to point out that the original Go de

[go-nuts] Re: Go2 Error Handling Feedback

[Egon]

Your example code is missing 4 error checks that should additionally be 
handled.

On Thursday, 1 November 2018 11:17:37 UTC+2, Henry wrote:
>
> Hi,
>
> I am concerned with the direction Go2 is going. If anything, Go2 should 
> reduce and consolidate features from Go1 rather than adding new ones. 
> Remember that C++ and Java too were once simple languages and people keep 
> adding stuffs instead of consolidating features. 
>
> About error handling, I prefer the Go1 error handling approach. It is 
> simple, readable, and scalable. Everything is laid out in plain sight and 
> there is no hidden alternate execution paths.
>
> The complaint people have about Go1 approach is the repetitive error 
> checks. I will use the following code example from another thread 
>  by DrGo.
>
> func CopyFile(src, dst string) error {
>  r, err := os.Open(src)
>  if err != nil {
>  return fmt.Errorf("copy %s %s: %v", src, dst, err)
>  }
>  defer r.Close()
>
>
>  w, err := os.Create(dst)
>  if err != nil {
>  return fmt.Errorf("copy %s %s: %v", src, dst, err)
>  }
>
>
>  if _, err := io.Copy(w, r); err != nil {
>  w.Close()
>  os.Remove(dst)
>  return fmt.Errorf("copy %s %s: %v", src, dst, err)
>  }
>
>
>  if err := w.Close(); err != nil {
>  os.Remove(dst)
>  return fmt.Errorf("copy %s %s: %v", src, dst, err)
>  }
>   return nil
> }
>
> Many people are thinking how to reduce the four error checks in the above 
> example, and they come up with various keywords and ways to reduce those 
> error checks. However, they are forgetting that CopyFile function itself is 
> an error-check reduction mechanism. The next person who needs to copy file, 
> only needs to use the function and handle one error check instead of four. 
> In addition, you get the benefits of reusability and readability. You gain 
> all those with simple modularization instead of adding keywords. The 
> approach is also more flexible and scalable.
>
> So, the next time you feel you are writing too many error checks, see if 
> you can refactor those into smaller functions. Even if you can't further 
> decompose your code, take heart knowing that you only need to write them 
> once. The next time you need a similar functionality, you just reuse the 
> function and avoid repeating those error checks. 
>

-- 
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: Weekend question: Idiomatic way of handling >millions of objects (structs ;))

[Egon]

Yeah, mmap is a valid solution.

Of course, you end up with code that works less reliably on all platforms.
And, depending on what kinds of operations you are doing you might not get 
a perf benefit.

On Friday, 15 February 2019 19:34:55 UTC+2, Jeroen Massar wrote:
>
> Hi folks, 
>
> Silly question time, to get to the most idiomatic golang based solution... 
>
> In C, when I have a large collection of structs with data (no pointers 
> outbound), I would just mmap a large file and chunk up the file into the 
> size of the struct, basically thus doing a bit of memory management myself. 
> Then with the offset * structsize, it effectively becomes a big list. 
> Save/load is a sync/close + mmap away, no need to figure out what is 
> loaded, cached, in memory etc or fight the system. 
> (I guess folks know the advantages/disadvantages of mmap here ;) ) 
>
> I've seen the examples where folks do effectively the same in golang: mmap 
> into a SliceHeader and voila. 
>
> But, is there a more idiomatic way to doing this? 
>
> Especially, when one wants to save and later load all these objects to 
> persistent storage, the mmap model is quite nice. 
> Looping through a slice/map and having to write stuff that might have 
> changed (would have to track changes to objects, an option, but OS does it 
> otherwise for one). 
>
> Thus, go with mmap trick, or any better ideas? 
>
> Greets, 
>  Jeroen 
>

-- 
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] Stop triggering firewall on Windows? Preset build path?

[Egon]

If you use `127.0.0.1:0` as your listening address then the firewall won't 
trigger as well.

On Saturday, 7 November 2020 at 15:20:06 UTC+2 Aleistar Markóczy wrote:

> I may not be "using go run as a development tool" (which I would deem a 
> perfectly fine reason to use "go run", I mean what else would you use it 
> for, maybe to run on production? ;-) ) but the same happens when running go 
> test to run tests while creating a server to run the tests on.
>
> The trick of opening the port works perfectly file, thanks! Just open the 
> windows Firewall Settings > Advanced Settings > Inbound Rules > New Rule > 
> By Port.
>
> On Wednesday, 11 February 2015 at 15:38:53 UTC+1 ni...@craig-wood.com 
> wrote:
>
>> On 11/02/15 10:13, Mateusz Czapliński wrote: 
>> > Or, I believe "go build && myappname.exe" (as mentioned by Egon too) is 
>> > on par with go install, with the small difference between the two (i.e. 
>> > location of the resulting executable) left up to personal 
>> > choice/preference/needs. 
>>
>> If you have a big project you'll notice the difference in speed between 
>> go build and go install. It is especially noticeable if you have 
>> modified code in a package which you are not typing go build for - that 
>> has to be rebuilt every time. 
>>
>> In my 25,000 line project split over 50+ files it takes about 2 seconds 
>> for a cold build, but only 0.6s for a go install after that cold build. 
>> go install speeds up subsequent go builds. 
>>
>> .../src/github.com/ncw/myproject$ rm -rf 
>> ~/go/pkg/linux_amd64/github.com/ncw/myproject 
>> .../src/github.com/ncw/myproject$ time go build 
>>
>> real 0m1.972s 
>> user 0m1.796s 
>> sys 0m0.237s 
>>
>> .../src/github.com/ncw/myproject$ time go build 
>>
>> real 0m2.004s 
>> user 0m1.797s 
>> sys 0m0.255s 
>>
>> .../src/github.com/ncw/myproject$ time go install 
>>
>> real 0m1.955s 
>> user 0m1.809s 
>> sys 0m0.210s 
>>
>> .../src/github.com/ncw/myproject$ time go install 
>>
>> real 0m0.614s 
>> user 0m0.531s 
>> sys 0m0.085s 
>>
>> .../src/github.com/ncw/myproject$ time go build 
>>
>> real 0m0.960s 
>> user 0m0.864s 
>> sys 0m0.080s 
>>
>> -- 
>> Nick Craig-Wood  -- http://www.craig-wood.com/nick 
>>
>

-- 
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/fe36826a-1187-4f26-b030-f208497b8fe5n%40googlegroups.com.

[go-nuts] Re: map memory usage question

[Egon]

On Friday, 17 June 2016 02:59:49 UTC+3, kortschak wrote:
>
> I'm running a terabyte-scale (minor compiler changes are necessary to get 
> this to run) genome resequencing simulation at the moment and an 
> interesting question has arisen.
>
The simulation involved hashing over ~all positions of a genome, either 
> with the key being a string or a [2]string. 
>

Interesting :)

Note there might be better data-structures for this than the built-in map. 
Do you have the code uploaded with some example which uses under 8GB of 
memory? Or a description how the algorithm works?

The difference in the resident memory size for the entire program for these 
> two cases is about a factor of two.
>
> What is an estimate of the contribution of key size to the number of bytes 
> required per element for a map?
> -- 
> afk
> Dan
>

-- 
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: Is this deterministic ?

[Egon]

On Friday, 17 June 2016 18:50:59 UTC+3, Olivier Gagnon wrote:
>
> https://play.golang.org/p/yE7UVXcXm3
>
> The key point here is that all the RHS of the `Cross` function must be 
> evaluated before the LHS is assigned. But I need to have a guarantee that 
> we won't assign before having evaluated the LHS.
>

Yes, see https://golang.org/ref/spec#Assignments

-- 
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: [?] emulating an opengl shader in cpu bound functions

[Egon]

On Monday, 20 June 2016 18:02:53 UTC+3, blue...@gmail.com wrote:
>
>
> <https://lh3.googleusercontent.com/-bPOQJTHF8Js/V2gEJqUg5jI/ACI/lg6cWG0cJqo0tFl4wsuDYF2w4kycTbRPACLcB/s1600/blank.png>
>
> I am attempting to generate a random starfield, in go. This is something 
> that will need to printed on actual paper, but that is another issue and I 
> only mention it to give some context for what I am doing here: Using go to 
> create graphics to pair with something I'm already doing in go (I've been 
> through several iterations of trying to use the go parts I have with 
> numerous variations of tex/latex templates using asymptote, and I reached a 
> point of frustration where I figured why not just do it all in go, as it 
> seems less a problem than I originally thought -- but opens a new set of 
> problems to solve, one of the biggest is that I know nothing at all about 
> graphics, let alone how to apply graphics in go).
>

For understanding graphics, learn how to do these without any libs:

* remove a color channel
* brighten/darken/contrast image
* blur an image
* blend two images together (add, sub, mul, div etc. try combining 
different color channels differently)
* gradients (i.e. conversion from hsl to rgb)
* noise (with a few parameters)
* combine multiple layers of noise (tip, blur some of the layers)
* draw a line
* draw a circle
* draw a rotating wireframe cube
* draw a filled circle filled with noise
* draw a thick line filled with noise

Don't worry about the performance/quality of each of those, do the 
stupidest thing first, play around with them. Much of this kind of graphics 
programming is about learning how to do the simple primitives and combine 
them.

You can take a look at Inigo Quilez, an amazing artist/programmer 
https://www.youtube.com/watch?v=emjuqqyq_qc, see the process how he combine 
simple things to get to something amazing. Plus he has plenty of good 
articles http://www.iquilezles.org/www/index.htm.

For printing, just make the image large.

*additional tip: use https://github.com/loov/watchrun (or compile on save 
from editor) to monitor when you change your code and automatically 
regenerate the output image, that way you don't have to manually 
recompile/run/open the file every time*

+ Egon

-- 
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: [?] emulating an opengl shader in cpu bound functions

[Egon]

On Monday, 20 June 2016 18:02:53 UTC+3, blue...@gmail.com wrote:
>
>
> 
>
> I am attempting to generate a random starfield, in go. This is something 
> that will need to printed on actual paper, but that is another issue and I 
> only mention it to give some context for what I am doing here: Using go to 
> create graphics to pair with something I'm already doing in go (I've been 
> through several iterations of trying to use the go parts I have with 
> numerous variations of tex/latex templates using asymptote, and I reached a 
> point of frustration where I figured why not just do it all in go, as it 
> seems less a problem than I originally thought -- but opens a new set of 
> problems to solve, one of the biggest is that I know nothing at all about 
> graphics, let alone how to apply graphics in go).
>
> Cosmic1 from:  
> https://gist.github.com/thrisp/1ed1785ac6a902585595fb8cb52f0a16, 
> generates the above it is the first thing that even roughly approximates 
> what I want to do.
>
> Any thoughts, or help cleaning that up. Maybe tell me why exactly I can't 
> directly translate an opengl shader to something cpu bound(which I suspect 
> is a thing, I may need to do more that I can't see right now).
>

As for the current code:

Here you are picking a random rotation for each pixel:
a1 := .5 + float64(float64(mr.Intn(size.X))/3)/float64(mr.Intn(size.X))*2
a2 := .8 + float64(float64(mr.Intn(size.X))/2)/float64(mr.Intn(size.Y))*2

This can change for every pixel (in shader the time is a constant for one 
frame):
time := float64(time.Now().UTC().Unix())*speed + 0.25

In func toUint8(in float64) uint8 { you need to clamp the value between 0 
and 255, otherwise the conversion overflows.

Color adjusting code doesn't match the shader code.

I suspect there are further issues in the iteration code.

PS: often with such fragments you can simplify code and achieve a similar 
result with less details, e.g. 
https://gist.github.com/egonelbre/b5f41ac8946e609ce1a944631dd462ef

-- 
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: [?] emulating an opengl shader in cpu bound functions

[Egon]

On Tuesday, 21 June 2016 12:50:16 UTC+3, Egon wrote:
>
>
>
> On Monday, 20 June 2016 18:02:53 UTC+3, blue...@gmail.com wrote:
>>
>>
>> <https://lh3.googleusercontent.com/-bPOQJTHF8Js/V2gEJqUg5jI/ACI/lg6cWG0cJqo0tFl4wsuDYF2w4kycTbRPACLcB/s1600/blank.png>
>>
>> I am attempting to generate a random starfield, in go. This is something 
>> that will need to printed on actual paper, but that is another issue and I 
>> only mention it to give some context for what I am doing here: Using go to 
>> create graphics to pair with something I'm already doing in go (I've been 
>> through several iterations of trying to use the go parts I have with 
>> numerous variations of tex/latex templates using asymptote, and I reached a 
>> point of frustration where I figured why not just do it all in go, as it 
>> seems less a problem than I originally thought -- but opens a new set of 
>> problems to solve, one of the biggest is that I know nothing at all about 
>> graphics, let alone how to apply graphics in go).
>>
>> Cosmic1 from:  
>> https://gist.github.com/thrisp/1ed1785ac6a902585595fb8cb52f0a16, 
>> generates the above it is the first thing that even roughly approximates 
>> what I want to do.
>>
>> Any thoughts, or help cleaning that up. Maybe tell me why exactly I can't 
>> directly translate an opengl shader to something cpu bound(which I suspect 
>> is a thing, I may need to do more that I can't see right now).
>>
>
> As for the current code:
>
> Here you are picking a random rotation for each pixel:
> a1 := .5 + float64(float64(mr.Intn(size.X))/3)/float64(mr.Intn(size.X))*2
> a2 := .8 + float64(float64(mr.Intn(size.X))/2)/float64(mr.Intn(size.Y))*2
>
> This can change for every pixel (in shader the time is a constant for one 
> frame):
> time := float64(time.Now().UTC().Unix())*speed + 0.25
>
> In func toUint8(in float64) uint8 { you need to clamp the value between 0 
> and 255, otherwise the conversion overflows.
>
> Color adjusting code doesn't match the shader code.
>
> I suspect there are further issues in the iteration code.
>
> PS: often with such fragments you can simplify code and achieve a similar 
> result with less details, e.g. 
> https://gist.github.com/egonelbre/b5f41ac8946e609ce1a944631dd462ef
>

Here's the minimal code for doing that: 
https://gist.github.com/egonelbre/811d37e94dda69b6d92365a7e63a2eec 

+ Egon

-- 
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: A proposal for generic in go

[Egon]

On Tuesday, 21 June 2016 17:18:04 UTC+3, andrew...@gmail.com wrote:
>
> >> increase in cognitive load to decipher chains of type definitions.
>
> Sorry, but who are members of this mail lists?
> This is a first time when I hear about such loads such as the `cognitive 
> load`.
>

https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

Also I am possible here a single person who does not know anything about 
> the `cognitive load to decipher chains of type definitions`.
>

See http://www.boost.org/, although it is at the very far end of the 
spectrum (for example Dijkstra algorithm 
<http://www.boost.org/doc/libs/1_57_0/boost/graph/dijkstra_shortest_paths.hpp>).
 
Or, examples in "Modern C++ Design Generic Programming".

Or if I take the trivial example and write some facilitated code *(I know 
that concurrent map API wouldn't look like that)*:

package conc

type Map struct {
  Entries []Entry
}
type Entry struct {
  Key K
  Value V
}

package main

func PrintItems(m conc.Map, format func(T)string) {
  var entry conc.Entry
  for m.Next(&entry) {
fmt.Println(entry.Key.Name, format(entry.Value))
  }
}

func main() {
  m := conc.NewMap()
  PrintItems(m, func(x string) string { return x })
}

And I'm not doing anything complicated, yet. This approach doesn't properly 
isolate the generic parts and you get code that is completely mixed with it.

I am mostly business man and a programmer just for my own requirements.
> I love to implements parsers, code generators, some effective algorithms 
> for solving some problem at the most effective time.
> Also my work includes a diagnose the failures and locate them.
> And I want to apologize for my illiteracy (thick-headed), but I do not 
> really was expecting that all members of this mail list worry mostly about 
> the ` increase in cognitive load to decipher chains of type definitions` 
> and don't worry about other things.
> I am sorry.
>

https://github.com/golang/proposal/blob/master/design/15292-generics.md

Here are some official proposals that were unfit:

* 
https://github.com/golang/proposal/blob/master/design/15292/2010-06-type-functions.md
* https://github.com/golang/proposal/blob/master/design/15292/2011-03-gen.md
* https://github.com/golang/proposal/blob/master/design/15292/2013-10-gen.md
* 
https://github.com/golang/proposal/blob/master/design/15292/2013-12-type-params.md

+ Egon

-- 
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: A proposal for generic in go

[Egon]

As a general suggestion:

Do not use fabricated examples, use concrete real-world examples.

Fabricated examples make harder to examine the practical side of generics 
-- i.e. how would you solve a particular problem with/without generics. The 
fabricated examples can suggest a problem where there is none, 
alternatively they can trivialize the actual problem without solving it in 
the first place. *And by concrete real-world examples, I really mean code 
that someone would pay you to write.*

Talking about reusability of faciliated code is nonsense, because that code 
isn't usable in the first place.

On Wednesday, 22 June 2016 10:49:06 UTC+3, andrew...@gmail.com wrote:
>
> Sorry for typo and possible spam but correct example here:
>
> type Foo interface {
>   Get(key K) V
>   Set(key K, val V)
> }
> func foo() (int, Foo) {
>
>   // Typo: foo := &Foo{}
>   foo := &fooStruct{}
>   // ...
>   foos := []Foo{}
>   // ...
>   k := "London"
>   // ...
>   return 55, foo2(foos, 55, k)
> }
> // This code is type safe and reusable
> foo2 (foos []Foo, i int, key K) (V, Foo) {
>   foo := foos[i]
>   return foo.Get(key), foo
> }
>
>
>
>

-- 
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: windows gamepad access

[Egon]

On Wednesday, 22 June 2016 07:36:56 UTC+3, rbi...@cox.net wrote:
>
> Hi all,
> I'm just getting started with Go and, for various reasons, want to run 
> under Windows 10.   I need to read a gamepad (x360) which is read by a 
> Windows hid driver.  I can't find any posts here or elsewhere that give an 
> easy explanation of how to do so.  Is there anything in the standard 
> libraries?  or any other libraries?  or do I have to do it by calling a 
> Win32 dll or something?
>Thanks in advance for any help.  And I apologize if this question is 
> naive, but I am a newbie.
> Alex
>

You can use glfw or windows api directly:
https://gist.github.com/egonelbre/eda3b78db47236a453f5ed257da7b2e2

+ Egon

-- 
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: A proposal for generic in go

[Egon]

On Wednesday, 22 June 2016 13:02:20 UTC+3, andrew...@gmail.com wrote:
>
> >> You are not bringing anything new to the table here, except the attempt 
> to insult my intelligence, apparently.
>>
>>
> I do not have any claims to anyone personally.
> I only defend my own point of view.
>
> P.S.
>
> Also I don't love to see or use some (not my own) code which written like 
> a mess.
> If I cannot understand some code then this does not means that this code 
> is bad.
>
> But if I know that a some code has been written carelessly and can be 
> written more diligently then it gives me a negative reaction on that work 
> (if there was no reason to write it carelessly).
>
> That is, write code once and and use it everywhere.
> Or more precisely, write (high quality and reusable) code once and and use 
> it everywhere (and give the possibility to use it to everyone).
>
> The generics programming are very good suit for that.
>
> In the simplest definition, *generic programming* is a style of computer 
> programming  in which 
> algorithms are written in terms of types *to-be-specified-later* that are 
> then *instantiated* when needed for specific types provided as parameters 
> . 
>
> The term *generic programming *describes a programming paradigm whereby 
> fundamental requirements on types are abstracted from across concrete 
> examples of algorithms and data structures and formalised as concepts, with 
> generic functions implemented in terms of these concepts, typically using 
> language genericity mechanisms as described above.
>
> P.S.
>
> I am sorry but here we discuss mostly about the advantages and 
> disadvantages of the generic programming (of course, in Go language).
>

Are there any points missing in the summary? 

This thread was a about a specific proposal, but as usual with threads they 
diverge from the original topic.
 

> Here we do not discuss: How to coding in Go language without generic 
> programming.
> I think that it should be different topic with appropriate title.
>

The version without generics is necessary to compare how well a particular 
generics approach improves the current language and code.

-- 
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: A proposal for generic in go

[Egon]

On Wednesday, 22 June 2016 15:32:53 UTC+3, Andrew Mezoni wrote:
>
> >> The version without generics is necessary to compare how well a 
> particular generics approach improves the current language and code.
>
> I am sorry but this is obviously that any useful feature (in the context 
> of solving problems) improves the current language and code.
>

Yes.. Of course, this presupposes that the particular generics approach is 
useful.
How would you demonstrate that one generics approach is more useful than 
another?

Another question: how new (version of the) language will look cosmetically 
> with this newly added feature.
>
> I found that the second question here more important then the first.
>
> It is obviously correct that the code with a generics (in appropriate 
> place) would be more useful then other code.
>

Which generics approach?
Which places need that kind of generics?
Should the language solve all generics related problems or only some?
Are there better solutions to those problems than generics?
Would some meta-programming approach negate the need for generics?

Also, is "useful in some particular case" the best metric to decide whether 
something should be included in the language?

e*.g. #define max(a,b) ((a) < (b) ? (b) : (a))*

But here I undestand one interesting thing which states: Some obviously 
> useful feature can significantly spoil the overall picture of language.
>
> For me this is very strange only because even a C language also has been 
> improved after when it initially was introduced. 
>

Have you also looked at the proposals that were rejected? If someone made 
the proposal, it must have been useful to someone.

In the years following the publication of K&R C, several features were 
> added to the language, supported by compilers from AT&T and some other 
> vendors. These included:
>
>- void  functions (i.e., 
>functions with no return value)
>- functions returning struct 
>
> 
> or union  types 
>(rather than pointers)
>- assignment 
> for 
>struct data types
>- enumerated types 
>
> 
>
> Were there any competing proposal for those same feature sets? Why were 
the others rejected whereas these particular ones accepted?

Also, what if, instead functions just allowing returning struct/unions, it 
would have also allowed to return multiple parameters? Would that have 
resulted better or worse C code?
 

> C99 introduced several new features, including inline functions 
> ,
>  
> several new data types 
>  (including long long int and a complex type to represent complex numbers 
> ), variable-length arrays 
> 
>  and flexible array members 
> ,
>  
> improved support for IEEE 754  
> floating 
> point, support for variadic macros 
>  (macros of variable arity 
> ), and support for one-line comments 
> beginning with //
>
> The C11 standard adds numerous new features to C and the library, 
> including type generic macros, anonymous structures, improved Unicode 
> support, atomic operations, multi-threading, and bounds-checked functions. 
>
> P.S.
>
> I guess I should think that this is very bad, because my first 
> acquaintance with the language began with the ZX-Spetrum and continued with 
> the Borland Turbo C.
>
> Indeed, the C language is now looks much worse cosmetically than before. 
> But should I regret it?
> Maybe...
>

-- 
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: A proposal for generic in go

[Egon]

On Thursday, 23 June 2016 06:41:07 UTC+3, Thomas Bushnell, BSG wrote:
>
> This is why I like this example. Generics induce people to write the wrong 
> thing instead of thinking about the right thing. When you start thinking of 
> the right thing, you often discover better solutions.
>

*It's also a great example why real-world examples are better for 
discussion.*
 

> I think the sort package's way of doing sorting and binary search are so 
> clearly better than almost any generic implementation I've seen, that I 
> think generics are a bad idea for this reason alone.
>

To me the major issues with C++/Java/C# generics is that they are too 
fine-grained. Often they are declaration scoped with meaningless type 
parameter names "T", "K".

The most promising generics idea I've seen is packages with interface 
specialization. 1. it's harder to abuse, 2. you end up building packages as 
usual with interfaces, 3. minimal change to the language. However it has 
some drawbacks - it doesn't solve all the generics problems - only data 
structures and algorithms part. The generic "sort" package, with that 
approach, wouldn't look any different.

Thomas
>
> On Wed, Jun 22, 2016, 8:07 PM Michael Jones  > wrote:
>
>> Yes, for floats with NANs and the like, you must specialize. My 
>> replacement for the standard library sort (3x to 10x faster in the common 
>> case) had to have more macro generators than expected just to handle the 
>> "uncomparables" in float32 and float64.
>>
>> You are right about that issue.
>>
>> P.S. By the way, Hi! Good to hear from you.
>> On Jun 22, 2016 6:32 PM, "Thomas Bushnell, BSG" > > wrote:
>>
>> But Michael, that implementation isn't right for floats! Check out the 
>> actual source for math.Max.
>>
>> On Wed, Jun 22, 2016, 6:31 PM Michael Jones > > wrote:
>>
>>> The wonderful history of symbolic algebra at IBM (Scratchpad, Scratchpad 
>>> II) resulted in a third system, Axiom, that has always seemed to me a 
>>> bright lesson in types. It boldly goes into the topic with rigor, using 
>>> category theory to decide what relationships make sense and what the nature 
>>> of a tensor cross product of types truly is. 
>>>
>>> A key part of that is the notion of *more general* and *more specific* 
>>> types. This makes it possible to define a function that needs arguments 
>>> supporting a less than order relationship so it could be applied to integer 
>>> and real arguments, but not to complex numbers. This is just the mechanism 
>>> that makes a generic Max() easy to create. Imagine a definition like:
>>>
>>> func {T type, where a,b ∈T allows a>>
>>> if a < b {
>>> return b
>>> }
>>> return a
>>>
>>> }
>>>
>>> This is a nice way to answer the riddle and it is just what Axiom 
>>> supports (but expresses differently).
>>> http://axiom-developer.org/axiom-website/bookvol2.pdf
>>>
>>> Michael Jones
>>> michae...@gmail.com 
>>>
>>> On Jun 22, 2016, at 6:10 PM, 'Thomas Bushnell, BSG' via golang-nuts <
>>> golan...@googlegroups.com > wrote:
>>>
>>> Really? How would you implement math.Max with generics? 
>>>
>>> Thomas
>>>
>>> On Wed, Jun 22, 2016, 5:45 AM Viktor Kojouharov >> > wrote:
>>>
 https://golang.org/pkg/math/ and https://golang.org/pkg/container/ are 
 just two stdlib packages that would greatly benefit from some kind of 
 generics. I'm pretty sure there are more packages in the stdlib that would 
 be greatly improved. And that's just the standard library. 


 On Tuesday, June 21, 2016 at 5:29:37 PM UTC+3, Henry wrote:
>
> You still haven't provided any argument why generics is indispensable. 
>
> The reason why I am no longer sure about my position in this issue is 
> because -while I agree that generics is useful- I don't think that 
> generics 
> is essential. In fact, all of C++ features are useful and implemented in 
> a 
> very efficient manner, but take a look what happened when you slab that 
> many features together. If you can do away with less, I think you should 
> go 
> for less. The trouble is deprecating language features is a lot harder 
> than 
> deprecating APIs in the standard library, while programming fads come and 
> go. 
>

 -- 
 You received this message because you are subscribed to the Google 
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to golang-nuts...@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...@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 thi

[go-nuts] Re: A proposal for generic in go

[Egon]

On Thursday, 23 June 2016 07:59:16 UTC+3, Henry wrote:
>
>
> Having completed an earlier project, my colleagues and I sat down to 
> review the team performance and what we could do better next. My colleague 
> proposed an intriguing idea and we decided to randomly pick two components 
> of our past projects that could be implemented independently from the rest 
> of the projects and were easy to test. We rewrote the components from using 
> OO (object oriented) to using PP (procedural). I was surprised with the 
> result. The number of lines was reduced by about 30%. We were able to see 
> things that were hidden behind the complex interaction of objects before, 
> and simplified the codes considerably. Performance was improved by about 
> 5%. This was no surprise because I always knew that OO has a bit of an 
> overhead and the code simplification also helps. Maintainability is a bit 
> subjective, but my colleagues and I think that the PP codes are easier to 
> read and simpler to understand. The main obstacle in OO is with 
> understanding the model employed. In our case, we has components that were 
> outsourced to some offshore developers before, and we often had to rely on 
> external documentation to understand the model they use. What was intuitive 
> to them was not very intuitive to us. With PP, my other colleague who was 
> not involved with rewriting the codes thinks that our PP codes can be 
> understood by reading the source codes alone. However, the main selling 
> point to me is the reduction in loc. For every 1000 lines of OO codes, we 
> can save about 300 lines of codes with PP. 
>
> This experience makes me question many things and wonder whether the 
> advances in programming for the past 40 years are really improvements over 
> earlier methodologies. Everything I was taught of in college now seems 
> questionable. Some people may argue that -in my case- it is probably a case 
> of bad OO design and that if they get it right, OO should yield substantial 
> benefits, especially when it comes to maintainability. The key phrase here 
> is *'if they get it right'*. OO allows abstraction, including 
> over-abstraction, that is limited only by imagination. How do you know when 
> you reach the right design? 
>

I've seen similar reduction or increase in readability, in multiple ways, 
i.e. going from PP <-> OO; OO <-> PP, PP <-> FP, FP <-> LP, of course the 
reverse as well etc. I've even gotten into a habit of prototyping critical 
parts in multiple languages.

I suspect the major contributor in rewrites isn't the new paradigm, but 
rather the paradigm shift itself. You notice new ways of 
compressing/cleaning the code, but at the same time you can retain ideas 
from the previous iteration. The new paradigm/language gives you new 
constraints and at the same time relaxes some -- resulting in easier 
creative thinking. In essence you combine the "good design from OO" and 
"good design from PP". *Obviously, some of these translations will be lossy 
and make code larger -- so you will hit a limit eventually.*

When you talk about OO, it's useful to mention what language you were 
using, as there is no gold-standard what OO is. Even in a particular 
language you could write it in multitude of ways. I've noticed, that the 
major contributors to complexity in OO, are inheritance and displaced 
methods *(e.g. multiple objects interact and the method describing 
interaction is put into one of those objects)*. Both cause fragmented 
artifacts - in one case the inherited type is scattered around several 
places, in the other case the interaction code is scattered between 
objects. With PP you tend to use your instincts more (rather than some 
principles), and end up putting related pieces together. However it doesn't 
mean you cannot fragment the code in PP 
(http://number-none.com/blow/john_carmack_on_inlined_code.html).

Now, sure, you might not agree about how big issue inheritance/methods are 
in OO. What I'm trying to get here is that there are deeper properties than 
the paradigm, language or a feature that causes problems.

It's the same with generics approaches -- there are underlying forces that 
cause these bad-designs, and one of the questions is, how to minimize the 
bad-design while still keeping the benefits.

Returning to the topic, instead of arguing about hypothetical uses of 
> generics, we should test it in real projects and see whether the benefit of 
> generics outweighs its cost. There are other languages that support 
> generics and may be used to test this. I personally have doubts over the 
> necessity of generics. I think *if they get it right*, generics should 
> be beneficial. The key here again is '*if they get it right*'.  The room 
> for potential abuse of generics which leads to incorrect design probably 
> outweighs its benefits.
>

>
> On Wednesday, June 22, 2016 at 8:28:01 PM UTC+7, Sean Russell wrote:
>
>> On Tuesday, June 21, 2016 at 10:29:37 AM UTC-4, Henry wr

[go-nuts] Re: Trying to dynamically find interfaces

[Egon]

On Monday, 27 June 2016 17:16:40 UTC+3, David Koblas wrote:
>
> I've got a program that is trying to implement functions on "subclasses", 
> where the parent can check to see if the interface is implemented. For 
> perspective, it's really dealing with REST URL generation based on if 
> methods exist.
>

Trying to simulate subclassing is a bad idea.
 

> What I'm running into is that based on the following pattern, both the 
> IList and IGet interfaces are found on the TestController object, when only 
> 1 is implemented. When the IGet interface is called I get a panic.
>
> I would rather not make concrete definitions of the Get/List on the base 
> struct and then have to override them, would much rather do the test for 
> existence then go from there.
>
> Code is available on the playground --  
> https://play.golang.org/p/5j58fejeJ3
>

a tip, if possible, use code from your real-world use-case; *if you cannot 
share the original code, **make a similar real-world use-case, *... it 
makes it easier to understand problem context and constraints involved.
 

>
> package main
>
> import "fmt"
>
> type IGet interface {
> Get(int)
> }
>
> type IList interface {
> List(int)
> }
>
> type Application struct {
> namestring
> }
>
> type BaseAppController struct {
> *Application
>
> IGet
> IList
> }
>
> type TestController struct {
> *BaseAppController
> }
>
> func (ctrl *BaseAppController) Init() {
> fmt.Println("In Init")
>
> if f, ok := interface{}(ctrl).(IGet); ok {
> fmt.Println("Controller Found GET", f)
> } else {
> fmt.Println("Controller NOT Found GET", f)
> }
>
> if f, ok := interface{}(ctrl).(IList); ok {
> fmt.Println("Controller Found LIST", f)
> } else {
> fmt.Println("Controller NOT Found LIST", f)
> }
> }
>
> func (ctrl *BaseAppController) Call() {
> fmt.Println("In Call")
>
> if f, ok := interface{}(ctrl).(IGet); ok {
> fmt.Println("Controller Found GET - going to call", f)
>
> f.Get(7)
> } else {
> fmt.Println("Controller NOT Found GET - can't call", f)
> }
> }
>
> // Test controller implements the Get Method
> func (ctrl *TestController) Get(v int) {
> fmt.Printf("Hi name=%s v=%d\n", ctrl.name, v)
> }
>
> func main() {
> app := Application{"hithere"}
> ctrl := TestController{&BaseAppController{Application: &app}}
>
> ctrl.Init()
>
> ctrl.Call()
> }
>

-- 
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: Why there's no arithmetic process for sets?

[Egon]

On Monday, 27 June 2016 17:32:08 UTC+3, Wang Yarco wrote:
>
> First, i should say very sorry to you, guys. (It is also not for golang 
> itself, but i think you may have interests on this. Just for some advice)
> Original Post 
> 
>

People that aren't member of the group cannot see the post. (including me)
 

> When i'm reading something about sets operators, i feel strange when 
> comparing to normal arithmetic process, i mean resolving equations like:
> x + y = 5
> x - y = 3
> is very easy, we don't have to draw some diagrams. 
>

This is only because you have learned to resolve the calculations in your 
head without needing to do it on the paper. If you give the same equations 
to a child learning equations systems, they will need to do it on paper as 
well.
 

> But it is not clear except you draw venn diagram when dealing with sets:
> A - B = {3}
> A ∩ B = {4}
> (we could get A = {3, 4} here, but we can not do normal arithmetic 
> comparing to above)
>

If you show that: A = (A - B) ∪ (A ∩ B), finding the solution becomes 
trivial.


> Then, i think maybe they (the scientists who do math) didn't create enough 
> operators for sets. 
>

∩  ∪  \  -  △  '  Ø  *U*

Can describe all the outcomes given two sets. (note, the symbols may vary 
slightly)

So i add the two (actually 1 operator, 1 mark) "+" and "*":
>
> A+B is equal to A U B, but also mean no having repeated numbers 
>

There are no repeated elements in sets. Are you thinking of multisets?
 

> ( A ∩ B = ∅)
> A* means "the rest part of A"
>

Rest relative to which set?

(of cause, they are not very strictly defined...)
>
> Then, the calculation process seems more easy (without drawing a venn 
> diagram):
> A - B = {3}  <= actually =>  A* = {3}
> A ∩ B = {4} <= actually => A* + {4} = A, B* + {4} = B
> Then, it is clear that:
> A = {3, 4}
>
> (Just an idea...)
>

-- 
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: A proposal for generic in go

[Egon]

On Wednesday, 29 June 2016 01:51:58 UTC+3, Mandolyte wrote:
>
> Earlier someone asked about real world examples. The obvious standard 
> library was mentioned. It only took me a few seconds to remember Jan 
> Mercl's interval package. A quick look suggests that the current 1200+ 
> lines of code would be reduced to about 250.


I'm not sure what application would require that full extent of the 
interval package. Currently the only thing I see importing it was 
https://godoc.org/github.com/cznic/wm, but it only used only one func from 
it... so the whole package could be replaced with ~10 lines.

So the problem is that I don't know a real-world use-case for that package 
-- hence I cannot judge it's API design and quality. Sure the interval 
package might be necessary, but is there a simpler design? Is the 
genericness of that package even warranted?  How would it affect user code 
by making it generic. Are there alternate designs? Should it implement a 
tree instead?

If this sort of code is written very often, the "prove it to me" argument 
> against generics will be less effective.
>
> So, how about some more examples?
>
>

-- 
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: A proposal for generic in go

[Egon]

On Wednesday, 29 June 2016 06:35:03 UTC+3, Egon wrote:
>
> On Wednesday, 29 June 2016 01:51:58 UTC+3, Mandolyte wrote:
>>
>> Earlier someone asked about real world examples. The obvious standard 
>> library was mentioned. It only took me a few seconds to remember Jan 
>> Mercl's interval package. A quick look suggests that the current 1200+ 
>> lines of code would be reduced to about 250.
>
>
> I'm not sure what application would require that full extent of the 
> interval package. Currently the only thing I see importing it was 
> https://godoc.org/github.com/cznic/wm, but it only used only one func 
> from it... so the whole package could be replaced with ~10 lines.
>
> So the problem is that I don't know a real-world use-case for that package 
> -- hence I cannot judge it's API design and quality. Sure the interval 
> package might be necessary, but is there a simpler design? Is the 
> genericness of that package even warranted?  How would it affect user code 
> by making it generic. Are there alternate designs? Should it implement a 
> tree instead?
>
> If this sort of code is written very often, the "prove it to me" argument 
>> against generics will be less effective.
>>
>> So, how about some more examples?
>>
>
Just to be clear what I consider a *great example* for analyzing generics:

1. a package containing something non-trivial and generic
*   alternatively, multiple packages that could have benfitted from that 
generic design*
2. 3+ real-world packages/applications use that package
*   By real-world here I mean it wasn't written for learning or fun, but 
rather solving a concrete problem.*
3. the package is specialized with at least 4 different types
*   ~4 types is where manual management of specializations becomes too 
verbose*
4. the package is implemented "in the best way"
*   e.g. linked list would be a bad example, because it's usually a bad 
solution <https://www.youtube.com/watch?v=YQs6IC-vgmo> in the first place*
5. the package using it, is written "in the best way"
*   e.g. code using a custom implementation of map without a good reason is 
a bad example*

Reasoning for those points, *1.* is just the baseline implementation and 
ensures that the specializations can use a non-trivial amount of code; *2.* 
ensures that package 1. is actually valuable in practice; *3.* ensures that 
the package would benefit from generics; *4./5.* are mainly for discussion 
and whether the right problem was solved, maybe 1. can be significantly 
simplified or is unnecessary.

*PS: I'm not saying there isn't value in smaller examples, but when all 
listed conditions are met, then it's easier to analyse what trade-offs can 
be made and how those will affect code using it.*

+ Egon

-- 
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: A proposal for generic in go

[Egon]

On Wednesday, 29 June 2016 14:45:09 UTC+3, Sean Russell wrote:
>
> On Wednesday, June 29, 2016 at 2:31:59 AM UTC-4, Egon wrote:
>>
>> Just to be clear what I consider a *great example* for analyzing 
>> generics:
>>
>> 2. 3+ real-world packages/applications use that package
>> *   By real-world here I mean it wasn't written for learning or fun, but 
>> rather solving a concrete problem.*
>>
>
> How about one (a single) production application with 106 types, all 
> sharing three common functions identical except for the type categories 
> they operate over? 
>

Hence, the either-or in packages and applications. The reason for multiple 
packages/applications is to ensure that it isn't an isolated problem 
affecting very few applications. Of course, it still is a good example... 
although not great. *Also it gives more weight to that particular problem 
compared to other generic issues.*
 

> 1411 LOC that could not only be reduced to around 300 (interesting that my 
> numbers are similar to the one @Mandolyte came up with from 'interval') -- 
> although, I'll state again that saving LOC isn't the killer feature of this 
> request; it's the fact that a bug fix or other change has to be made in 25 
> different places.
>  
>
>> 4. the package is implemented "in the best way"
>> *   e.g. linked list would be a bad example, because it's usually a bad 
>> solution <https://www.youtube.com/watch?v=YQs6IC-vgmo> in the first place*
>>
>
> My example, detailed in another thread, is deserializing XML content from 
> a legacy SOAP application, and normalizing and simplifying the data 
> structures. 
>

Could you link to it? I'm unable to find it...
 

> The 106 types, 25 functions, and 1411 LOC is just for the SOAP & 
> deserializing.  There's a whole other chunk of code dealing with the 
> conversion from type to type that I used introspection for (*that* was a 
> mistake!) rather than deal with several more thousand lines of duplicate 
> code.
>
> My case is extremely error prone and difficult to maintain safely.  I'm 
> afraid to touch the code.  There's enough customization on a couple types 
> that templating wouldn't be much help.  I'd *love* suggestions of a 
> better way to implement than copy/paste.  I can't even use introspection
>
> The criteria you lay out assumes a public library; bespoke, single-purpose 
> applications should also be able to be used as valid examples.
>

As said, it's just criteria for a great example -- maybe "perfect example" 
would be a better name :). Obviously there is room for examples that fill 
only some or only fill partially those conditions.

-- 
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: A proposal for generic in go

[Egon]

On Friday, 1 July 2016 10:32:20 UTC+3, Øyvind Teig wrote:
>
> I assume the scope of the discussion about introducing generics is not how 
> Go-generics might hypothetically be transformed to idiomatic Go. I find no 
> reference to "unsafe" in neither of these (already mentioned here):
>
>- "Proposal: Go should have generics" by Ian Lance Taylor 
>https://github.com/golang/proposal/blob/master/design/15292-generics.md
> 
>- "proposal: generic programming facilities" by Andrew Gerrand 
>https://github.com/golang/go/issues/15292 
>
> Neither do I find any mention of "reflect", which I assume might be 
> relevant.
>
> From this I infer that adding generics to Go is a rather large affair. It 
> also looks like that in the pages above.
>
> More interesting, I don't see formal modeling verification mentioned in 
> any of the generics-documents above, neither in this recent thread:
>
>- "formal verification in Go? someday perhaps?" at 
>https://groups.google.com/forum/#!topic/golang-nuts/MVITBF3TcOE
>
> I know that Rob Pike was involved with formal verification since long 
> ("Bell Labs and CSP Threads", by Russ Cox, see 
> https://swtch.com/~rsc/thread/) and that this background was colouring 
> much of how Go ended up. Has generics been discussed along this line: that 
> Go-generics might be more/less suitable for formal verification?
>

I haven't seen such discussion. I can't even recall even seeing anywhere 
such formal verification system (one that is based on generics and isn't 
dependently typed). It's an interesting thought, but I cannot even imagine 
how to bind together generics and *(non-trivial)* formal verification. *And 
then ... a formal verficiation implementation that doesn't slow down 
compilation.*


> Øyvind
>
> fredag 1. juli 2016 06.30.35 UTC+2 skrev Andrew Mezoni følgende:
>>
>> >> it can be done with using unsafe
>>
>> This is the only available method (and very suitable).
>> The same method used throughout in the Go language the runtime.
>> It's very easy to do that.
>>
>> Problem only to find appropriate syntax for the current Go grammar for to 
>> be look as idiomatic Go.
>> I still not found that but I am still looking (this even is a bigger 
>> problem than "how to implement them?").
>>
>

-- 
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: A proposal for generic in go

[Egon]

On Friday, 1 July 2016 21:34:10 UTC+3, Andrew Mezoni wrote:
>
> >> The generic dilemma is this: *do you want slow programmers, slow 
> compilers and bloated binaries, or slow execution times?*
>
> (The Java approach.) Box everything implicitly. 
> This slows execution. 
>
> I just want to add some clarification.
> This does not slows a whole execution.
> All that works fast will remain the same fast.
>
> Of course, new (generic) code will be slightly slower by the following 
> reasons.
> 1. Information about the types will be obtained not at the compile time 
> but at the runtime (this requires a some time to access this information).
>

Go has to run in environments where runtime code-generation / modification 
is not allowed. 
(https://docs.google.com/document/pub?id=1IXHI5Jr9k4zDdmUhcZImH59bOUK0G325J1FY6hdelcM)

-- 
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: A proposal for generic in go

[Egon]

On Friday, 1 July 2016 21:59:19 UTC+3, Andrew Mezoni wrote:
>
> >> Go has to run in environments where runtime code-generation / 
> modification is not allowed. 
>

> Where you find that I wrote about that?
>

Yeah, sorry, my mistake:

*1. Information about the types will be obtained not at the compile time 
but at the runtime*

I assumed that meant that you build up some type-information and use that 
at runtime to optimize specific pieces of code.

-- 
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: Without normalisation is there any way of iterating over this string by grapheme?

[Egon]

On Wednesday, 6 July 2016 17:31:06 UTC+3, gary.wi...@victoriaplumb.com 
wrote:
>
> I have a little snippet here which iterates over a string.
>
> package main
>
> import "fmt"
>
> func main() {
>
> text := "Noël"
>
> for _, rune_ := range text {
> fmt.Printf("%#U\n", rune_)
> }
> }
>
> Playground: https://play.golang.org/p/bVfXB2crKo
>
> The output is not correct because it breaks the 'e' from the diaeresis '
> *¨*'.
>
> Without normalisation (because it doesn't work with all code points), is 
> there any way of iterating over this string by grapheme to output each as a 
> fully formed readable character?
>

I'm not an expert in this area, but combing characters belong to mark 
category: https://play.golang.org/p/2X8xc9sijY

-- 
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: log.Logger, Why is this not an interface?

[Egon]

On Friday, 8 July 2016 07:33:37 UTC+3, zger...@pivotal.io wrote:
>
> Hey All,
>
> Originally asked on twitter but a more long-form medium is required to 
> answer this question. I've recently been working on adding logging to a 
> library and have been replacing what was once a custom logging interface 
> with just *log.Logger. 
>
In so doing, I removed my ability to mock the logger (if I choose) and that 
> steered me towards not testing / test-driving any of my logging output.
>

Why do you need to mock it? You can replace *log.Logger with one that 
writes to a *bytes.Buffer.

Walking down this path led me to these specific questions:
>
> 1. Does any one REALLY test whether their app logs specific log lines 
> (when logging is not your the apps primary function)
>

Depends on whether the logs have value to the end-user or not.

2. Why isn't log.Logger just an interface instead of a struct (or why isn't 
> there a LogWriter interface that specifies a few of the log packages 
> multiple methods)
>

Packages should usually implement concrete types instead of interfaces. 
Interfaces should be declared by the user of the package. Interfaces add 
indirection and more code... when it's not necessary it's waste. Instead of 
understanding one thing you need to understand multiple things.

3. What has been the litmus test for when the stdlib will provide an 
> interface (like io.Writer)
>

I guess it's more of a standards based approach -- i.e. there's a standard 
way to write bytes to a file... however there is no standard way to log, 
there are tons of different approaches.

-- 
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: An efficient runtime expression evaluation

[Egon]

On Friday, 8 July 2016 16:25:40 UTC+3, Ondrej wrote:
>
> Hi all,
> I have a model with variables, let's call them a, b, c, ..., z. These are 
> numerical values (time series loaded from a database) and I let the user 
> specify their relationships in a JSON, say 'z = 12; x = a + 2/3 + 3*c; y = 
> log(12*f) + exp(g)' etc. The syntax is trivial - it's basically just 
> algebraic relationships + a few functions (log, log2, log10, exp, 
> trigonometrics, ...; all 1:1 mappings to their math package equivalents).
>

*Tip: include a working piece of code that you want to make faster, it 
makes it easier for people to see the problems and common issues.*


> Now, I get these relationships in a JSON and I parse them using go/parser. 
> Then I walk the tree once and process it a bit - replacing keywords by 
> pointers to my variable stores, replacing all the log/exp/sin with function 
> pointers, leaving literals be literals etc. Each node is then a struct with 
> a type and the actual contents (sadly a generic interface, because the 
> value can be almost anything). The prep stage is now over.
>
> When actually running the model, I loop through years and within each year 
> I solve each variable - I walk the tree and evaluate it where needed. The 
> only non-trivial action is when I get to a model variable, I need to do a 
> bit of lookup (it's a time series, so I need to look up the correct time 
> period and other bits). Otherwise it's just literals, operators and 
> function calls, all of which is fairly straightforward.
>
> This is all well and good. One of the issues is that it's rather slow. I 
> thought it would be the recursive nature (and interface assertions), but 
> converting all this into a shunting yard system didn't improve the 
> performance dramatically. I've profiled the thing and removed a few 
> hotspots, my question is not about profiling. I'm after a bit more general 
> advice on how to handle these runtime evaluations and if there are better 
> ways of doing so. Essentially some sort of a JIT (but Go does not have 
> runtime assembly, right?), or maybe convert each expression into a closure 
> or maybe a whole different algorithm or...?
>

Reduce the amount of code and indirection that you need to do, few basic 
ideas:
1. implement a VM https://play.golang.org/p/dlmZ2lGPY7
2. operate on vectors of variables instead of single 
values https://play.golang.org/p/25MIjIXs0D
3. try to do the lookup of all necessary variables before starting to 
compute with them; if possible

Obviously pprof is your friend. 
(https://blog.golang.org/profiling-go-programs)

+ Egon

-- 
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: Make a multi part request from a stringified body payload

[Egon]

Not quite sure what you mean by reconstructing the request. There is 
https://golang.org/pkg/mime/multipart/ for parsing MIME multipart.

On Sunday, 10 July 2016 15:39:00 UTC+3, Mayank Jha wrote:
>
> Any clues people ?
>
> On Thursday, July 7, 2016 at 5:05:13 PM UTC+5:30, Mayank Jha wrote:
>>
>> I have the payload,
>> "--3c1e04950334427b
>> Content-Disposition: form-data; name="certificate"; 
>> filename="new-cert.pem"
>> Content-Type: application/octet-stream
>>
>> -BEGIN RSA PRIVATE KEY-
>> 
>> -END RSA PRIVATE KEY-
>> -BEGIN CERTIFICATE-
>> 
>> -END CERTIFICATE-
>>
>> --3c1e04950334427b
>> Content-Disposition: form-data; name="body"
>> Content-Type: application/json
>>
>> {"name":"test"}
>> --3c1e04950334427b--" which I obtained by doing,
>>
>> //Here r is a *http.Request. object
>>
>> body := new(bytes.Buffer)
>> if r.Body != nil {
>>b, _ := ioutil.ReadAll(r.Body)
>>r.Body = ioutil.NopCloser(bytes.NewBuffer(b))
>>if len(b) > 0 {
>>   if err := json.Compact(body, b); err != nil {
>>  body = bytes.NewBuffer(b)
>>   }
>>}
>> }
>>
>> payload := body.String()
>>
>>
>> I want to reconstruct the request from this payload, how can I do that ? 
>> Is that possible ? If yes, how ?
>>
>>
>>

-- 
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: TCP Server

[Egon]

On Monday, 11 July 2016 07:53:00 UTC+3, EdgarAlejandro Vintimilla wrote:
>
>
> hi
> What is the best way to implement a TCP server, I found many examples, 
> including in this book
> http://cdn.oreillystatic.com/oreilly/booksamplers/9781491941959_sampler.pdf
>
> but I would like some recommendation of how to make a more robust TCP 
> server
>

*tip: explain both your problem and context, it helps people get oriented 
faster. e.g. I'm building a MUD server for ~1000 players... or I'm building 
a SMTP server that needs to be fault-tolerant etc.*

You can additionally take a look 
at https://talks.golang.org/2012/chat.slide. Of course there is no "ideal" 
solution for building TCP servers, different problems will require 
different solutions.

+ Egon

-- 
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: which approach to appending a slice to another slice by creating a new slice look best to you?

[Egon]

On Monday, 11 July 2016 07:06:03 UTC+3, Anmol Sethi wrote:
>
> https://gist.github.com/nhooyr/7b773ea98f0d08e698d4fe706b4f5b2a 
>

It depends on what problem you are solving manually specifying *cap* may 
not give you the exact same behavior as specifying the *len*. In this case 
it looks like the chains you build are immutable, hence you probably want 
to manually specify the *cap*.

I would probably use the 2. version, because it to me is the clearest what 
it actually needs to do.

+ Egon

-- 
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: TCP Server

[Egon]

On Thursday, 14 July 2016 17:41:32 UTC+3, EdgarAlejandro Vintimilla wrote:
>
> Thanks, basically is a GPS that sends data to the server. It's for a fit 
> traker. 
>
> What is the best way to put into producción this server?


There are probably few important things to consider:
1. use encryption (you are transferring personal information and it needs 
to be protected)
2. use compression (you are on a mobile device, i.e. low speed and high 
price)
3. ensure that you have some fault tolerance (and ensure that device can 
record locally and sync later in case of network failures)

I would use regular HTTPS instead of a raw TCP server, it has most of those 
properties and Go has a solid http.Server. But, it really doesn't matter as 
long as you have those 3 properties. I would even consider things such as 
"AWS Lambda" to avoid managing servers, but that entirely depends on how 
much information you need to download/upload.

I think there should be Go REST tutorials so you can look up those.

+ Egon

-- 
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: scheduling non determinism

[Egon]

On Sunday, 17 July 2016 19:05:44 UTC+3, Scott Cotton wrote:
>
> Hi all,
>
> I'm looking for information/pointers for making the scheduling and 
> select {} choices determinisable for an application domain in which 
> non-determinism in scheduling/select causes problems.
>

This seems like queues are the wrong solution for communication in this 
case.

Just a simple case

ch := make(chan int)
go computeSquare(ch, 1)
go computeSquare(ch, 2)

fmt.Println(<-ch, <-ch)

Now, due to things running at different speeds, OS switching, and the 
inherent indeterminism in CPU, you can end up with either 1 or 4 as the 
output. Even if the Go scheduler does not interrupt, the OS or/and the CPU 
itself can cause the indeterminism.

The only reasonable way I can see this being solved is to introduce an 
order to the results.

ch1 := make(chan int)
ch2 := make(chan int)

go computeSquare(ch1, 1)
go computeSquare(ch2, 2)

fmt.Println(<-ch1, <-ch2)

Now there are different ways of approaching the ordering of intermediate 
results... and the nicest one will entirely depend on the problem at 
hand... But the basic premise is that, distribute the workload giving each 
process/thread/goroutine a token. Merge the results together you need to 
process the tokens in a particular order... *Of course each process in turn 
can split the work similarly. *But when you want to schedule new work e.g. 
a new iteration, all previous work must have been done. For random, you 
would need to also split your seed somehow...

e.g. the simplest thing that could work

var mu sync.Mutex
var results [8]struct {
done  bool
value int
}

for i := range results {
go func(index int){
result := index * index

mu.Lock()
results[index].value = result
results[index].done = true
mu.Unlock()
}(i)
}

*// alternatively you can also use here WaitGroup to wait that all 
computations have been completed.*

var total int
for i := range results {
var value int
for {
mu.Lock()
if results[i].done {
value = results[i].value
mu.Unlock()
break
}
mu.Unlock()
time.Sleep(time.Millisecond)
}

total = (total << 1) | value
}

fmt.Println(total)

*tl;dr; don't use queues for communicating results from different 
threads/goroutines/processes/computers.*

*+ Egon*


> For my own purposes I plan to make a determinisable version of the
> gc toolchain where one can set a random seed via an environmental variable.
> If there is shared interest in this endeavour, please chime in.
>
> If any gc officianados could comment about how to go about this (on 
> technical grounds, not contribution IP requirements), it would be 
> appreciated.
>
> Thanks,
>
> -- 
> Scott Cotton
> http://www.iri-labs.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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: problems receiving data from a GPS

[Egon]

On Sunday, 17 July 2016 21:42:26 UTC+3, EdgarAlejandro Vintimilla wrote:
>
> Hi, I have a GPS that sends me data through a connection TCP
>
> the data it sends me are in ASCII, and I have to convert it to HEX
>
> for example in python I'm doing this 
>
> BUFFER_SIZE = 1024
> conn, addr = s.accept()
> data = conn.recv(BUFFER_SIZE)
> data.encode("hex")
> conn.close()
> print data
>
> and it works.
>
> but in GO, 
>
>   buf := make([]byte, 1024)
>   reqLen, err := conn.Read(buf)
>

Note, from here you are not using reqLen, you probably should do:
buf = buf[:reqLen], although if the conn is not fast enough you may not 
receive the full request.
 

>   if err != nil {
> fmt.Println("Error: ", err.Error())
>   }
>
>   fmt.Println("buf: ", buf) 
>   fmt.Println("buf str: ", string(buf))
>

this []byte to string conversion assumes that "buf" is encoded as UTF8, so 
if you have bytes that are larger than 0x7f you might get bizarre results. 
*(Although 
I know you mentioned ASCII, it might also be Extended ASCII)*
 

>   var str string = ""
>   for i:=0; i< len(buf); i++{
> str += strconv.FormatUint(uint64(buf[i]), 16)
>   }
>   fmt.Println("str: ", str) 
>
> or if I use io, error2 :=ioutil.ReadAll(connection) i do not get the exact 
> data that it sends me in any way
>

data, err := ioutil.ReadAll(conn)
if err != nil { panic(err) }
enc := hex.EncodeToString(data)
fmt.Println("hex:", enc)


Also you should be probably reading up to the message sequence not 
everything. Protocols usually define some ending character or sequence, or 
have a leading length of message. I suspect you should read up-to a 
line-feed instead of everything. And also that might be the reason that you 
get different results from Go and Python.

+ Egon

-- 
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: problems receiving data from a GPS

[Egon]

What is the difference in the data that you receive?

On Monday, 18 July 2016 05:42:36 UTC+3, EdgarAlejandro Vintimilla wrote:
>
> now I have this, but still not the correct results
>
> package main
>
> import (
> "fmt"
> "net"
> "os"
> //"strconv"
> //"bytes"
> //"io/ioutil"
> //"net/http"
> "reflect"
> //"strings"
> )
>
> const (
> CONN_HOST = ""
> CONN_PORT = ""
> CONN_TYPE = "tcp"
> )
>
> func main() {
> // Listen for incoming connections.
> l, err := net.Listen(CONN_TYPE, CONN_HOST+":"+CONN_PORT)
> if err != nil {
> fmt.Println("Error listening:", err.Error())
> os.Exit(1)
> }
> // Close the listener when the application closes.
> defer l.Close()
> fmt.Println("Listening on " + CONN_HOST + ":" + CONN_PORT)
> for {
> // Listen for an incoming connection.
> conn, err := l.Accept()
> if err != nil {
> fmt.Println("Error accepting: ", err.Error())
> os.Exit(1)
> }
> // Handle connections in a new goroutine.
> go handleRequest(conn)
> }
> }
>
> // Handles incoming requests.
> func handleRequest(conn net.Conn) {
>
>   // Make a buffer to hold incoming data.
>   buf := make([]byte, 1024)
>
>   // Read the incoming connection into the buffer.
>   reqLen, err := conn.Read(buf)
>   buf = buf[:reqLen]
>
>   if err != nil {
> fmt.Println("Error reading:", err.Error())
>   }
>
>   var cadena string = ""
>   for i := 0; i < len(buf)-1; i++ {
> cadena += fmt.Sprintf("%x ", buf[i])
>   }
>
>
>   // Send a response back to person contacting us.
>   conn.Write([]byte( "ok" ))
>   fmt.Println("cadena: ", cadena, reflect.TypeOf(cadena) )
>   fmt.Println( "\n" )
>
>   // Close the connection when you're done with it.
>   conn.Close()
> 
> }
>
>
>
> On Sunday, July 17, 2016 at 2:05:22 PM UTC-5, Egon wrote:
>>
>> On Sunday, 17 July 2016 21:42:26 UTC+3, EdgarAlejandro Vintimilla wrote:
>>>
>>> Hi, I have a GPS that sends me data through a connection TCP
>>>
>>> the data it sends me are in ASCII, and I have to convert it to HEX
>>>
>>> for example in python I'm doing this 
>>>
>>> BUFFER_SIZE = 1024
>>> conn, addr = s.accept()
>>> data = conn.recv(BUFFER_SIZE)
>>> data.encode("hex")
>>> conn.close()
>>> print data
>>>
>>> and it works.
>>>
>>> but in GO, 
>>>
>>>   buf := make([]byte, 1024)
>>>   reqLen, err := conn.Read(buf)
>>>
>>
>> Note, from here you are not using reqLen, you probably should do:
>> buf = buf[:reqLen], although if the conn is not fast enough you may not 
>> receive the full request.
>>  
>>
>>>   if err != nil {
>>> fmt.Println("Error: ", err.Error())
>>>   }
>>>
>>>   fmt.Println("buf: ", buf) 
>>>   fmt.Println("buf str: ", string(buf))
>>>
>>
>> this []byte to string conversion assumes that "buf" is encoded as UTF8, 
>> so if you have bytes that are larger than 0x7f you might get bizarre 
>> results. *(Although I know you mentioned ASCII, it might also be 
>> Extended ASCII)*
>>  
>>
>>>   var str string = ""
>>>   for i:=0; i< len(buf); i++{
>>> str += strconv.FormatUint(uint64(buf[i]), 16)
>>>   }
>>>   fmt.Println("str: ", str) 
>>>
>>> or if I use io, error2 :=ioutil.ReadAll(connection) i do not get the 
>>> exact data that it sends me in any way
>>>
>>
>> data, err := ioutil.ReadAll(conn)
>> if err != nil { panic(err) }
>> enc := hex.EncodeToString(data)
>> fmt.Println("hex:", enc)
>>
>>
>> Also you should be probably reading up to the message sequence not 
>> everything. Protocols usually define some ending character or sequence, or 
>> have a leading length of message. I suspect you should read up-to a 
>> line-feed instead of everything. And also that might be the reason that you 
>> get different results from Go and Python.
>>
>> + Egon
>>
>

-- 
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: An efficient runtime expression evaluation

[Egon]

On Monday, 18 July 2016 03:11:29 UTC+3, ondrej...@gmail.com wrote:
>
> Cheers, I tried replicating my endeavours (
> https://play.golang.org/p/Qxoo2ASac6), sorry if it's still too verbose. 
> It's essentially rewriting the inbuilt ast.Node into a simpler nested 
> struct and then walking it.
>
> In testing the performance, I started adding algebraic expressions, which 
> make my walking more expensive, but don't change the 'native' expression 
> evaluation (I guess due to constant folding).
>
> As to your suggestion three - I do the variable lookup in the parsing 
> stage, but I still need to retain the pointer, not the value itself, 
> because I'm accessing an element of that given variable (time series), and 
> this element (time period) changes at runtime.
>

https://play.golang.org/p/dd4hTpMKrp

Of course you can additionally add constant folding and similar... 
Additionally instead of working on a single float at a time, make each 
variable an array of 8 floats, that are computed in parallel.

One performance gain I can think of is to implement some pruning through 
> the abovementioned constant folding and other optimisations, but I'd rather 
> leave that as the last resort. Another thing that comes to mind is that I 
> could return nested closures in some way - meaning that '1+3*x' would be, 
> in go-like pseudocode, add(func() { return one }, func mul(func() { return 
> three}, func() {return model[x]} )), where the one/tree are values passed 
> to the closure when parsing the equation; but that's just now off the top 
> of my head.
>
> I attached a pprof result in the header.
>
> Thanks again.
>
> On Friday, 8 July 2016 15:46:32 UTC+1, Egon wrote:
>>
>> On Friday, 8 July 2016 16:25:40 UTC+3, Ondrej wrote:
>>>
>>> Hi all,
>>> I have a model with variables, let's call them a, b, c, ..., z. These 
>>> are numerical values (time series loaded from a database) and I let the 
>>> user specify their relationships in a JSON, say 'z = 12; x = a + 2/3 + 3*c; 
>>> y = log(12*f) + exp(g)' etc. The syntax is trivial - it's basically just 
>>> algebraic relationships + a few functions (log, log2, log10, exp, 
>>> trigonometrics, ...; all 1:1 mappings to their math package equivalents).
>>>
>>
>> *Tip: include a working piece of code that you want to make faster, it 
>> makes it easier for people to see the problems and common issues.*
>>
>>
>>> Now, I get these relationships in a JSON and I parse them using 
>>> go/parser. Then I walk the tree once and process it a bit - replacing 
>>> keywords by pointers to my variable stores, replacing all the log/exp/sin 
>>> with function pointers, leaving literals be literals etc. Each node is then 
>>> a struct with a type and the actual contents (sadly a generic interface, 
>>> because the value can be almost anything). The prep stage is now over.
>>>
>>> When actually running the model, I loop through years and within each 
>>> year I solve each variable - I walk the tree and evaluate it where needed. 
>>> The only non-trivial action is when I get to a model variable, I need to do 
>>> a bit of lookup (it's a time series, so I need to look up the correct time 
>>> period and other bits). Otherwise it's just literals, operators and 
>>> function calls, all of which is fairly straightforward.
>>>
>>> This is all well and good. One of the issues is that it's rather slow. I 
>>> thought it would be the recursive nature (and interface assertions), but 
>>> converting all this into a shunting yard system didn't improve the 
>>> performance dramatically. I've profiled the thing and removed a few 
>>> hotspots, my question is not about profiling. I'm after a bit more general 
>>> advice on how to handle these runtime evaluations and if there are better 
>>> ways of doing so. Essentially some sort of a JIT (but Go does not have 
>>> runtime assembly, right?), or maybe convert each expression into a closure 
>>> or maybe a whole different algorithm or...?
>>>
>>
>> Reduce the amount of code and indirection that you need to do, few basic 
>> ideas:
>> 1. implement a VM https://play.golang.org/p/dlmZ2lGPY7
>> 2. operate on vectors of variables instead of single values 
>> https://play.golang.org/p/25MIjIXs0D
>> 3. try to do the lookup of all necessary variables before starting to 
>> compute with them; if possible
>>
>> Obviously pprof is your friend. (
>> https://blog.golang.org/profiling-go-programs)
>>
>> + Egon
>>
>

-- 
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: An efficient runtime expression evaluation

[Egon]

PS: you may want to research and learn how Forth interpreters are 
implemented, they have similar problems.

On Monday, 18 July 2016 10:30:14 UTC+3, Egon wrote:
>
> On Monday, 18 July 2016 03:11:29 UTC+3, ondrej...@gmail.com wrote:
>>
>> Cheers, I tried replicating my endeavours (
>> https://play.golang.org/p/Qxoo2ASac6), sorry if it's still too verbose. 
>> It's essentially rewriting the inbuilt ast.Node into a simpler nested 
>> struct and then walking it.
>>
>> In testing the performance, I started adding algebraic expressions, which 
>> make my walking more expensive, but don't change the 'native' expression 
>> evaluation (I guess due to constant folding).
>>
>> As to your suggestion three - I do the variable lookup in the parsing 
>> stage, but I still need to retain the pointer, not the value itself, 
>> because I'm accessing an element of that given variable (time series), and 
>> this element (time period) changes at runtime.
>>
>
> https://play.golang.org/p/dd4hTpMKrp
>
> Of course you can additionally add constant folding and similar... 
> Additionally instead of working on a single float at a time, make each 
> variable an array of 8 floats, that are computed in parallel.
>
> One performance gain I can think of is to implement some pruning through 
>> the abovementioned constant folding and other optimisations, but I'd rather 
>> leave that as the last resort. Another thing that comes to mind is that I 
>> could return nested closures in some way - meaning that '1+3*x' would be, 
>> in go-like pseudocode, add(func() { return one }, func mul(func() { return 
>> three}, func() {return model[x]} )), where the one/tree are values passed 
>> to the closure when parsing the equation; but that's just now off the top 
>> of my head.
>>
>> I attached a pprof result in the header.
>>
>> Thanks again.
>>
>> On Friday, 8 July 2016 15:46:32 UTC+1, Egon wrote:
>>>
>>> On Friday, 8 July 2016 16:25:40 UTC+3, Ondrej wrote:
>>>>
>>>> Hi all,
>>>> I have a model with variables, let's call them a, b, c, ..., z. These 
>>>> are numerical values (time series loaded from a database) and I let the 
>>>> user specify their relationships in a JSON, say 'z = 12; x = a + 2/3 + 
>>>> 3*c; 
>>>> y = log(12*f) + exp(g)' etc. The syntax is trivial - it's basically just 
>>>> algebraic relationships + a few functions (log, log2, log10, exp, 
>>>> trigonometrics, ...; all 1:1 mappings to their math package equivalents).
>>>>
>>>
>>> *Tip: include a working piece of code that you want to make faster, it 
>>> makes it easier for people to see the problems and common issues.*
>>>
>>>
>>>> Now, I get these relationships in a JSON and I parse them using 
>>>> go/parser. Then I walk the tree once and process it a bit - replacing 
>>>> keywords by pointers to my variable stores, replacing all the log/exp/sin 
>>>> with function pointers, leaving literals be literals etc. Each node is 
>>>> then 
>>>> a struct with a type and the actual contents (sadly a generic interface, 
>>>> because the value can be almost anything). The prep stage is now over.
>>>>
>>>> When actually running the model, I loop through years and within each 
>>>> year I solve each variable - I walk the tree and evaluate it where needed. 
>>>> The only non-trivial action is when I get to a model variable, I need to 
>>>> do 
>>>> a bit of lookup (it's a time series, so I need to look up the correct time 
>>>> period and other bits). Otherwise it's just literals, operators and 
>>>> function calls, all of which is fairly straightforward.
>>>>
>>>> This is all well and good. One of the issues is that it's rather slow. 
>>>> I thought it would be the recursive nature (and interface assertions), but 
>>>> converting all this into a shunting yard system didn't improve the 
>>>> performance dramatically. I've profiled the thing and removed a few 
>>>> hotspots, my question is not about profiling. I'm after a bit more general 
>>>> advice on how to handle these runtime evaluations and if there are better 
>>>> ways of doing so. Essentially some sort of a JIT (but Go does not have 
>>>> runtime assembly, right?), or maybe convert each expression into a closure 
>>>> or maybe a whole different algorithm or...?
>>>>
>>>
>>> Reduce the amount of code and indirection that you need to do, few basic 
>>> ideas:
>>> 1. implement a VM https://play.golang.org/p/dlmZ2lGPY7
>>> 2. operate on vectors of variables instead of single values 
>>> https://play.golang.org/p/25MIjIXs0D
>>> 3. try to do the lookup of all necessary variables before starting to 
>>> compute with them; if possible
>>>
>>> Obviously pprof is your friend. (
>>> https://blog.golang.org/profiling-go-programs)
>>>
>>> + Egon
>>>
>>

-- 
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: DB application design: Embedding vs Having an ID field pointing to resource

[Egon]

On Monday, 18 July 2016 10:33:44 UTC+3, fazal wrote:
>
> Fellow gophers,
>
> I'm having this dilemma of whether to embed related struct, or to have an 
> ID field pointing to resource in the DB.
>

Note ensure that your ID is not generated from the Name, team names change 
and if you rely on it being based on the Name you end up with problems when 
changing team names.
 

>
> Say I have something like these types defined.
>
> type Team struct{
> ID string
> Name string
> }
>
> type Organization struct {
> ID string
> Name string
> }
>
>  Now my question is which is better, more idiomatic
>
>
> // 1
> type Team struct{
>  ID string
>  Name string
>  OrgID string
> }
>
>
> // 2
> type Team struct {
>  ID string
>  Name string
>  Organization Organization
>
> }
>
> Web applications I see mostly use 1, which is sensible as most of the time 
> you only just need Organization ID with Team.
> But sometimes you just need to include a little bit more information 
> (mostly for JSON output). For that with 1 you'd have to define another type 
> that include both Team and Organization.
>
> With 2 the problem is you need to embed Organization type even if you just 
> needed the ID. Also you'd have to have `json:"omitempty"` everywhere since 
> you don't want empty fields in your JSON.
> And that alone is not enough, some types would need to be changed to 
> pointer types within the struct since `omitempty` does consider them as 
> empty.
>
> I know I could use a mix of this, but that makes it difficult to create a 
> consistent API with a consistent format.
>
> Assuming it's mostly for web applications with JSON API endpoints, how do 
> you tackle this problem? 
>

Two additional possibilities:

https://play.golang.org/p/aTvCPj2h1P
https://play.golang.org/p/PI5fNg42U9

-- 
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: An efficient runtime expression evaluation

[Egon]

On Monday, 18 July 2016 10:30:14 UTC+3, Egon wrote:
>
> On Monday, 18 July 2016 03:11:29 UTC+3, ondrej...@gmail.com wrote:
>>
>> Cheers, I tried replicating my endeavours (
>> https://play.golang.org/p/Qxoo2ASac6), sorry if it's still too verbose. 
>> It's essentially rewriting the inbuilt ast.Node into a simpler nested 
>> struct and then walking it.
>>
>> In testing the performance, I started adding algebraic expressions, which 
>> make my walking more expensive, but don't change the 'native' expression 
>> evaluation (I guess due to constant folding).
>>
>> As to your suggestion three - I do the variable lookup in the parsing 
>> stage, but I still need to retain the pointer, not the value itself, 
>> because I'm accessing an element of that given variable (time series), and 
>> this element (time period) changes at runtime.
>>
>
> https://play.golang.org/p/dd4hTpMKrp
>
> Of course you can additionally add constant folding and similar... 
> Additionally instead of working on a single float at a time, make each 
> variable an array of 8 floats, that are computed in parallel.
>
>
Just realized that it's trivial to write basic constant 
folding: https://play.golang.org/p/iqWX5_Mweb

This brings the result to:

interpreter: 17.001ms
native: 7.0004ms

Which is approximately the best I would expect from an interpreter without 
JIT (and not computing multiple time-points at a time).

+ Egon

One performance gain I can think of is to implement some pruning through 
>> the abovementioned constant folding and other optimisations, but I'd rather 
>> leave that as the last resort. Another thing that comes to mind is that I 
>> could return nested closures in some way - meaning that '1+3*x' would be, 
>> in go-like pseudocode, add(func() { return one }, func mul(func() { return 
>> three}, func() {return model[x]} )), where the one/tree are values passed 
>> to the closure when parsing the equation; but that's just now off the top 
>> of my head.
>>
>> I attached a pprof result in the header.
>>
>> Thanks again.
>>
>> On Friday, 8 July 2016 15:46:32 UTC+1, Egon wrote:
>>>
>>> On Friday, 8 July 2016 16:25:40 UTC+3, Ondrej wrote:
>>>>
>>>> Hi all,
>>>> I have a model with variables, let's call them a, b, c, ..., z. These 
>>>> are numerical values (time series loaded from a database) and I let the 
>>>> user specify their relationships in a JSON, say 'z = 12; x = a + 2/3 + 
>>>> 3*c; 
>>>> y = log(12*f) + exp(g)' etc. The syntax is trivial - it's basically just 
>>>> algebraic relationships + a few functions (log, log2, log10, exp, 
>>>> trigonometrics, ...; all 1:1 mappings to their math package equivalents).
>>>>
>>>
>>> *Tip: include a working piece of code that you want to make faster, it 
>>> makes it easier for people to see the problems and common issues.*
>>>
>>>
>>>> Now, I get these relationships in a JSON and I parse them using 
>>>> go/parser. Then I walk the tree once and process it a bit - replacing 
>>>> keywords by pointers to my variable stores, replacing all the log/exp/sin 
>>>> with function pointers, leaving literals be literals etc. Each node is 
>>>> then 
>>>> a struct with a type and the actual contents (sadly a generic interface, 
>>>> because the value can be almost anything). The prep stage is now over.
>>>>
>>>> When actually running the model, I loop through years and within each 
>>>> year I solve each variable - I walk the tree and evaluate it where needed. 
>>>> The only non-trivial action is when I get to a model variable, I need to 
>>>> do 
>>>> a bit of lookup (it's a time series, so I need to look up the correct time 
>>>> period and other bits). Otherwise it's just literals, operators and 
>>>> function calls, all of which is fairly straightforward.
>>>>
>>>> This is all well and good. One of the issues is that it's rather slow. 
>>>> I thought it would be the recursive nature (and interface assertions), but 
>>>> converting all this into a shunting yard system didn't improve the 
>>>> performance dramatically. I've profiled the thing and removed a few 
>>>> hotspots, my question is not about profiling. I'm after a bit more general 
>>>> advice on how to handle these runtime evaluations and if there are better 
>>>> ways o

[go-nuts] Re: An efficient runtime expression evaluation

[Egon]

On Monday, 18 July 2016 11:13:08 UTC+3, Egon wrote:
>
>
>
> On Monday, 18 July 2016 10:30:14 UTC+3, Egon wrote:
>>
>> On Monday, 18 July 2016 03:11:29 UTC+3, ondrej...@gmail.com wrote:
>>>
>>> Cheers, I tried replicating my endeavours (
>>> https://play.golang.org/p/Qxoo2ASac6), sorry if it's still too verbose. 
>>> It's essentially rewriting the inbuilt ast.Node into a simpler nested 
>>> struct and then walking it.
>>>
>>> In testing the performance, I started adding algebraic expressions, 
>>> which make my walking more expensive, but don't change the 'native' 
>>> expression evaluation (I guess due to constant folding).
>>>
>>> As to your suggestion three - I do the variable lookup in the parsing 
>>> stage, but I still need to retain the pointer, not the value itself, 
>>> because I'm accessing an element of that given variable (time series), and 
>>> this element (time period) changes at runtime.
>>>
>>
>> https://play.golang.org/p/dd4hTpMKrp
>>
>> Of course you can additionally add constant folding and similar... 
>> Additionally instead of working on a single float at a time, make each 
>> variable an array of 8 floats, that are computed in parallel.
>>
>>
> Just realized that it's trivial to write basic constant folding: 
> https://play.golang.org/p/iqWX5_Mweb
>

Although it probably will be easier to maintain and extend as a separate 
pass: https://play.golang.org/p/xcz5mXoaOG
 

>
> This brings the result to:
>
> interpreter: 17.001ms
> native: 7.0004ms
>
> Which is approximately the best I would expect from an interpreter without 
> JIT (and not computing multiple time-points at a time).
>
> + Egon
>
> One performance gain I can think of is to implement some pruning through 
>>> the abovementioned constant folding and other optimisations, but I'd rather 
>>> leave that as the last resort. Another thing that comes to mind is that I 
>>> could return nested closures in some way - meaning that '1+3*x' would be, 
>>> in go-like pseudocode, add(func() { return one }, func mul(func() { return 
>>> three}, func() {return model[x]} )), where the one/tree are values passed 
>>> to the closure when parsing the equation; but that's just now off the top 
>>> of my head.
>>>
>>> I attached a pprof result in the header.
>>>
>>> Thanks again.
>>>
>>> On Friday, 8 July 2016 15:46:32 UTC+1, Egon wrote:
>>>>
>>>> On Friday, 8 July 2016 16:25:40 UTC+3, Ondrej wrote:
>>>>>
>>>>> Hi all,
>>>>> I have a model with variables, let's call them a, b, c, ..., z. These 
>>>>> are numerical values (time series loaded from a database) and I let the 
>>>>> user specify their relationships in a JSON, say 'z = 12; x = a + 2/3 + 
>>>>> 3*c; 
>>>>> y = log(12*f) + exp(g)' etc. The syntax is trivial - it's basically just 
>>>>> algebraic relationships + a few functions (log, log2, log10, exp, 
>>>>> trigonometrics, ...; all 1:1 mappings to their math package equivalents).
>>>>>
>>>>
>>>> *Tip: include a working piece of code that you want to make faster, it 
>>>> makes it easier for people to see the problems and common issues.*
>>>>
>>>>
>>>>> Now, I get these relationships in a JSON and I parse them using 
>>>>> go/parser. Then I walk the tree once and process it a bit - replacing 
>>>>> keywords by pointers to my variable stores, replacing all the log/exp/sin 
>>>>> with function pointers, leaving literals be literals etc. Each node is 
>>>>> then 
>>>>> a struct with a type and the actual contents (sadly a generic interface, 
>>>>> because the value can be almost anything). The prep stage is now over.
>>>>>
>>>>> When actually running the model, I loop through years and within each 
>>>>> year I solve each variable - I walk the tree and evaluate it where 
>>>>> needed. 
>>>>> The only non-trivial action is when I get to a model variable, I need to 
>>>>> do 
>>>>> a bit of lookup (it's a time series, so I need to look up the correct 
>>>>> time 
>>>>> period and other bits). Otherwise it's just literals, operators and 
>>>>> function calls, all of which is fairly straightforward.
>

Re: [go-nuts] Re: An efficient runtime expression evaluation

[Egon]

On Monday, 18 July 2016 13:27:09 UTC+3, Michael Jones wrote:
>
> Anything much faster than this needs vector operations in the interpreter 
> so the “get to the OP function” overhead is once per time series rather 
> than once per element in the series.
>

I managed to make it a little faster https://play.golang.org/p/Tr2PRKI23w, 
but runs only on windows (kind of).

*What have I done...*

+ Egon

 

>  
>
> *From: *> on behalf of Egon <
> egon...@gmail.com >
> *Date: *Monday, July 18, 2016 at 1:32 AM
> *To: *golang-nuts >
> *Cc: *>
> *Subject: *[go-nuts] Re: An efficient runtime expression evaluation
>
>  
>
>
>
> On Monday, 18 July 2016 11:13:08 UTC+3, Egon wrote:
>
>
>
> On Monday, 18 July 2016 10:30:14 UTC+3, Egon wrote:
>
> On Monday, 18 July 2016 03:11:29 UTC+3, ondrej...@gmail.com wrote:
>
> Cheers, I tried replicating my endeavours (
> https://play.golang.org/p/Qxoo2ASac6), sorry if it's still too verbose. 
> It's essentially rewriting the inbuilt ast.Node into a simpler nested 
> struct and then walking it.
>
>  
>
> In testing the performance, I started adding algebraic expressions, which 
> make my walking more expensive, but don't change the 'native' expression 
> evaluation (I guess due to constant folding).
>
>  
>
> As to your suggestion three - I do the variable lookup in the parsing 
> stage, but I still need to retain the pointer, not the value itself, 
> because I'm accessing an element of that given variable (time series), and 
> this element (time period) changes at runtime.
>
>  
>
> https://play.golang.org/p/dd4hTpMKrp
>
>  
>
> Of course you can additionally add constant folding and similar... 
> Additionally instead of working on a single float at a time, make each 
> variable an array of 8 floats, that are computed in parallel.
>
>  
>
>  
>
> Just realized that it's trivial to write basic constant folding: 
> https://play.golang.org/p/iqWX5_Mweb
>
>  
>
> Although it probably will be easier to maintain and extend as a separate 
> pass: https://play.golang.org/p/xcz5mXoaOG
>
>  
>
>  
>
> This brings the result to:
>
>  
>
> interpreter: 17.001ms
>
> native: 7.0004ms
>
>  
>
> Which is approximately the best I would expect from an interpreter without 
> JIT (and not computing multiple time-points at a time).
>
>  
>
> + Egon
>
>  
>
> One performance gain I can think of is to implement some pruning through 
> the abovementioned constant folding and other optimisations, but I'd rather 
> leave that as the last resort. Another thing that comes to mind is that I 
> could return nested closures in some way - meaning that '1+3*x' would be, 
> in go-like pseudocode, add(func() { return one }, func mul(func() { return 
> three}, func() {return model[x]} )), where the one/tree are values passed 
> to the closure when parsing the equation; but that's just now off the top 
> of my head.
>
>  
>
> I attached a pprof result in the header.
>
>  
>
> Thanks again.
>
>
> On Friday, 8 July 2016 15:46:32 UTC+1, Egon wrote:
>
> On Friday, 8 July 2016 16:25:40 UTC+3, Ondrej wrote:
>
> Hi all,
>
> I have a model with variables, let's call them a, b, c, ..., z. These are 
> numerical values (time series loaded from a database) and I let the user 
> specify their relationships in a JSON, say 'z = 12; x = a + 2/3 + 3*c; y = 
> log(12*f) + exp(g)' etc. The syntax is trivial - it's basically just 
> algebraic relationships + a few functions (log, log2, log10, exp, 
> trigonometrics, ...; all 1:1 mappings to their math package equivalents).
>
>  
>
> *Tip: include a working piece of code that you want to make faster, it 
> makes it easier for people to see the problems and common issues.*
>
>  
>
>  
>
> Now, I get these relationships in a JSON and I parse them using go/parser. 
> Then I walk the tree once and process it a bit - replacing keywords by 
> pointers to my variable stores, replacing all the log/exp/sin with function 
> pointers, leaving literals be literals etc. Each node is then a struct with 
> a type and the actual contents (sadly a generic interface, because the 
> value can be almost anything). The prep stage is now over.
>
>  
>
> When actually running the model, I loop through years and within each year 
> I solve each variable - I walk the tree and evaluate it where needed. The 
> only non-trivial action is when I get to a model variable, I need to do a 
> bit of lookup (it's a time series, so I need to look up the correct time 
> period and other bits). Otherwise it

[go-nuts] Re: problems receiving data from a GPS

[Egon]

Usually in these cases it helps to bring up the diff between the bytes:

<https://lh3.googleusercontent.com/-SzaoriDYD-c/V43aSOMR1iI/CKc/ycqDFbZyKcEZEfIB7zavcefLgM97SDzvgCLcB/s1600/gps.png>

So the things I noticed here, 
* the data definitely is not ASCII
* it looks like some GPS protocol, find the spec how to properly parse it.
* Go data looks more what I would expect than Python; Python seems to be 
converting the data into ASCII range, *notice how most of the differences 
are in bytes higher than 0x80.*

So, find the GPS protocol spec and reference application and first 
implement that.

+ Egon

On Tuesday, 19 July 2016 06:58:58 UTC+3, EdgarAlejandro Vintimilla wrote:
>
> In GO I get this data 
>
> buf := make([]byte, 1024)
> buf:  [64 64 153 0 4 50 49 51 71 76 50 48 49 52 48 49 53 49 56 55 0 0 0 0 
> 0 16 1 233 24 140 87 64 25 140 87 68 88 10 0 136 2 0 0 182 29 0 0 4 0 0 0 4 
> 0 7 100 1 17 19 0 3 0 1 17 7 16 23 43 59 76 94 160 0 244 82 243 16 7 0 0 0 
> 0 73 68 68 95 50 49 51 71 48 50 95 83 32 86 50 46 50 46 54 0 73 68 68 95 50 
> 49 51 71 48 50 95 72 32 86 50 46 50 46 54 0 13 0 1 24 2 24 1 26 1 30 1 31 2 
> 31 3 31 4 31 5 31 6 31 7 31 1 33 2 33 224 55 13 10] []uint8
>
> cadena += fmt.Sprintf("%x ", buf[i])
> cadena:  40 40 99 0 4 32 31 33 47 4c 32 30 31 34 30 31 35 31 38 37 0 0 0 0 
> 0 10 1 e9 18 8c 57 40 19 8c 57 44 58 a 0 88 2 0 0 b6 1d 0 0 4 0 0 0 4 0 7 
> 64 1 11 13 0 3 0 1 11 7 10 17 2b 3b 4c 5e a0 0 f4 52 f3 10 7 0 0 0 0 49 44 
> 44 5f 32 31 33 47 30 32 5f 53 20 56 32 2e 32 2e 36 0 49 44 44 5f 32 31 33 
> 47 30 32 5f 48 20 56 32 2e 32 2e 36 0 d 0 1 18 2 18 1 1a 1 1e 1 1f 2 1f 3 
> 1f 4 1f 5 1f 6 1f 7 1f 1 21 2 21 e0 37 d  string
>
>
> and python
>
> 4040990004323133474c3230313430313531383700100111a38d5766a38d57855d0a00c21d0100040007640e000300011307100331317e4aa000f245f3108c495f3231334730325f532056322e322e3600495f3231334730325f482056322e322e36000d0001180218011a011e011f021f031f041f051f061f071f0121022171a40d0a
>
>
>
> ---
> On Monday, July 18, 2016 at 1:23:05 AM UTC-5, Egon wrote:
>>
>> What is the difference in the data that you receive?
>>
>> On Monday, 18 July 2016 05:42:36 UTC+3, EdgarAlejandro Vintimilla wrote:
>>>
>>> now I have this, but still not the correct results
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "net"
>>> "os"
>>> //"strconv"
>>> //"bytes"
>>> //"io/ioutil"
>>> //"net/http"
>>> "reflect"
>>> //"strings"
>>> )
>>>
>>> const (
>>> CONN_HOST = ""
>>> CONN_PORT = ""
>>> CONN_TYPE = "tcp"
>>> )
>>>
>>> func main() {
>>> // Listen for incoming connections.
>>> l, err := net.Listen(CONN_TYPE, CONN_HOST+":"+CONN_PORT)
>>> if err != nil {
>>> fmt.Println("Error listening:", err.Error())
>>> os.Exit(1)
>>> }
>>> // Close the listener when the application closes.
>>> defer l.Close()
>>> fmt.Println("Listening on " + CONN_HOST + ":" + CONN_PORT)
>>> for {
>>> // Listen for an incoming connection.
>>> conn, err := l.Accept()
>>> if err != nil {
>>> fmt.Println("Error accepting: ", err.Error())
>>> os.Exit(1)
>>> }
>>> // Handle connections in a new goroutine.
>>> go handleRequest(conn)
>>> }
>>> }
>>>
>>> // Handles incoming requests.
>>> func handleRequest(conn net.Conn) {
>>>
>>>   // Make a buffer to hold incoming data.
>>>   buf := make([]byte, 1024)
>>>
>>>   // Read the incoming connection into the buffer.
>>>   reqLen, err := conn.Read(buf)
>>>   buf = buf[:reqLen]
>>>
>>>   if err != nil {
>>> fmt.Println("Error reading:", err.Error())
>>>   }
>>>
>>>   var cadena string = ""
>>>   for i := 0; i < len(buf)-1; i++ {
>>> cadena += fmt.Sprintf("%x ", buf[i])
>>>   }
>>>
>>>
>>>   // Send a response back to person contacting us.
>>>   conn.Write([]byte( "ok" ))
>>>   fmt.Println("cadena: ", cadena, r

Re: [go-nuts] Re: An efficient runtime expression evaluation

[Egon]

On Monday, 18 July 2016 19:37:46 UTC+3, ondrej...@gmail.com wrote:
>
> I think this pretty much covers it
>
> _, err := VirtualProtect(fn.body, 0x40)
> if err != nil {
> panic(err)
> }
>
> // OH GOD WHAT HAVE I DONE???
> type callstub struct{ fn func(*Memory) }
>
> Excellent and worrying work :-) A 2x difference between interpreted and 
> native is pretty rad. It strongly reminds me of the JIT endeavours I 
> researched earlier today - none of those seemed to have survived. I'd wait 
> until there's native support before pushing things like these into 
> production. But it would be nice to reopen the discussion about runtime 
> (portable) assembly, could make performance critical code in the 
> text/numerical analysis sphere quite a bit easier.
>

One of the main issue with runtime code-generation is that it requires 
special permissions from the machine, which means there must be some sort 
of fallback possible. However those fallbacks are very likely to be 2x 
slower. But, yes, there are niches that it can be very effectively used.

I would much rather see some language extension that generates 
highly-optimized and vectorized asm code based on regular Go code. *e.g. 
long compilation times would be fine here. *However, compiler gets faster 
and faster, so I'm not sure how useful it would be in the long run.

Of course there's no reason there cannot be both.

The discussion isn't so much as "how to do it" or "what exactly to do", but 
rather "somebody needs to do few first prototypes".

+ Egon


> As for all the other developments in this thread - I'll go through them 
> one by one - there are subtle things (operators from int to byte, which 
> makes for faster comparisons; caching of value lookups) and less subtle 
> things (VM), where I'll have to consider the ups and downs. After all, my 
> example is quite cut down and the actual production version has a lot more 
> complexity bolted on with a lot more data and fast turnaround (so caching 
> and small VMs might not be worthwhile). In any case, lot of excellent 
> advice all around, thank you, sir.
>
> On Monday, 18 July 2016 17:07:27 UTC+1, Egon wrote:
>>
>> On Monday, 18 July 2016 13:27:09 UTC+3, Michael Jones wrote:
>>>
>>> Anything much faster than this needs vector operations in the 
>>> interpreter so the “get to the OP function” overhead is once per time 
>>> series rather than once per element in the series.
>>>
>>
>> I managed to make it a little faster https://play.golang.org/p/Tr2PRKI23w, 
>> but runs only on windows (kind of).
>>
>> *What have I done...*
>>
>> + Egon
>>
>>  
>>
>>>  
>>>
>>> *From: * on behalf of Egon >> >
>>> *Date: *Monday, July 18, 2016 at 1:32 AM
>>> *To: *golang-nuts 
>>> *Cc: *
>>> *Subject: *[go-nuts] Re: An efficient runtime expression evaluation
>>>
>>>  
>>>
>>>
>>>
>>> On Monday, 18 July 2016 11:13:08 UTC+3, Egon wrote:
>>>
>>>
>>>
>>> On Monday, 18 July 2016 10:30:14 UTC+3, Egon wrote:
>>>
>>> On Monday, 18 July 2016 03:11:29 UTC+3, ondrej...@gmail.com wrote:
>>>
>>> Cheers, I tried replicating my endeavours (
>>> https://play.golang.org/p/Qxoo2ASac6), sorry if it's still too verbose. 
>>> It's essentially rewriting the inbuilt ast.Node into a simpler nested 
>>> struct and then walking it.
>>>
>>>  
>>>
>>> In testing the performance, I started adding algebraic expressions, 
>>> which make my walking more expensive, but don't change the 'native' 
>>> expression evaluation (I guess due to constant folding).
>>>
>>>  
>>>
>>> As to your suggestion three - I do the variable lookup in the parsing 
>>> stage, but I still need to retain the pointer, not the value itself, 
>>> because I'm accessing an element of that given variable (time series), and 
>>> this element (time period) changes at runtime.
>>>
>>>  
>>>
>>> https://play.golang.org/p/dd4hTpMKrp
>>>
>>>  
>>>
>>> Of course you can additionally add constant folding and similar... 
>>> Additionally instead of working on a single float at a time, make each 
>>> variable an array of 8 floats, that are computed in parallel.
>>>
>>>  
>>>
>>>  
>>>
>>> Just realized that it's trivial to write basic constant folding: 
>>> https://play.golang.org/p/iqWX5_Mweb
>&

[go-nuts] Re: Go is for everyone

[Egon]

So far my research, and small scale experiments (mostly one-on-one 
teaching), on this topic has lead me to these points.

I separated these into levels to make it easier to understand, however when 
teaching to some degree they can be mixed.

*Level 0*

These I consider fundamental, either you understand and learn them or you 
won't be able to program. Not knowing/understanding these are a better 
predictor than anything else I've seen:

1. Dealing with frustration
2. Problem Solving
3. Learning

Dealing and understanding frustration is one of the least taught things, 
but it has the biggest benefit to the learners. It helps with motivation 
and means people can stand more difficult problems when learning... also 
better willpower. Many seem to think that programming is similar to writing 
just a piece of text and when things don't go that easy, assume they are 
stupid and cannot learn it.

Dealing with frustration is essential part of programming. It can be 
avoided in two ways, either teach more gradually or teach how to deal and 
focus frustration.

There's a process how people solve problems and how they can solve them 
better. "How to Solve It" by Polya is great book on this book. Often people 
start randomly trying things rather than take a more structured approach to 
solving problems.

Learning here means that "learning the essence of things" rather than 
memorizing things. Some people have very good memorization skills, which 
means they can tell exactly what something is, but are not able to actually 
use it. "Learning How To Learn" is a good summary course on the topic 
https://www.coursera.org/learn/learning-how-to-learn 

Problem Solving and Learning can be made into a really good feedback loop 
-- i.e. you can "solve the problem how to learn faster/better" and you can 
"learn how to solve problems better"...


Using LightBot (https://lightbot.com/) it's possible to teach all of these 
ideas together. I.e. explain how people feel frustration, how to deal with 
it. Let them self-monitor how frustration builds and how they react to it. 
When getting stuck, show how scribbling on paper helps.

*Level 1*

Here we need to learn computational thinking, for better or worse. LightBot 
really helps here as well.

0. Syntax and tooling or "we need to communicate with the computer"
1. Meaning of things or "computers are very stupid"
2. Making things concrete or "mapping your mental model to code"
3. Progams do what they do or "computers are still stupid"
4. Reaching the goal or "learn the process not the end-result"
5. Limits or "we are stupid"

With this knowledge people should be capable of writing programs 
1000-5000LOC, i.e. things that don't require architecural descisions.

Extended notes, but old: 
https://github.com/egonelbre/spark/blob/master/basics-of-programming.rst

*Level 2*

This is mostly leveling up your skill and knowledge

1. Read code
2. Write code

Pick some:
3. Algorithmics (http://www.algorist.com/)
4. Web programming
5. Machine code
6. How memory works
7. How floating point works
8. Concurrency
9. Few more languages
...

*Level 3*

Here we have skills that would help you to build 1MLOC+ programs.

1. Learning different tradeoffs
2. How to analyze tradeoffs between different solutions
3. Writing some real programs with someone reviewing
4. Process of writing large program or "gradual stiffening"

For 2. there is a really nice exercise - write at least 10 different ways 
for converting temperature units.

Mentorship is an essential part, i.e. getting better people to review your 
code is the best thing that can happen.

4. is currently incomplete and least formulated... I only have ~3000 pages 
still to read and ~5 projects to write :), before properly starting to 
write about it.

Hopefully this helps somehow...

*Sidenotes/Disclaimers:*
*I haven't had a good chance in teaching this way, so there might be some 
essential parts missing. However one-on-one sessions seem to be promising. 
I'm aware that class-room situations are more difficult. E.g. people will 
learn these at very different speed and trying to homogenize it, would 
always frustrate some... it's better to let people advance at a different 
pace.*

+ Egon

On Tuesday, 19 July 2016 18:16:05 UTC+3, Matt Aimonetti wrote:
>
> I just wanted to point out a post I published today talking about the fact 
> that we are often leaving new / less experienced Go developers high and 
> dry:
> https://medium.com/@mattetti/go-is-for-everyone-b4f84be04c43
>
> I'd love to see what you all in mind to help new or junior developers. 
> Maybe share some of the pain points you've experienced or seen (for 
> instance setting up the Go path, finding resources to get started etc...) 
> I'm thinking about a bunch of very short posts on

[go-nuts] Re: Go is for everyone

[Egon]

Just realized one very important point, that I should have highlighted:

In the initial Level 0 and Level 1, helping and googling must be very 
controlled. The important part is teaching the process of solving problems 
and writing code.

While teaching, if there's an obvious syntax error, you should not point it 
out, but rather teach a process that helps them find it. Not letting them 
find the problem has a negative effect for solving more difficult problems. 
In other words, you've just let them skip learning "dealing with 
frustration" and "process of finding bug locations" on small scale.

At all costs avoid giving them the answer. If necessary make up a similar 
situation and explain how you would solve it there, but let them solve the 
original problem. Only explain the process.

*Once they learn the process, you can give the answers to move faster to 
the next step ... how ever, it prevents people from practicing those 
processes... so then use it with caution.*

Now in Level 2, it's necessary to teach proper Googling skill and how to 
get help etc. Then you have learned the foundation so there's less problem 
with giving a direct answer.

+ Egon

On Wednesday, 20 July 2016 10:56:28 UTC+3, Egon wrote:
>
> So far my research, and small scale experiments (mostly one-on-one 
> teaching), on this topic has lead me to these points.
>
> I separated these into levels to make it easier to understand, however 
> when teaching to some degree they can be mixed.
>
> *Level 0*
>
> These I consider fundamental, either you understand and learn them or you 
> won't be able to program. Not knowing/understanding these are a better 
> predictor than anything else I've seen:
>
> 1. Dealing with frustration
> 2. Problem Solving
> 3. Learning
>
> Dealing and understanding frustration is one of the least taught things, 
> but it has the biggest benefit to the learners. It helps with motivation 
> and means people can stand more difficult problems when learning... also 
> better willpower. Many seem to think that programming is similar to writing 
> just a piece of text and when things don't go that easy, assume they are 
> stupid and cannot learn it.
>
> Dealing with frustration is essential part of programming. It can be 
> avoided in two ways, either teach more gradually or teach how to deal and 
> focus frustration.
>
> There's a process how people solve problems and how they can solve them 
> better. "How to Solve It" by Polya is great book on this book. Often people 
> start randomly trying things rather than take a more structured approach to 
> solving problems.
>
> Learning here means that "learning the essence of things" rather than 
> memorizing things. Some people have very good memorization skills, which 
> means they can tell exactly what something is, but are not able to actually 
> use it. "Learning How To Learn" is a good summary course on the topic 
> https://www.coursera.org/learn/learning-how-to-learn 
>
> Problem Solving and Learning can be made into a really good feedback loop 
> -- i.e. you can "solve the problem how to learn faster/better" and you can 
> "learn how to solve problems better"...
>
>
> Using LightBot (https://lightbot.com/) it's possible to teach all of 
> these ideas together. I.e. explain how people feel frustration, how to deal 
> with it. Let them self-monitor how frustration builds and how they react to 
> it. When getting stuck, show how scribbling on paper helps.
>
> *Level 1*
>
> Here we need to learn computational thinking, for better or worse. 
> LightBot really helps here as well.
>
> 0. Syntax and tooling or "we need to communicate with the computer"
> 1. Meaning of things or "computers are very stupid"
> 2. Making things concrete or "mapping your mental model to code"
> 3. Progams do what they do or "computers are still stupid"
> 4. Reaching the goal or "learn the process not the end-result"
> 5. Limits or "we are stupid"
>
> With this knowledge people should be capable of writing programs 
> 1000-5000LOC, i.e. things that don't require architecural descisions.
>
> Extended notes, but old: 
> https://github.com/egonelbre/spark/blob/master/basics-of-programming.rst
>
> *Level 2*
>
> This is mostly leveling up your skill and knowledge
>
> 1. Read code
> 2. Write code
>
> Pick some:
> 3. Algorithmics (http://www.algorist.com/)
> 4. Web programming
> 5. Machine code
> 6. How memory works
> 7. How floating point works
> 8. Concurrency
> 9. Few more languages
> ...
>
> *Level 3*
>
> Here we have skills that would help you to build 1MLOC+ prog

[go-nuts] Re: Go is for everyone

[Egon]

On Wednesday, 20 July 2016 12:40:01 UTC+3, Simon Ritchie wrote:
>
> I taught C to second year undergraduates back in the 1990s.  By this time, 
> they had done some COBOL (those were the days), Pascal and assembler.  Two 
> things they had great difficulty with were pointers and multithreading.  
> Multithreading is not such an issue because you can avoid it while they are 
> learning the basics, but you couldn't avoid pointers for long.  Go is, if 
> anything, even worse, because pretty much as soon as you introduce 
> functions you have to get involved in pointers, because without pointers 
> you can't write a function that sets data.  Other languages such as Java 
> manage to hide pointers sufficiently well that you don't have to get to 
> grips with them until you have the rest of the language under your belt.  
> Actually, I'm guessing that there are lots of successful Java programmers 
> out there who have never really understood those things that Java calls 
> references.
>
> To be honest, I'm not entirely sure why pointers are such a big issue for 
> students who had done a bit of assembler, but trust me, for some they are.  
> I think one reason may be that they are one of a set of related concepts, 
> and you have to understand them all before any one of them makes sense.
>

I've explained pointers in terms of arrays...

var memory [1<<10]byte
// defining a pointer
p := 10
// assigning to a pointer
memory[p] = 123 // *p := 123
// dereference
fmt.Println(memory[p]) // *p
// indexing array starting at p
fmt.Println(memory[p+8])
// double dereference
fmt.Println(memory[memory[p]]) // **p

Then show how you can store bigger values, structs or strings... etc.

Multithreading is a different matter. I just found that many people have 
> great difficulty visualising several threads working at the same time.
>

For multithreading "The Little Book of Semaphores" by A. Downey 
(http://greenteapress.com/wp/semaphores/), it has many exercises about "how 
things can go wrong", which is one of the fundamentals of concurrency.
 

>
> Apart from those specific issues, people new to programming have great 
> difficulty with the idea of (a) variables and (b) expressions.  These very 
> fundamental and crucial ideas are actually quite hard to grasp.  To a 
> newcomer, it all just looks very arbitrary.  I have a variable called 
> "total", but it could just as  easily be called "wibble".  Why is it called 
> "total" then?  What are the rules?  This variable contains a string.  
> What's a string?  Oh, it's a bit of text.  Why would I want to store a bit 
> of text?  Because the instructor understands these concepts very well, they 
> often don't appreciate how difficult some people find them at first, and 
> they take them at too fast a pace.
>
> Changing tack completely, I've also encountered a different problem.  Most 
> people are only interested in computers when they do useful things - useful 
> to them.  So, the instructor shows them a program that takes two numbers, 
> adds them together and displays the result.  They can do that themselves 
> with a calculator.  Take a list ten numbers that are out of order and sort 
> them.  Why not just write the list in the correct order in the first 
> place?  What's the point of all this?  Many people are just not willing to 
> go through many hours of artificial examples on the assumption that they 
> might one day learn something useful.  You have to convince them before you 
> begin that they are going to learn something useful (to them) and keep them 
> on board throughout.
>
> If you think about it, *why not just write the list in the correct order 
> in the first place?* is actually a fundamentally important question, 
> involving stuff that we are good at, and computers are bad at.  We can just 
> look at a small list of numbers and write it down in sorted order.  Why 
> can't the computer do that?   The answer to you is probably so obvious that 
> it shouldn't need explaining, something on the lines of "it's not the same 
> problem when you have a million numbers", but then why would I be 
> interested in sorting a million numbers into order?
>
> Sorry if this is a bit vague.  I've been thinking about this stuff ever 
> since I gave up teaching many years ago.  I know what some of the problems 
> are, but I'm really not certain of the answers.
>

-- 
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: Go is for everyone

[Egon]

On Thursday, 21 July 2016 10:43:06 UTC+3, Ralf Schülke wrote:
>
> Hi,
>
> Programming language is secondary level.
> first must be clear as works as a Computer (machine) production.
>
> In my early time, which was very clear but hard 8bit machines could one 
> still imagine today the machine are a thousand times faster and their 
> possibilities as well.
>
> Alone GPU, I / O, the kernel and userland programming there is also so 
> much you need to know.
>
> In my time, BASIC was the only and my imagination and my own motivation, 
> books and friends.
>
> Today, we have the Internet, www and 100 of possibilities. Many new want 
> to make games whose examples same (3d games etc). Only this day expenses 
> with very large and it takes a long time and can not be done by a single 
> person.
>
> Conclusion:
> -  Learn how works a Machine
>  (Neumann architecture) or DCPU16 Emu. Number systems, bits & bytes, asm
> - Programming paradigms, Unix philosophy, data structures
> - Then golang as first language
>
> Personally, I also think that one aspect, about the attitude as a 
> programmer:
> - Open source vs closed source
> - Hacking (white vs black)
> - Judge of techniques
> - Behave in a network (jargon file)
>

Note, I do not agree that this is the best way for most beginners to start 
programming, however I think it's important for professional programmer to 
understand how computers work internally.

People can get a lot of value by just wiring libraries together... even if 
the code doesn't look great and/or breaks sometimes.

In a similar sense, I would not recommend learning piano by first seeing 
how the piano works. However, if you are a professional, you probably 
should know how to tune the piano, understand piano voicing and basic 
maintenance.

This sort of teaching has a high frustration level and low reward... 
however people who manage to get through it, would definitely be good 
programmers. And if you have intrinsic motivations, it makes it so much 
easier. There are of course ways to make reward higher, e.g. TIS-100 comes 
to mind. The younger the people, the higher you want the reward and lower 
the frustration.

It helps to keep in mind that there are different audiences for programming 
- children, teenagers, adults, personal programming, computer scientists, 
software developers, computer technology, robotics ... Of course people are 
different, so no single strategy for teaching can work, there should be 
multiple of them.

*Sidenote: the best course for computer internals I've seen is 
http://www.nand2tetris.org/.*

For computer technology and robotics people, it would be an excellent 
approach. For teaching children methodical thinking and problem solving to 
children, not so much.

*But, I also do not consider "no-frustration" the best approach either. In 
a similar sense, to learn running you must eventually get tired and there's 
no way around it.*

w.r.t paradigms, unix philosophy and data-structures... although important 
for professional developers, it's hard to convey the importance of them, 
without having real-world problems backing them. I.e. you can give a 
mathematical definition of functional programming, but people will just 
forget or don't pay attention to it -- basically they don't get the point 
and hence won't understand. *Alternatively, it becomes a cult thing -- i.e. 
FP is good hence I will use it, without seeing it being used in real-world. 
(Just an example, I don't have anything against FP... I could say the same 
about SP, OOP, LP, AOP etc.)*

There's one major additional concern with this sort of teaching -- it 
ignores the human aspects of software development. If you focus on learning 
technology instead of focusing on people, you get software that serves 
engineers rather than people using it. There must be a good balance between 
those two sides.

There's a ton of things I would consider worth learning for developers -- 
but there's just too much information... effective teaching means teaching 
the bits that are either hard to learn or things that empowers learning 
everything else.

+ Egon

-- 
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: Speeding up multiple regexp matches

[Egon]

If the regexps aren't dynamic then Ragel 
(http://www.colm.net/open-source/ragel/).
There's https://github.com/BurntSushi/rure-go, which might work better than 
Go-s regexp.

There might be interesting approaches depending on the regexp and input 
data.

Also, show example data and some regexps that are representative of the 
data you are running it on.

+ Egon

On Wednesday, 27 July 2016 11:11:35 UTC+3, Raj wrote:
>
> Not specific to golang. Incidentally I am using go to develop this 
> particular tool.
>
> I have a piece of text that I want to test against a large number of 
> regular expressions, where a different action is taken based on which 
> regexps successfully
> matched. The naive approach is to loop through each regexp and if matches 
> do the corresponding action and continue.
>
> I thought of combining all of the regular expressions into one massive 
> regexp, and let the regexp state machine do all the discriminating. The 
> problem with
> this is that it gives you no way to determine which regexps were the matched 
> among all.
>
> Any suggestions?
>
>
>

-- 
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: first program, game of life in go

[Egon]

On Wednesday, 27 July 2016 15:14:13 UTC+3, Carl Ranson wrote:
>
>
> HI all, 
>
> So I figured Conways game of life would be a good exercise to get my feet 
> wet with go. Specifically i wanted to make the calculation of the next 
> board state to be concurrent. 
> I started a separate goroutine for each cell and then used a pair of 
> channels to synchronize updating to the next state and displaying the 
> board. 
>
> Would love to hear opinions on this approach? are their better or more 
> effective ways to do the same thing?
>

Few unorganized thoughts:

First, when parallelizing things, always consider communication as part of 
the computation. Communication can have a significant overhead.

Usually, you should try to ensure that each goroutine does non-trivial 
amount of work.

e.g.

type Bitmap [32][32]bool // can be packed more compactly

type Block struct {
Active  *Bitmap // = &block.Buffers[0]
Next*Bitmap // = &block.Buffers[1], after each computation swap 
Active and Next
Buffers [2]Bitmap
}
type Field struct {
Blocks []Block
}

// Alternatively use two fields instead of swapping at block level...

And each goroutine computes some number of the blocks...

http://www.shodor.org/media/content/petascale/materials/UPModules/GameOfLife/Life_Module_Document_pdf.pdf

Try to avoid pointers in a tight loop. Following a pointer is not free.

This can be simplified:
if c.nw.currentState {
i++
}
with
i += count(c.nw) // define count somewhere

Also take a look at https://golang.org/doc/play/life.go

Of course then there's HashLife, and other that can improve it further.


> Thanks in advance,
> CR
>
>
> package main
>
> import (
> "fmt"
> "math/rand"
> "time"
> )
>
> type Cell struct {
> xint
> yint
> currentState bool
> nw   *Cell
> n*Cell
> ne   *Cell
> e*Cell
> se   *Cell
> s*Cell
> sw   *Cell
> w*Cell
> }
>
> func (c *Cell) cell(runChan chan string, doneChan chan string) {
> for {
> // wait until we're allowed to proceed
> _ = <-runChan
>
> // count the number of neighbours
> var i int = 0
> if c.nw.currentState {
> i++
> }
> if c.n.currentState {
> i++
> }
> if c.ne.currentState {
> i++
> }
> if c.e.currentState {
> i++
> }
> if c.se.currentState {
> i++
> }
> if c.s.currentState {
> i++
> }
> if c.sw.currentState {
> i++
> }
> if c.w.currentState {
> i++
> }
>
> //  Any live cell with fewer than two live neighbours dies, as if 
> caused by under-population.
> //  Any live cell with two or three live neighbours lives on to 
> the next generation.
> //  Any live cell with more than three live neighbours dies, as 
> if by over-population.
> //  Any dead cell with exactly three live neighbours becomes a 
> live cell, as if by reproduction.
>
> nextState := c.currentState
> if c.currentState == true {
> if i < 2 {
> nextState = false
> } else if i == 2 {
> nextState = true
> } else if i == 3 {
> nextState = true
> } else if i > 3 {
> nextState = false
> }
> } else {
> if i == 3 {
> nextState = true
> }
> }
>
> //fmt.Println("calc for ", c.x, c.y, c.currentState, nextState, i)
>
> // report that we're finished the calc
> doneChan <- "done"
>
> // wait for permission to continue
> _ = <-runChan
> c.currentState = nextState
>
> // report that we've done the transition
> doneChan <- "done"
>
> //fmt.Println("assign")
> }
> }
>
> func ring(x int, size int) int {
> // this corrects x to be in the range 0..size-1
> if x < 0 {
> return size + x
> } else if x >= size {
> return 0
> } else {
> return x
> }
> }
>
> func main() {
> const iterations = 10
> const gridSize = 50
> const numCells = gridSize * gridSize
>
> r := rand.New(rand.NewSource(123))
> var cells [numCells]Cell
>
> // set up the cells
> for y := 0; y < gridSize; y++ {
> for x := 0; x < gridSize; x++ {
> cells[x+gridSize*y].x = x
> cells[x+gridSize*y].y = y
> cells[x*gridSize+y].currentState = r.Intn(4) == 0
>
> cells[x+gridSize*y].nw = &cells[ring(x-1, gridSize)+gridSize*
> ring(y-1, gridSize)]
> cells[x+gridSize*y].n = &cells[ring(x, gridSize)+gridSize*ring
> (y-1, gridSize)]
> cells[x+gridSize*y].ne = &cells[ring(x+1, gridSize)+gridSize

[go-nuts] Re: first program, game of life in go

[Egon]

On Thursday, 28 July 2016 03:40:39 UTC+3, Carl Ranson wrote:
>
> Thanks Egon, 
>
> Ok, I take your point that one needs to strike a balance with the work 
> done in each goroutine to achieve optimum performance. 
> i understand that each goroutine doing a subblock of the board using 
> bitmaps would be faster, but as a learning exercise i'm keeping it simple. 
> In fact I was pleasantly surprised by how simply the code came out once I 
> could think about each cell's calculation as a discrete process.
>
> one part of your answer I didn't understand was the bit about pointers. 
>
>> Try to avoid pointers in a tight loop. Following a pointer is not free.
>>
>> This can be simplified:
>> if c.nw.currentState {
>> i++
>> }
>> with
>> i += count(c.nw) // define count somewhere
>>
>
> what would the count function do that alleviates it from the need to 
> follow the pointer? Are you saying that testing the pointer for nil costs 
> less than dereferencing the pointer? even if true that doesn't help me here 
> as every cell always has 8 neighbors (its not dependent on the cell being 
> live or not)
>

Those were two separate points :)... I guess using bullet-points would have 
made it clearer.

One was just about pointer derefing, the other about the repetitive code.

PS: using an array could make it shorter as well, e.g. [8]*Cell
 

> one of the reasons I used pointers here was to avoid each goroutine from 
> fighting over access to the boards array. they only care about the adjacent 
> cells after all. 
>

> thanks,
> CR
>

-- 
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] compressing long list of short strings

[Egon]

On Thursday, 11 August 2016 02:24:49 UTC+3, Alex Flint wrote:
>
> There are around 2M strings, and their total size is ~6 GB, so an average 
> of 3k each.
>

What kind of data? How large is the alphabet? What is the distribution of 
letters? Examples would be good :)
 

>
> I actually looked briefly at Go's compress/flate to see whether something 
> like what you're describing is possible without writing my own compressor 
> but I couldn't see any obvious way to get at the underlying compressor 
> state. Or perhaps I'm looking in the wrong package - any pointers would be 
> appreciated.
>
> On Wed, Aug 10, 2016 at 3:42 PM Ian Lance Taylor  > wrote:
>
>> On Wed, Aug 10, 2016 at 3:27 PM, Alex Flint > > wrote:
>> >
>> > I have long list of short strings that I want to compress, but I want 
>> to be
>> > able to decompress an arbitrary string in the list at any time without
>> > decompressing the entire list.
>> >
>> > I know the list ahead of time and it doesn't matter how much 
>> preprocessing
>> > time is involved. It is also fine if there is some significant O(1) 
>> memory
>> > overhead at runtime.
>> >
>> > Any suggestions?
>>
>> You say the strings are "short": how short?  How many strings are
>> there?  How much total data in the uncompressed strings?
>>
>> What is your target for the total amount of memory used by the
>> compressed strings plus any data required to decompress them?
>>
>> One approach that comes to mind is building an optimized Huffman table
>> for the full set of strings, and compressing each one separately using
>> that table.  Then each string is represented by a bit offset into the
>> resulting bitstream, and each can be decompressed separately.  But you
>> would need storage at run time not only for the bitstream, but also
>> for the Huffman table.
>>
>> 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] Re: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[Egon]

On Tuesday, 13 September 2016 06:31:20 UTC+3, davidmi...@gmail.com wrote:
>
> I've spent many, many, many hours on this (measured in days, at this 
> point) and I'm convinced that Golang is missing a fundamental programming 
> capability, that of multidimensional associative arrays. Searching through 
> this forum's archives and other sites, I've found that I'm not the first 
> one to face this problem and no one who has posted about this has yet 
> received a decent response (at least, not one that I have found)! The best 
> responses consist either of maps that are, at most, two levels deep or maps 
> whose depth is known in advance and declared using something like 
> make(map[string]map[string]map[string]map[string]map[string]string) and 
> even in those cases, one cannot replace a map with just a string on any of 
> those levels. 
>

I know it's frustrating to convert one piece of software based on a set of 
idioms, to another language that uses other idioms. I can remember trying 
to convert some highly OO JavaScript code to Delphi -- oh it was a pain and 
in the end it looked terrible in Delphi.

I guess one point everyone is trying to get across is that "Go doesn't have 
a multidimensional array -- at least not a convenient one -- for a reason." 

Implicit structures significantly harm readability at the cost of 
convenience. I.e. it's probably fine for small code bases (i.e. below 
50KLOC and ~5 people), but the larger it gets the harder it is to verify 
that the structures are consistently used. This means that refactoring is 
more difficult. *(You can partly see TypeScript and Hack as trying to deal 
with the aftermath.)*

But, I should say -- I love JS objects -- they are super-convenient and 
nice to use... but I wouldn't use them in Go.

So, let's take a step back, 

and investigate how people would solve your problem in Go -- rather than 
figuring out, how to write PHP code in Go. Remember Go is not PHP, JS nor 
Haskell... hence the code you write in Go will look different than in any 
of those languages. Yes, the larger code structures will stay the same, but 
the details will vary. *Sure, the first conversion could be crude.*

Basically, what business problem are you trying to solve with 
multidimensional arrays? If you can show the PHP code you are trying to 
convert, it would be even better.

+ Egon

-- 
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: Static race detector?

[Egon]

On Tuesday, 13 September 2016 08:53:39 UTC+3, josvazg wrote:
>
> Why does Go does not have a static race detector? What are the 
> difficulties?
> (just pointing me to the right docs to read is fine)
>
> I was thinking in a naive high level way...
>  
> If Rust can do it, using its ownership model, Go could have a tool 
> checking the AST that analyzes variable scopes and checks globals, 
> variables passed to goroutines and to/from channels.
>
> If one such followed variable is found in any piece of code to be accessed 
> from more than 2 places and any access is a write, bam! flag that code with 
> an error.
>
> What is this not possible or too difficult? too many corner cases? not 
> enough supporting info in the code? (that could be build by the tool)
> Or maybe is a work in progress,? maybe 100% reliable escape analysis is 
> required beforehand?
>

One WIP http://www.doc.ic.ac.uk/~cn06/pub/2016/dingo/

It's mainly -- *someone has to put in the effort*.

AFAIR the main difficulty lies in buffered channels.

+ Egon

-- 
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: Static race detector?

[Egon]

On Tuesday, 13 September 2016 09:15:57 UTC+3, Egon wrote:
>
> On Tuesday, 13 September 2016 08:53:39 UTC+3, josvazg wrote:
>>
>> Why does Go does not have a static race detector? What are the 
>> difficulties?
>> (just pointing me to the right docs to read is fine)
>>
>> I was thinking in a naive high level way...
>>  
>> If Rust can do it, using its ownership model, Go could have a tool 
>> checking the AST that analyzes variable scopes and checks globals, 
>> variables passed to goroutines and to/from channels.
>>
>> If one such followed variable is found in any piece of code to be 
>> accessed from more than 2 places and any access is a write, bam! flag that 
>> code with an error.
>>
>> What is this not possible or too difficult? too many corner cases? not 
>> enough supporting info in the code? (that could be build by the tool)
>> Or maybe is a work in progress,? maybe 100% reliable escape analysis is 
>> required beforehand?
>>
>
> One WIP http://www.doc.ic.ac.uk/~cn06/pub/2016/dingo/
>
> It's mainly -- *someone has to put in the effort*.
>
> AFAIR the main difficulty lies in buffered channels.
>

Oh, forgot to mention -- it's not a race detector, but rather a deadlock 
detector -- but, I guess, the principles are similar.

-- 
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: Having difficulty testing this "cleanly"

[Egon]

counter := intr64(N)
release := make(chan struct{})

...
for i := 0; i < N; i ++ {
  h.Handle(func() {
  <-release
  atomic.AddInt64(&counter, -1)
  })
}
...

go func(){
time.Sleep(time.Millisecond) // so we would certainly hit h.Close, 
before we continue
for i := 0; i < N; i++ { release <- struct{}{}; 
time.Sleep(time.Millisecond) }
// alternatively use runtime.Gosched() instead of Sleep
}()

h.Close()

if atomic.LoadInt64(&counter) > 0 {
// fail
}

It's not completely fool-proof, but should work well enough in practice.

On Tuesday, 13 September 2016 21:56:08 UTC+3, Evan Digby wrote:
>
> Has anyone come across a good way, non-racy way to ensure that N tasks are 
> guaranteed to be completed after a function is called? Essentially I have a 
> “Close” function that must be guaranteed to block until all tasks are 
> finished. Achieving this was pretty simple: wrap each task in an RLock, and 
> then a Lock on close. 
>
> Example: https://play.golang.org/p/7lhBPUhkUE
>
> Now I want to write a solid test to guarantee Close will meet that 
> requirement of all tasks must finish first for posterity. In that example, 
> try commenting out the RLock/RUnlock on lines 25/26. You'll see that it no 
> longer outputs many, if any, lines. I'm trying to prevent that from 
> happening in the future by some cowboy refactor!
>

> All of the ways I can come up with involve Sleeping or launching more 
> tasks than I _think_ can be finished in time--obviously not good!
>
> I feel like I must be missing some obvious way to test this and I'll end 
> up feeling silly once someone replies with the solution. I'm okay with that!
>

-- 
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: Having difficulty testing this "cleanly"

[Egon]

On Tuesday, 13 September 2016 22:52:27 UTC+3, Evan Digby wrote:
>
> Hi Egon,
>
> This is essentially the strategy I'm taking; however, I am hoping to avoid 
> the "Sleep and Pray" method. Reliable in practice, but not guaranteed. Also 
> in a CI of thousands of tests, adding time arbitrarily can extend out the 
> time it takes to test quite a bit.
>
> That said, if a sleep is the only way, a sleep is the only way. I hope it 
> isn't!
>

You would need to modify the handler to make it work other ways.
Alternatively you need to write a code-rewriter for injecting code into the 
handler.

The only reliable concurrent software I've seen is one that is easy to 
understand, that is backed by a proof (either formal or informal).

I took a deeper look into the taskHandler code -- and it doesn't finish all 
the tasks before everything:

I.e. 

R1: Line 24 // go func is delayed for some reason
R2: Line 35 // close is called in main
R2: Line 36
R2: Line 37
R1: Line 25 // go func is started
R1: Line 28 // task is executed
R1: Line 26

ATM. too tired to implement a proper solution, will take a look at it 
tomorrow.

+ Egon


> Thanks!
>
> Evan
>
> On Tuesday, 13 September 2016 12:47:40 UTC-7, Egon wrote:
>>
>> counter := intr64(N)
>> release := make(chan struct{})
>>
>> ...
>> for i := 0; i < N; i ++ {
>>   h.Handle(func() {
>>   <-release
>>   atomic.AddInt64(&counter, -1)
>>   })
>> }
>> ...
>>
>> go func(){
>> time.Sleep(time.Millisecond) // so we would certainly hit h.Close, 
>> before we continue
>> for i := 0; i < N; i++ { release <- struct{}{}; 
>> time.Sleep(time.Millisecond) }
>> // alternatively use runtime.Gosched() instead of Sleep
>> }()
>>
>> h.Close()
>>
>> if atomic.LoadInt64(&counter) > 0 {
>> // fail
>> }
>>
>> It's not completely fool-proof, but should work well enough in practice.
>>
>> On Tuesday, 13 September 2016 21:56:08 UTC+3, Evan Digby wrote:
>>>
>>> Has anyone come across a good way, non-racy way to ensure that N tasks 
>>> are guaranteed to be completed after a function is called? Essentially I 
>>> have a “Close” function that must be guaranteed to block until all tasks 
>>> are finished. Achieving this was pretty simple: wrap each task in an RLock, 
>>> and then a Lock on close. 
>>>
>>> Example: https://play.golang.org/p/7lhBPUhkUE
>>>
>>> Now I want to write a solid test to guarantee Close will meet that 
>>> requirement of all tasks must finish first for posterity. In that example, 
>>> try commenting out the RLock/RUnlock on lines 25/26. You'll see that it no 
>>> longer outputs many, if any, lines. I'm trying to prevent that from 
>>> happening in the future by some cowboy refactor!
>>>
>>
>>> All of the ways I can come up with involve Sleeping or launching more 
>>> tasks than I _think_ can be finished in time--obviously not good!
>>>
>>> I feel like I must be missing some obvious way to test this and I'll end 
>>> up feeling silly once someone replies with the solution. I'm okay with that!
>>>
>>

-- 
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] Having difficulty testing this "cleanly"

[Egon]

On Tuesday, 13 September 2016 23:31:55 UTC+3, Evan Digby wrote:
>
> Hi John/Egon/Augusto,
>
> I should point out is that all we need to guarantee (barring abnormal 
> termination of course) is that once a task starts processing, it finishes. 
> Partially processed messages are bad, but http requests that don't result 
> in a message being processed at all are okay.
>
> We don't need to guarantee that the result of every Accept in the HTTP 
> server results in a processed message. We handle this on the OPS side by 
> ensuring we stop sending requests to that instance before terminating the 
> process. We just want to make sure, at that point, that the messages which 
> did make it to the handler are flushed.
>
> So the case where:
>
> h.Handle(...)  <-- gets past the closed channel check, calls go ..., butthe 
> goroutine doesn't execute yet.
> h.Close() <-- closes the close channel, Locks and Unlocks,returns.
> ...now the goroutine executes and acquires the read lock.
>
> We actually don't care if "Handle" completes in this example. We only care 
> if that our task handler starts processing a message that it completes the 
> processing.
>

How do you actually ensure that it completes processing without hooking 
into Server? I.e. that buffers and sockets get properly flushed?

Let's take a step back and what are the properties that you need -- 

I assume it's just graceful shutdown where all the pending ServeHTTP 
requests have been processed?

What should happen when the server crashes -- is it vital for those 
requests to be processed, once they have been accepted?

What should happen when one handler gets stuck in an infinite wait/loop?

Does the "Close" returning mean you exit main or does hpw does the process 
termination depend on it? Or is it just another goroutine that is 
terminating not the whole process?

+ Egon

-- 
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] Having difficulty testing this "cleanly"

[Egon]

On Wednesday, 14 September 2016 00:18:26 UTC+3, Evan Digby wrote:
>
> Hi Egon,
>
> My requirements are more simple than a graceful http shutdown. I simply 
> require that everything that enters the RLock completes to RUnlock. 
> Accepted requests, or even calls to servehttp can die without issue as long 
> as they haven't entered the processing in the RLock.
>

In that case https://play.golang.org/p/RiFEbQvytP. *Ps. Still tired, may 
contain bugs.*


> If the server crashes we have ways to deal with that, but it's a more 
> DevOps-y process. Recovering from logging, etc.,and should be an edge case 
> that I'm not worried about handling in code. 
>
> If the handler gets stuck in a loop, we will see that in our logging. I 
> don't want the server to die in that case. I want it to keep retrying (we 
> have exponential backoff) and informing us via structured logging of what's 
> going on. If it's an unanticipated loop/block, then there will be a manual 
> investigation into the server's state before we manually kill the process. 
> At that point it becomes similar to the last point, except easier because 
> we already know the state the message was in.
>
> In our use case we will always exit shortly after a close. It's safe to 
> assume the process will die after close returns.
>
> Thanks again,
>
> Evan
>
> On Tue, 13 Sep 2016 at 14:08 Egon > wrote:
>
>> On Tuesday, 13 September 2016 23:31:55 UTC+3, Evan Digby wrote:
>>>
>>> Hi John/Egon/Augusto,
>>>
>>> I should point out is that all we need to guarantee (barring abnormal 
>>> termination of course) is that once a task starts processing, it finishes. 
>>> Partially processed messages are bad, but http requests that don't result 
>>> in a message being processed at all are okay.
>>>
>>> We don't need to guarantee that the result of every Accept in the HTTP 
>>> server results in a processed message. We handle this on the OPS side by 
>>> ensuring we stop sending requests to that instance before terminating the 
>>> process. We just want to make sure, at that point, that the messages which 
>>> did make it to the handler are flushed.
>>>
>>> So the case where:
>>>
>>> h.Handle(...)  <-- gets past the closed channel check, calls go ..., butthe 
>>> goroutine doesn't execute yet.
>>> h.Close() <-- closes the close channel, Locks and Unlocks,returns.
>>> ...now the goroutine executes and acquires the read lock.
>>>
>>> We actually don't care if "Handle" completes in this example. We only 
>>> care if that our task handler starts processing a message that it completes 
>>> the processing.
>>>
>>
>> How do you actually ensure that it completes processing without hooking 
>> into Server? I.e. that buffers and sockets get properly flushed?
>>
>> Let's take a step back and what are the properties that you need -- 
>>
>> I assume it's just graceful shutdown where all the pending ServeHTTP 
>> requests have been processed?
>>
>> What should happen when the server crashes -- is it vital for those 
>> requests to be processed, once they have been accepted?
>>
>> What should happen when one handler gets stuck in an infinite wait/loop?
>>
>> Does the "Close" returning mean you exit main or does hpw does the 
>> process termination depend on it? Or is it just another goroutine that is 
>> terminating not the whole process?
>>
>> + Egon
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/jh-nvt9ukBg/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@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] Having difficulty testing this "cleanly"

[Egon]

On Wednesday, 14 September 2016 00:58:39 UTC+3, Evan Digby wrote:
>
> Hi Egon,
>
> Thanks for that. It seems to implement the same requirements as 
> implemented in my example, although I prefer my implementation as it 
> doesn't require a sleep/loop. 
>

I used sleep/loop because I probably was thinking about sleep too much at 
that time :D. It could have been done with a WaitGroup.

Anyways, coming back to the problem at hand... 
As I said there are two properties that a good concurrency primitive should 
have:

1. It should be easy to understand.
2. It should have a formal or an informal proof.

Tests are less useful, unless they are supported by the scheduler. If they 
are not, then you pretty much either end up with quite tests that don't 
cover the "hard stuff" -- e.g. the problem in your initial code.

Now you can write the tests that implement the program state-machine... 
crude version https://play.golang.org/p/wBTbA2bQTP ... then write your 
whole program in terms of Routine -- where each func is an "atomic" 
instruction... then write the Step function that it goes through all 
possible orderings... or alternatively use randomized testing and run 
through only N different orderings... Put as you can imagine it's pretty 
annoying. *(Just a top of the head idea.)*

Now there are "testing frameworks" that can help here as well... 
e.g. https://www.youtube.com/watch?v=zi0rHwfiX1Q ... 
There's https://golang.org/pkg/testing/quick/ that provides some support 
for it... i.e. you need to add an "Action" generator and a "State" 
primitive... and each call to Check does a random action and verifies 
whether "State" is in a consistent state. *(You may need to add an 
additional func "WouldWait" to do it.)*

For actually verifying/proving -- people involved with Raft have came up 
with easy-to-use framework, relatively speaking... http://verdi.uwplse.org/ 
... to say the least, proper verification requires significant effort.

Here's the simplest I was able to make the needed 
primitive https://play.golang.org/p/MkmarqPzr1 ... and instead of testing 
"Do" and "Finish" you test the rest of the interface -- they are 
deterministic -- and non-racy. (Using testing/quick here would be probably 
ideal.)

+ Egon


> The implementation I provided in the original email, with the exception of 
> the bug that Augusto pointed out, works as desired. The question was not 
> how to implement these requirements, but how to validate them with a test 
> cleanly. 
>
> Unfortunately it doesn't seem that I was clear in my original post since 
> most people are focusing on the implementation of the requirements.
>
> Thanks again for your effort in this--apologies for miscommunication the 
> original question.
>
> Evan 
>
>
> On Tue, 13 Sep 2016 at 14:48 Egon > wrote:
>
>>
>>
>> On Wednesday, 14 September 2016 00:18:26 UTC+3, Evan Digby wrote:
>>>
>>> Hi Egon,
>>>
>>> My requirements are more simple than a graceful http shutdown. I simply 
>>> require that everything that enters the RLock completes to RUnlock. 
>>> Accepted requests, or even calls to servehttp can die without issue as long 
>>> as they haven't entered the processing in the RLock.
>>>
>>
>> In that case https://play.golang.org/p/RiFEbQvytP. *Ps. Still tired, may 
>> contain bugs.*
>>
>>
>>> If the server crashes we have ways to deal with that, but it's a more 
>>> DevOps-y process. Recovering from logging, etc.,and should be an edge case 
>>> that I'm not worried about handling in code. 
>>>
>>> If the handler gets stuck in a loop, we will see that in our logging. I 
>>> don't want the server to die in that case. I want it to keep retrying (we 
>>> have exponential backoff) and informing us via structured logging of what's 
>>> going on. If it's an unanticipated loop/block, then there will be a manual 
>>> investigation into the server's state before we manually kill the process. 
>>> At that point it becomes similar to the last point, except easier because 
>>> we already know the state the message was in.
>>>
>>> In our use case we will always exit shortly after a close. It's safe to 
>>> assume the process will die after close returns.
>>>
>>> Thanks again,
>>>
>>> Evan
>>>
>>> On Tue, 13 Sep 2016 at 14:08 Egon  wrote:
>>>
>> On Tuesday, 13 September 2016 23:31:55 UTC+3, Evan Digby wrote:
>>>>>
>>>>> Hi John/Egon/Augusto,
>>>>>
>>>>> I should point out is that al

[go-nuts] Re: Base58check to decimal

[Egon]

Write a for loop :)

https://play.golang.org/p/OZvqcWEOIc

Also are you sure that the decimal number is correct... i.e. I got a 
different result and http://lenschulwitz.com/base58 gives the same result.

+ Egon

On Thursday, 15 September 2016 11:26:11 UTC+3, Nosferatu fist wrote:
>
> First Hello and thank you for any help you can give me .
>
> here I have traveled google but I have not found my happiness . I would 
> like to convert decimal number BASE58Check in my research but give nothing
>
> example:
> bitcoin address : 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN
> In decimal : 103754284494436883955695059393877833907143043
>
> Thank you in advance for your help.
>
>

-- 
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: looking for a hot reloader/producer package

[Egon]

On Monday, 3 October 2016 20:55:45 UTC+3, mhh...@gmail.com wrote:
>
> Hi,
>
> I m looking for a package which would call a producer when a fs event is 
> emitted. 
>

> Doing so i could reload templates everytime they changed without 
> restarting the app.
>

Based on complexity:

1. For templates, just reload from disk every time you render.

2. Use a cache, see whether the file is newer on disk -- if yes, reload... 
put a RW mutex around the table containing templates.

3. Walk the directory and filter by ext every 1s and see whether the 
largest modified date has changed... if yes, reload everything.

https://play.golang.org/p/fdGIvGGicz

To swap out the templates put a RW mutex around the templates instance and 
replace the whole thing.

4. Same as before, but track time for each file separately and for 
modifications -- gives you more information and works better when you 
checkout older code.

0. watch for changes and rebuild and restart the whole program: 
https://github.com/loov/watchrun ... most of the time I use this.

>
> I ve found this package https://github.com/gernest/hot 
> 
>
> But, its totally built to render templates, where as i know i ll add other 
> kind of resources to watch & reload.
>
> Also, i m a bit skeptic because it re-assigns a *template.Template pointer 
> from a go func, and consume it from another routine.
>
> See 
> https://github.com/gernest/hot/blob/master/hot.go#L88
> https://github.com/gernest/hot/blob/master/hot.go#L104
> https://github.com/gernest/hot/blob/master/hot.go#L162
>
> Is it safe to do so ???
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: looking for a hot reloader/producer package

[Egon]

On Tuesday, 4 October 2016 00:57:57 UTC+3, mhh...@gmail.com wrote:
>
> Hi,
>
> I ll sleep on your code to digest it again.
>
> Yet agree i should not have these shared Registry, 
> and that your tree walk is way simpler.
>
> I may have some disagreements about 0 and 1, but it does not worth 
> mentioning, its all very contextual.
>

Most of the time I end up using 0, because I usually want to auto-reload 
the code as well, not just the templates.

Now 1. is trivial to setup and the overhead for dev environment isn't a 
problem. Of course, if necessary at a future date -- you can migrate from 
that 1. to any of the more complex solution, when the need arises...

I agree that 2-4 are nicer solutions, but a lot of times, they are not 
worth the effort.

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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: looking for a hot reloader/producer package

[Egon]

On Tuesday, 4 October 2016 14:11:03 UTC+3, mhh...@gmail.com wrote:
>
> Hi!
>
> I m not sure to get why you say 2-4 is not worthy.
>
> Is it because it seems there is no generic implementation of such behavior 
> ? 
>

I've written 3-6 hot reloaders, and I've yet to stumble on a "great general 
purpose implementation".

Which leads to costly copy pastes.
>

Copy-Paste in itself is not costly... the cost comes when you need to 
change it.
 

> Or some side effects that may occur and which make it to difficult to 
> maintain to even attempt to write it ?
>

I don't know the kind of template render interface do I need until I have 
an actual working application... this means by doing upfront design I could 
end-up redoing lot of work... the 0,1 approach are close to zero cost in 
terms of effort... once I know how the design will fit together, I can 
replace that part with something better.

The complexity with rendering comes when you start to add the current user, 
server time, menus, redirections, backlinks etc... so when you don't have 
any of those, you won't know the "best design for that situation".
 

>
> I made a new version based on your pseudo code,
> https://gist.github.com/mh-cbon/9eb7701e57a8f37bb7e62647dc9726e8 
> <https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2Fmh-cbon%2F9eb7701e57a8f37bb7e62647dc9726e8&sa=D&sntz=1&usg=AFQjCNHWZyuT23O6FMT7DGofY29Yg2tT5A>
>
>
It's too complicated for my tastes.

Try this instead: https://play.golang.org/p/9r4EYNoUEH

PS: use gofmt
 

> I slightly changed it to well split checker / producer.
> i have in mind sometimes soon i ll want to load some data from a storage 
> which is not a FS.
>

Sure, but at that point you might also need to change some other design as 
well.
 

> I also added the notion of StrategyDeliverer, because there could be some 
> behaviors
> to modify when an existing result become temporary invalid.
>
> There is no more registry shared across goroutines, 
> the drawback is that for each result to be produced it needs to create N 
> chans, N goroutines, ect.
>
> I don t have enough experience to say how bad this could be,
> I m little worried by contentions or other side effects i m not yet aware 
> of 
> because of the previous.
>
> Its still a long way to go : )
>

The issue is that you are building a lot of base/framework without 
immediate benefit. Small incremental value enhancing changes will work 
better... *this of course does not mean that you don't do any planning.*

In the crudest sense -- it comes down to how much value can you produce in 
a given time...

I.e. does it really matter to the end-user that your development 
environment is inefficient? Probably not, so there's no clear *value* doing 
something more complicated... Of course, when the tool is something like 
gohugo.io then it is useful... but such feature shouldn't be the first step 
that you do, because there are more valuable things that you could be doing.

+ Egon

-- 
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: looking for a hot reloader/producer package

[Egon]

On Tuesday, 4 October 2016 16:23:05 UTC+3, mhh...@gmail.com wrote:
>
> On Tuesday, October 4, 2016 at 1:55:56 PM UTC+2, Egon wrote:
>>
>> On Tuesday, 4 October 2016 14:11:03 UTC+3, mhh...@gmail.com wrote:
>>>
>>> Hi!
>>>
>>> I m not sure to get why you say 2-4 is not worthy.
>>>
>>> Is it because it seems there is no generic implementation of such 
>>> behavior ? 
>>>
>>
>> I've written 3-6 hot reloaders, and I've yet to stumble on a "great 
>> general purpose implementation".
>>
>
> I m interested to know more about this, 
> if you d agree to share. I m sure it is valuable.
>

With varying quality:

category 0: (internally uses category 4)
https://github.com/loov/watchrun/
https://github.com/loov/watchrun/blob/master/watch/monitor.go

category 1:
https://github.com/loov/spaceshift/blob/master/main.go#L122
https://github.com/loov/timeclock/blob/master/main.go#L92

category 3:
https://github.com/raintreeinc/knowledgebase/blob/master/module/dita/module.go#L139

*batching buffer for fsnotify*
*https://github.com/spf13/hugo/blob/master/watcher/batcher.go*

category 4:
https://github.com/raintreeinc/livepkg
(handles JS/CSS reloading, but expects some conventions to be followed)

I had more, but dropped most of them in favor of using watchrun or category 
4. And probably some which I don't even remember.

I've also had some networking programs that watched changes on one computer 
and automatically rebuilt program, download to another computer and start.
 

> Besides that i want to put emphasis i did not mean to make you angry, 
> that really was not my intent at all, if that ever happened.
>

No worries... :D, I just tend to write directly and avoid all the "IMHO"-s 
because I think it harms text readability; which might come across as 
"agressive".

Generally, very happy to discuss things >^.^<
 

>
> I m not very interested into arguing about non technical concerns.
> Said differently, don t tell me how to behave, instead, 
>

The reasons I outlined weren't meant to tell how to behave, but rather 
where I see the value and what has been useful to me. Of course, I 
understand situations vary and therefore the "best solution" will also vary 
*(hence 
the several categories of possible solutions)*.
 

> participate, if you d like to, into producing correct/better algorithms. 
>

> This said, two quick notes,
>
> In my concern i do see the immediate benefits, 
> and while i agree the end user does not care, 
> my clients does.
>

Sure, then go ahead. :)


> Lastly, regarding the use of go fmt, for a non officially published source 
> code,
> I feel like my indentation is correct. And, yes, to me, two spaces is 
> tasty.
>

gofmt as usual:

*Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.*

 
I don't like all the decisions that gofmt did, but it helps others to read 
my code -- and after getting used to it (~2 week), I rarely notice the 
issues anymore. The convenience from automatic formatting after saving is 
much nicer than the "perfect style" -- and yes, I also use two spaces in 
some languages and in some four spaces... but automatically formatted to 
the language-s "standard formatter", if there is one... if there isn't a 
standard, I'll use the formatter that is easiest to setup.

*But, as usual, you are free to do with your source as you please. :)*


> The day I ll publish such source code, give it a name and a version, 
> so you may depend on it, 
> I ll setup a bump script to make sure it always happen, 
> so everyone s always happy.
> It will even do the test, vet, changelog etc...
>
> Anyways, 
> thanks again for your interest, sharing and proposals, 
> it s sincerely appreciated.
>

-- 
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: tidy way to write a repeat-until in golang

[Egon]

On Saturday, 8 October 2016 16:34:33 UTC+3, xiio...@gmail.com wrote:
>
> If you can stomach GOTO the code :
>
> i := a
>
> loop1: //stuff
>
> //..fmt.Println(i, a, b)
>
> //stuff
>
> if i != b {
>
> i = i + b - a
>
> goto loop1
>
> }
>
>  
> should compile to something fairly sane without the extra variables and 
> 'ifs'
>
> ..but it lacks local scope, and the indentation isn't helpful. It's not 
> good to read when there are multiple loops like a 3d array case.
>

In this code you could use empty blocks, e.g.:

{
i := 0
loop:
fmt.Println(i)
if i < 10 {
i++
goto loop
}
}

or:

  i := 0
{
loop:
fmt.Println(i)
if i < 10 {
i++
goto loop
}
}

or:

i := 0
loop:
{
fmt.Println(i)
if i < 10 {
i++
goto loop
}
}

-- 
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: Tooling experience feedback

[Egon]

On Tuesday, 18 October 2016 14:02:08 UTC-5, Zellyn wrote:
>
> I run go tests with something like this:
>
> while true; do go test ./foo/bar; fswatch -1 -r . > /dev/null; sleep 0.3; 
> done
>
>
> It would be nice if go test could do that itself. (The 0.3 second sleep is 
> to let the file-write that triggered the test complete.)
>

I've built a tool for myself based on Watch by Russ Cox (he showed it in 
this video http://research.swtch.com/acme)

Located at: https://github.com/loov/watchrun


*$ go get github.com/loov/watchrun*
*$ watchrun go test ./foo/bar*

Keeping it as a separate tool is much more flexible and useful... e.g.

*$ watchrun go build myapp ;; myapp*

Which would build the application and then start it. Or... chain it with 
code generation...

*$ watchrun go generate . ;; go build . ;; myapp*

etc... of course depending on your needs you may want some other features 
or an alternative implementation.

Zellyn
>
> On Tuesday, October 18, 2016 at 2:54:49 PM UTC-4, Jaana Burcu Dogan wrote:
>>
>> Hello gophers,
>>
>> I am going to spend some time on improving the not-documented or 
>> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
>> test. The work will consist of reorganizing manuals, proposing new 
>> subcommands or flags to support commonly used multi-step things and so on.
>>
>> To give you some concrete examples:
>>
>> I have been in cases where users cannot find the build flags because they 
>> are hidden. E.g.
>>
>> $ go test -help
>> test [build/test flags] [packages] [build/test flags & test binary 
>> flags]
>> ...
>>
>> requires you to know about where the build flags are. Some tools are 
>> invisible for the newcomers.
>>
>> The other example is about test coverage. It is so tedious that I need an 
>> alias.
>>
>> func gocover() {
>> go test -v -coverprofile=coverage.out && go tool cover 
>> -html=coverage.out
>> } 
>>
>> I want to learn more about your experience, aliases, etc to propose 
>> improvements and work on the most commonly suggested items. I also am 
>> planning to go through this mailing list, stack overflow and other channels 
>> to see the common complaints.
>>
>> Feel free to reply to this thread or write to me privately.
>>
>> Thanks,
>> JBD
>>
>

-- 
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: Suggestions to hide plaintext password in net/smtp

[Egon]

On Wednesday, 26 October 2016 16:02:37 UTC-7, vincen...@gmail.com wrote:
>
> Hi
>
> I am new to Go and I have a go program to send email   similar to 
> https://golang.org/pkg/net/smtp/#example_SendMail below:
>
>
>
> func main() {
> // Set up authentication information.
> auth := smtp.PlainAuth("", "us...@example.com ", "password", 
> "example.com") //<plaintext password here
>
> // Connect to the server, authenticate, set the sender and recipient,
> // and send the email all in one step.
> to := []string{"reci...@example.net "}
> msg := []byte("To: reci...@example.net \r\n" +
> "Subject: discount Gophers!\r\n" +
> "\r\n" +
> "This is the email body.\r\n")
> err := smtp.SendMail("mail.example.com:587", auth, "us...@example.com 
> ", to, msg)
> if err != nil {
> log.Fatal(err)
> }
> }
>
> this go  program runs on a little PC that could be shipped to users, and 
> the little PC would be beyond my control. I read through the Internet and 
> pretty much everyone  says it is bad idea to put plaintext password in 
> applications even in compiled binary. this link  
> http://manoharvanga.com/hackme/ "Deconstructing an ELF file" even 
> describe details on how to reverse engineering the binary and reveal the 
> password.
>
> so if storing plaintext password in compiled go binary is bad idea, is 
> there anyway to go around in my go net/smtp scenario ? I looked bcrypt but 
> not sure how to apply bcrypt in this situation, storing hashed password in 
> the program? any suggestions is welcome! thanks! 
>

tl;dr; there is no secure way to embed a password inside an executable.

It depends what do you want to keep protected or why do you need to hide 
the password in the first place? What is the purpose of the program?

If you just need to protect the email account, set up a server that accepts 
a https+POST request and sends the email. That computer would be under your 
control and you can store the password there.

+ Egon

-- 
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] Noob question: Pointers to interfaces

[Egon]

tl;dr; version don't write generic code -- write concrete code, but do 
automate the boilerplate stuff...

Now depending on the reasons why you want to use ECS there can be several 
solutions:

two easy solutions:

1. https://play.golang.org/p/Vv2yYpMitg
2. https://play.golang.org/p/RCImpkDWT2

*PS: always ask about the actual problem you are solving, then people can 
orient to the situation much faster.*

On Tuesday, 8 November 2016 06:27:08 UTC+2, Kaylen Wheeler wrote:
>
> Keep in mind: at this point, I'm only playing around with a Go 
> implementation.
>
> What I'm trying to do is implement an Entity-Component-System.  Each 
> entity consists of a collection of components, each of which may have a 
> different type.
>
> The first thing I'm trying to implement is an easy way to look up 
> components by their type and assign them to a variable that points to that 
> type.
>
> I want to avoid writing something like  foo := 
> e.GetComponent(reflect.TypeOf(&Foo{}))
>
> That seems unnecessarily verbose.
>
> I also want to avoid explicit type-casting for the same reason.
>
> On Monday, 7 November 2016 19:52:06 UTC-8, freeformz wrote:
>>
>> Based on that example, I'm even more confused about what you are trying 
>> to accomplish. 
>>
>> Can we take a step back and forget about the implementation of a solution 
>> and describe the problem you are working on?
>> On Mon, Nov 7, 2016 at 19:08 Kaylen Wheeler  wrote:
>>
>>> Here's what I have so far: https://play.golang.org/p/X2z7Yl9UPg
>>>
>>> I think it works for my purposes.  However, I'm confused about one 
>>> thing:  Why does reflect.Value.Set panic when passed a zero-value?
>>>
>>>
>>>
>>> On Monday, 7 November 2016 16:56:52 UTC-8, freeformz wrote:
>>>
 Then just use pointers (see lines 45+): 
 https://play.golang.org/p/vl47WDHOdN

 On Mon, Nov 7, 2016 at 4:50 PM Kaylen Wheeler  
 wrote:

> I want pointers because I want most components to be structs, and I 
> want the ability to modify the fields in those structs.
>
> On Monday, 7 November 2016 16:46:17 UTC-8, freeformz wrote:
>
>> Why do you want to use pointers?
>>
>> On Mon, Nov 7, 2016 at 4:42 PM Kaylen Wheeler  
>> wrote:
>>
> Thanks for the "basic pattern" example here.  There's one little 
>>> modification I'm wondering about.
>>>
>>> Can this line:
>>>
>>> rv.Elem().Set(m[rv.Type()])
>>>
>>> be changed to this?
>>>
>>> rv.Elem().Set(*&*m[rv.Type()])
>>>
>>> If so, how can we check that the input value is a pointer to a 
>>> pointer.
>>>
>>> Or alternatively, is it better that the values in m should be 
>>> pointers?
>>>
>>>
>>> On Monday, 7 November 2016 16:01:53 UTC-8, adon...@google.com wrote:

 On Monday, 7 November 2016 17:55:57 UTC-5, Kaylen Wheeler wrote:
>
> I'm trying to find a typesafe way to access a type-indexed map of 
> components.  This map can contain objects of any type, and the keys 
> are 
> reflect.Type.
>
> One strategy I thought may work would be to pass a pointer to a 
> pointer as an out-var.  Using reflection to determine the pointer's 
> type, 
> it could be populated with a corresponding value.
>
> For instance, if we did something like this:
>
> c := ComponentCollection{}
> c.addComponent(123) // Add an int component 
>
> var p : *int
> c.getComponent(&p)
>
>
> In this case, p would point to the int component of c.
>
> That's wht the 2 levels of indirection are necessary: it's an 
> out-var to a pointer.
>
> Does that make sense?
>

 Here's the basic pattern:

 var m = make(map[reflect.Type]reflect.Value)

 func addComponent(x interface{}) {
v := reflect.ValueOf(x)
m[v.Type(x)] = v
 }

 func getComponent(ptr interface{}) {
rv := reflect.ValueOf(ptr)
if rv.Kind() != reflect.Pointer {
 panic("not a pointer")
}
rv.Elem().Set(m[rv.Type()])
 }

>>> -- 
>>> 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...@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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
 -- 
>>> You received this messa

[go-nuts] Re: Where should interfaces live?

[Egon]

On Monday, 21 November 2016 17:30:21 UTC+2, Vorn Mom wrote:

> Sorry if it was asked before, but where should interfaces live?
>
>- In the package that contains an implementation of it.
>- In its own package.
>- or in the package that needs it.
>
> The quick answer here is "yes to all", but most commonly it should be in 
"the package that needs it".

The interface can be seen as an evolution of indirection:

*#1 - no interface*

type memorydb struct { people []*Person }
func (db *memorydb) PersonByName(name string) (*Person, error) { ... }

type Server struct {
db *memorydb
}

*#2 - private interface*, introduced to allow multiple db or to separate 
code more

type memorydb struct { ... }
...
type sqllitedb struct { ... }
...

type peopledb interface { PersonByName(name string) (*Person, error) }

type Server struct {
db peopledb
}

*#3 - public interface* - introduced to allow sub-packages access/see the 
same interface, this usually happens together with moving the 
memorydb/sqllitedb into a separate package. It can also be used to break 
dependency cycles.

...
type PeopleDB interface { PersonByName(name string) (*Person, error) }

type Server struct {
db PeopleDB
}

*#4 - common interface* - introduced to allow wide compatibility between 
things; you only end-up here when you are implementing a widely used 
package, e.g. "database/sql/driver.Driver", "io.Reader", "io.Writer", 
"context.Context".

Try to stop at the "smallest number" that solves your problem. Each step 
adds extra indirection and more artifacts, so making code harder to 
understand. Of course, you should keep in mind not to make each 
file/struct/package/interface too large, which also makes code harder to 
read. It's a balancing act . Most web applications will end up at #3... 
frameworks/libraries end up at #3 or #4. Anything else can vary from #1 - 
#4.

+ Egon

The standard library is not consistent.  For example:
>
>- io.Writer is defined in a package that also has an implementation, 
>io.PipeWriter.  
>- Encoding is all interfaces, defering implementation to sub-packages.
>- database/sql returns a DB struct on Open() instead of an interface.
>
> Because Go interfaces are decoupled from implementation, I think it should 
> be defined where it's needed.  So I like having my own interface for DB 
> that may only define a subset of what behaviors it provides.
>
> However, doesn't defining an interface that depends on other packages 
> decrease cohesion and leaks the abstraction?  For example,
>
> type interface DbQuery {
>   QueryRow(query string, args ...interface{}) *sql.Row
> }
>
> This interface depends on sql.Row.  This decreases cohesion because the 
> interface is now defined across packages?
>
> -Vorn
>
>
>

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[Egon]

I think you are missing the point of my comment.

I'm all for generics, but I also can survive without them without much of a 
problem. (I'm even 
maintaining 
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4 
to understand the problem better)

The issue I was trying to highlight was that you are proposing solutions to 
a problem, but other people don't know what your exact problem is. Hence my 
3 lines version are equivalent in their result and value, because the 
problem is missing.

Similarly, when we don't have a concrete problem we could over-engineer the 
generics or alternatively solve the wrong problems.

For example, when the solution you propose only solves 5% of the problems 
that generics needs to solve... or vice-versa... a generics solution 100x 
simpler would solve 99% of the cases... then what is the value of the 
proposed solution?

So, which of the 147 different generics approaches/implementations works 
better for Go and why? (I'm also counting the ones that aren't known yet :D)

When you would use a real-world example and problem, it would be possible 
to argue that one approach is better than the other... without one, this 
discussion doesn't lead to anywhere.

+ Egon

On Sunday, 4 June 2017 19:09:17 UTC+3, mhh...@gmail.com wrote:
>
> given the fact that actually everybody disagrees on that idea, 
> or even something similar according to some feedback.
>
> I want to put the question differently.
>
> My mean is to say that golang is a basis to build upon in general that is 
> better
> than other existing solutions.
>
> imho, golang is governed by its compatibility requirement,
> and, an extremely vertical approach,
> which blocks every possible update to the dogma: 
> is it go 1.0 compatible ?
>
> And because its vertical, is it to my taste ?
>
> The go 1.0 compatibility requirement makes everybody very happy.
>
> Still, I dont believe the language is considered as finalized by a 
> majority of users.
> Some will say it misses generics, some other (..) will try different 
> approach.
>
> Why should it be that much of frictions ?
>
> Why can t we evaluate a solution where multiple vision co exists ?
> Handle the change.
>
> Aint there existing case of such kind of symbiosis which benefits each 
> other on the long term ?
>
> A solution where the go 1.0 requirement is kept valuable, 
> and a new language target where this requirement has been removed.
> A transpiler to go 1.0 compatible code ? 
> So both can exist ?
>
> my 2 cents, 
> that close and negative answer i got,
> is not helpful nor inclusive,
> its like take or leave attitude,
>
> it d just be more inclusive to say that 
> it is ok to make a transpiler/or whatever it should be/ implementing your 
> idea, 
> check that resource for further implementation come back here for 
> questions.
>
> Other consideration, 
> the idea that golang 1.0 is used to build a different language target that 
> compiles back to go1.0, 
> looks cool.
>
> On Saturday, June 3, 2017 at 6:24:31 PM UTC+2, mhh...@gmail.com wrote:
>>
>> for the fun, with early return,
>>
>> https://play.golang.org/p/I9AORKOYQm
>>
>> On Saturday, June 3, 2017 at 12:34:15 PM UTC+2, mhh...@gmail.com wrote:
>>>
>>> > Generics enable more than just replacing loops. For example, they can 
>>> enable libraries of generic algorithms to be used with any type of array. 
>>> Here's an example:
>>>
>>> in my demonstration every type got this kind of method,
>>> the problem become how do you jump from Type A to type B.
>>> in []A to []B or A -> B
>>>
>>> indeed it works on the item level, no more on the collections.
>>>
>>> This question is solved in two ways,
>>> - interface definitions (not interface value)
>>> - static conversion, which always resumes to 
>>> func(in-type) out-type
>>>
>>> and some alternatives for convenience (producer/consumer)
>>> func (func(in-type) out-type
>>> func (in-type) func() out-type
>>> func (func(in-type) func() out-type
>>> // this is unfinished explanation it should include error management to 
>>> be handled more completely. see please previous conv() fn introduced 
>>> earlier to statically re decorate a func signature.
>>>
>>> So far the sum/reduce things operation,
>>> i left them as exercise to the stream declarer
>>> and did not consider them as core.
>>> Take become => filter (func(10 elements))
>>> Map is map
>>> Sort is All(fn sorter) []out
>>> Reduce is a map operation, preceded by a conv if 

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[Egon]

On Monday, 5 June 2017 06:59:46 UTC+3, utyug...@mail.com wrote:
>
>
>
> On Sunday, June 4, 2017 at 12:25:17 PM UTC-4, Egon wrote:
>>
>> I think you are missing the point of my comment.
>>
>> I'm all for generics, but I also can survive without them without much of 
>> a problem. (I'm even maintaining 
>> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4
>>  
>> to understand the problem better)
>>
>
> create a custom container type that I can use with any type out-of-the-box.
>
> for example: iset := make(Set[int],9); sset := make(Set[string],9); pset 
> := make(Set[Person]);
>
> right now, my solution is to rewrite the source with go generate calling a 
> tool i wrote which grew out from a great talk from robert griesemer. The 
> video: https://www.youtube.com/watch?v=vLxX3yZmw5Q
>
> This solution has nearly twice the performance increase over maps with 
> almost every type used so far. Now I could have just written the 500 lines 
> of code over and over again for every type needed until the end of time(or 
> copy and paste and edit until the end of time), or I could use empty 
> interfaces which throws type safety out the window, but I chose to write a 
> tool, and when go generate came to be I chose to use that tool like a 
> simple script executed within a '//go:generate go run..' tag.
>
>
> Over time golang(I do this now to annoy the zealots) provided the 
> tools(reflection, /go packages, go generate) that made creating custom 
> generic type safe containers easier. These things weren't always this easy, 
> and these things could be easier.
>
> And I am serious about create a custom container type that I can use with 
> any type out-of-the-box. Please indulge me, how would you solve this 
> problem. Provide a solution for a simple type-safe container type Set that 
> takes any type, with a simple api of 
> insert,remove,contain,union,difference,intersection, 
> complement,superset,subset.
>

I would use copy-paste. That action to specialize and clean-up API is 
pretty trivial, it might take me 3min (probably less), but it isn't a 
problem. I often spend more time on tweaking CSS or figuring out what the 
customer needs. Copy-pasteing code is annoying, but it's trivial low-effort 
work... so it's not a problem. *There of course are probably domains where 
this 3min might be a problem*. Then you might use a reflect/interface based 
solution and create a type-safe wrapper. Or use code-generation.

3min writing code, isn't a problem for me.

There's also a subtle problem here, I consider 
"insert,remove,contain,union,difference,intersection,complement,superset,subset"
 
API somewhat unclear... it loses domain knowledge and may provide more 
functions than strictyl necessary... this of course it depends on the 
context.

Also, where will this set be used? Set data-structures have a ton of 
different trade-offs. I really don't know how to write a really good 
general purpose Set. 
(see https://github.com/golang/go/wiki/HowToAsk#the-story-of-a-bad-question)

I've seen you provide solutions in the past, so I would like to see your 
> solution to this not-much-of-a-problem.
>
 
>
>>
>> The issue I was trying to highlight was that you are proposing solutions 
>> to a problem, but other people don't know what your exact problem is. Hence 
>> my 3 lines version are equivalent in their result and value, because the 
>> problem is missing.
>>
>> Similarly, when we don't have a concrete problem we could over-engineer 
>> the generics or alternatively solve the wrong problems.
>>
>> For example, when the solution you propose only solves 5% of the problems 
>> that generics needs to solve... or vice-versa... a generics solution 100x 
>> simpler would solve 99% of the cases... then what is the value of the 
>> proposed solution?
>>
>> So, which of the 147 different generics approaches/implementations works 
>> better for Go and why? (I'm also counting the ones that aren't known yet :D)
>>
>> When you would use a real-world example and problem, it would be possible 
>> to argue that one approach is better than the other... without one, this 
>> discussion doesn't lead to anywhere.
>>
>> + Egon
>>
>> On Sunday, 4 June 2017 19:09:17 UTC+3, mhh...@gmail.com wrote:
>>>
>>> given the fact that actually everybody disagrees on that idea, 
>>> or even something similar according to some feedback.
>>>
>>> I want to put the question differently.
>>>
>>> My mean is to say that golang is a basis to build upon in general that 
>>&g

[go-nuts] Re: Need some help on my basic "Backup size" calculator

[Egon]

See filepath.Walk (https://golang.org/pkg/path/filepath/#Walk)

If you wish to recurse with ioutil.ReadDir or File.Readdir 
(https://golang.org/pkg/os/#File.Readdir), you have to do it manually.

Nested structs -- it depends what you are doing.

I would simplify it to:

type Stat struct {
FileCount int64
DirCount  int64
Bytes int64
}

When I want to keep per directory, then I would use:

type Info struct {
Pathstring
Total   Stat
Current Stat
Dirs[]Info
}

type Stat struct {
FileCount int64
DirCount  int64
Bytes int64
}

Btw. have you done the Go tour? (https://tour.golang.org/moretypes/1)

On Monday, 5 June 2017 08:38:59 UTC+3, Giovanni Francesco wrote:
>
> Hi there,
>
> I'm very new to Golang, and quite honestly haven't coded in a long time so 
> bear with me if this is an very basic question.
>
> I'm trying to build a basic backup program, which will take a path 
> (string) and then calculate the total "backup size" of the entire backup 
> (and all the child folders, etc).
>
> I found out by starting to write the basics of the program that 
> ioutil.ReadDir does not recursively go deeper into child folders so the 
> code I will show you is only calculating the size for any files in the root 
> only.
>
> I already have an idea on how to fix it but I have a much deeper question: 
> would using nested structs be a good idea?
>
> I'm basically defining the program like so:
>
> type Backup struct {
> Files
> Directories
> byteSize int64
> humanSize string
> }
>
> type Directories struct {
> name string
> containsBytes float64
> constainsFiles int64
> }
>
> type Files struct {
> parent Directories
> name string
> byteSize int64
> humanSize string
> }
>
> Do I need to make "Directories" and "Files" be a slice / map or something 
> for my purposes? I am a little confused here and I don't know how I could 
> make my struct (which holds multiple values) be an array/slice, how would 
> that work?
>
> What if I wanted to "search" for a file or folder later on my program? 
>
> My code that works for top-level folder calculation: 
> https://gist.github.com/TheLinuxGuy/2dd8ed958d14c491bf86e2f5f3d4688d
>
> Thanks!
> Giovanni
>

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[Egon]

On Monday, 5 June 2017 12:30:33 UTC+3, mhh...@gmail.com wrote:
>
> just to add,
>
> https://www.youtube.com/watch?v=gHCtEjzZ-rY
>
> I could not agree more on the end,
> i could argue about some arguments ;)
>
> btw, is there a channel that gathers all talks about go ?
>

https://gophervids.appspot.com/

and for slides

https://talks.golang.org/
 

> https://www.youtube.com/channel/UCO3LEtymiLrgvpb59cNsb8A
> https://www.youtube.com/channel/UCSRhwaM00ay0fasnsw6EXKA
> https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw
> https://www.youtube.com/channel/UCx9QVEApa5BKLw9r8cnOFEA
> https://www.youtube.com/channel/UCz7KItbg3owOqMpB5IjI7sA ?
> https://www.youtube.com/channel/UCWbNJn6vUW5SMRdqtoOHK5g
>
> On Monday, June 5, 2017 at 11:00:45 AM UTC+2, mhh...@gmail.com wrote:
>>
>> as anyway the thread has completely derived,
>> its the right place to put about that.
>>
>> I recently read about stanford choosing to use JS over Java
>> for some its courses.
>>
>> https://www.theregister.co.uk/2017/04/24/stanford_tests_javascript_in_place_of_java/
>>
>> I can t understand.
>> If a beginner ask me which language he should learn,
>> i d say go,
>> i d say him, stay put, its unfortunately not easy to enter, but its gonna 
>> be a great learning place.
>>
>> I was an heavy user of javascript, 
>> i loved it for its stream api,
>> i hated it because of its stream api.
>>
>> I say its not a good language for beginners,
>> its apparent ease hides a much greater complexity,
>> and it does not teach the traditional programming science,
>> but it has those good things like 
>> its a local problem solver rather than a define all the world approach.
>>
>> Anyway, my point is to say that i see in this decision of the stanford 
>> university 
>> the proof that something has to happen.
>>
>> THey were teaching Java before, how it come they chosen JS over go ?
>>
>> On Wednesday, May 24, 2017 at 9:52:27 AM UTC+2, mhh...@gmail.com wrote:
>>>
>>> see the title, only for what s needed 
>>> Slice/Splice/Each/Map/First/Last/Reverse/Sort ect ect not len, for reason. 
>>> so interface system serves the userland by its definition of struct, and 
>>> the basic slice type provided by the language is fully operational, without 
>>> breaking, btw. i don t go further in evaluation, i leave that to the 
>>> reader, just trying to work decently.
>>>
>>

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[Egon]

On Monday, 5 June 2017 16:26:25 UTC+3, utyug...@mail.com wrote:
>
> I gave you a simple problem, don't over think it. A Set data structure 
> with a simple api that can work out-of-the-box - just as slices and maps 
> with the builtins. I kept the requirements minimal. I'd like to see your 
> solution.
>

As I've already mentioned, my current problem-free approach is not 
out-of-the-box solution. Maybe, you misunderstood what I meant by 
problem-free. I mean that this is something I don't care about when writing 
code and the workaround is trivial-low-effort work...

I didn't know what the set was intended for; so I wasn't able to add 
Universe -- or don't have a good idea how you would construct one in Go for 
infinite constrained type. Not sure what you meant by superset/subset; -- 
if that one set contains another set, then there would be more code similar 
to Add/Sub. If you meant a superset that returns all possible supersets, 
then it would need Universe.

By no means I would consider it a good set implementation / API, but since 
that wasn't one of the criteria.

<https://lh3.googleusercontent.com/-TnGw_r6sy5I/WTVi7v_BpsI/D4c/9ETmQWhe4uw9RDXbV8hb8xe7wwWu2yYxQCLcB/s1600/SetImplementation.gif>

I ran into 3/4 bugs while renaming types:
1. I forgot to save the file.
2. I forgot to remove the original set entry type.
3. I forgot what the original set api was
4. Confused a,b,c and x,y in the demo.

At the moment I had to specially write generic code for Set, because it 
seems in ~5 years I've never found it worthwhile to write one. I had a 
delta-encoded intset, sparse-set, different bitset implementations, but 
nothing else.

I know the video is not 3minutes long, the rest of 3-minutes I would have 
used for searching the general purpose set, if I had one.

*Depending on the situation the actual approach may vary..*

+ Egon

On Monday, June 5, 2017 at 12:52:47 AM UTC-4, Egon wrote:
>>
>>
>>
>> On Monday, 5 June 2017 06:59:46 UTC+3, utyug...@mail.com wrote:
>>>
>>>
>>>
>>> On Sunday, June 4, 2017 at 12:25:17 PM UTC-4, Egon wrote:
>>>>
>>>> I think you are missing the point of my comment.
>>>>
>>>> I'm all for generics, but I also can survive without them without much 
>>>> of a problem. (I'm even maintaining 
>>>> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4
>>>>  
>>>> to understand the problem better)
>>>>
>>>
>>> create a custom container type that I can use with any type 
>>> out-of-the-box.
>>>
>>> for example: iset := make(Set[int],9); sset := make(Set[string],9); pset 
>>> := make(Set[Person]);
>>>
>>> right now, my solution is to rewrite the source with go generate calling 
>>> a tool i wrote which grew out from a great talk from robert griesemer. The 
>>> video: https://www.youtube.com/watch?v=vLxX3yZmw5Q
>>>
>>> This solution has nearly twice the performance increase over maps with 
>>> almost every type used so far. Now I could have just written the 500 lines 
>>> of code over and over again for every type needed until the end of time(or 
>>> copy and paste and edit until the end of time), or I could use empty 
>>> interfaces which throws type safety out the window, but I chose to write a 
>>> tool, and when go generate came to be I chose to use that tool like a 
>>> simple script executed within a '//go:generate go run..' tag.
>>>
>>>
>>> Over time golang(I do this now to annoy the zealots) provided the 
>>> tools(reflection, /go packages, go generate) that made creating custom 
>>> generic type safe containers easier. These things weren't always this easy, 
>>> and these things could be easier.
>>>
>>> And I am serious about create a custom container type that I can use 
>>> with any type out-of-the-box. Please indulge me, how would you solve this 
>>> problem. Provide a solution for a simple type-safe container type Set that 
>>> takes any type, with a simple api of 
>>> insert,remove,contain,union,difference,intersection, 
>>> complement,superset,subset.
>>>
>>
>> I would use copy-paste. That action to specialize and clean-up API is 
>> pretty trivial, it might take me 3min (probably less), but it isn't a 
>> problem. I often spend more time on tweaking CSS or figuring out what the 
>> customer needs. Copy-pasteing code is annoying, but it's trivial low-effort 
>> work... so it's not a problem. *There of course are probably domains 
>> where this

[go-nuts] Re: Copy map with empty interfaces

[Egon]

On Monday, 5 June 2017 18:11:00 UTC+3, Chun Zhang wrote:
>
> Unfortunately it does not give any info. :(
>

Can you upload the code somewhere?

Other ideas:

1. set environment variable GODEBUG to cgocheck=2
2. try valgrind - maybe it picks something up (not sure how well it works)
3. try sanitizers - search `go build -msan`... I've never used it, but you 
can see some tests for it in 
https://github.com/golang/go/tree/master/misc/cgo/testsanitizers

Other than that, yeah... try to get the example as small as possible and so 
that you can show it.

+ Egon


> Thanks,
> Chun
>
> On Saturday, June 3, 2017 at 1:16:18 PM UTC-4, Egon wrote:
>>
>> Does race detector say something useful?
>>
>> On Friday, 2 June 2017 21:18:31 UTC+3, Chun Zhang wrote:
>>>
>>> I am trying to store some complicated data structure with a map, and 
>>> eventually search and use it. 
>>> Since the structure can change with different applications, and it has 
>>> to work with multiple thread, I defined a generic map like follows
>>>
>>> type IndexedMap struct {
>>> sync.RWMutex
>>> DataNode  map[interface{}]interface{}
>>> }
>>>
>>> Insert is defined as 
>>>
>>> func (m *IndexedMap) Insert(dataIndex interface{}, data interface{}) error {
>>>
>>>var err error
>>>
>>>m.Lock()
>>>
>>>//if the node exist
>>>if _, ok := m.DataNode[dataIndex]; ok {
>>>   m.Unlock()
>>>   return m.Update(dataIndex, data)
>>>} else {
>>>   //insert new node
>>>   m.DataNode[dataIndex] = data
>>>}
>>>
>>>m.Unlock()
>>>
>>>return err
>>> }
>>>
>>>
>>> ** For now, the data being inserted is a structure, not the pointer to 
>>> the structure and the key/index is a string.**
>>>
>>>
>>> Then when I need to find a piece of data, I tried to get a snapshot of 
>>> the database first and then look for it
>>>
>>> v, ok : = m.SnapShotData()[key] where
>>>
>>> func (m *IndexedMap) SnapShotData() map[interface{}]interface{} {
>>>
>>>ret := make(map[interface{}]interface{})
>>>
>>>m.Lock()
>>>for k, v := range m.DataNode {
>>>   ret[k] = v
>>>}
>>>m.Unlock()
>>>
>>>return ret
>>> }
>>>
>>>
>>> Then the data v is used to do other things, never modified though. 
>>>
>>> This works but the performance is abysmal when the database getting 
>>> large. So, I tried to search without copying 
>>>
>>> v, ok := m.DataSearch(key)
>>>
>>> func (m *IndexedMap) DataSearch(dataIndex interface{}) (interface{}, bool) {
>>>
>>>var data interface{}
>>>var ok bool
>>>
>>>m.Lock()
>>>
>>>data, ok = m.DataNode[dataIndex]
>>>
>>>m.Unlock()
>>>
>>>return data, ok
>>> }
>>>
>>>
>>>
>>> However, with this implementation, I always get crash after running the 
>>> program just a little bit with the following error
>>>
>>> *** Error in `./colordecoder': double free or corruption (fasttop): 
>>> 0x7f943c26f590 ***
>>> SIGABRT: abort
>>> PC=0x7f946c2eac37 m=4
>>> signal arrived during cgo execution
>>>
>>> I guess somewhere along the line the copy is a not a hard copy but just 
>>> a reference copy. However, I couldn't understand the difference between 
>>> above two approaches, seems that in SnapShotData I did exactly the same 
>>> thing, but no crash ever. 
>>>
>>> Can somebody tell me where I did wrong? 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: How fast can gopacket handles?

[Egon]

The usual 
1. do less work,
2. don't make copies,
3. produce less garbage.

e.g. 
1./2. maybe you can avoid parsing the whole data and just extract the 
necessary bits directly.
2./3. maybe you can create a pool of packets so that the internal 
structures for them can be reused

Essentially try to exactly understand why the parsing takes that much time. 
Write a benchmark that stresses that point of the code. Optimize it.

This might also require improving gopacket itself.

On Friday, 9 June 2017 17:47:46 UTC+3, Chun Zhang wrote:
>
> Hi, All, 
>
> Update on this issue. Based on the suggestion I got earlier, I dedicated 
> one thread, which is locked to a os thread to handle packet receiving, this 
> thread then put the received packet on a buffered channel/queue. Without 
> doing any extra work, this thread is able to take packets up to 
> 800Mbps-ish, which is the limit of the sender. 
>
> 12 goroutines are then kicked off to take items from this queue and 
> distribute them to other work queues for further processing. The 
> distributing thread parses the packet to a gopacket.Packet interface and 
> hashes based on the ip address etc. Even though I have used the faster 
> version, the parse routine takes a LOT of the cpu power.  By profiling the 
> program, it seems the parsing takes 1/3 of whole time. The whole app is 
> then limited to roughly 120Mbps, aka, 50kpps. 
>
> The decoding routine I am using is pretty much like the example here
> Decoding Packets Faster
>
> http://www.devdungeon.com/content/packet-capture-injection-and-analysis-gopacket
>  
> <http://www.google.com/url?q=http%3A%2F%2Fwww.devdungeon.com%2Fcontent%2Fpacket-capture-injection-and-analysis-gopacket&sa=D&sntz=1&usg=AFQjCNEjTqyKHKawVSYxS7UeC0PQ-NRTQw>
>
> I am wondering what further optimization can I do to speed this up?
>
> Thanks,
> Chun
>
>
>
>
>
> On Tuesday, May 30, 2017 at 10:50:50 AM UTC-4, Chun Zhang wrote:
>>
>> Thank you Rajanikanth, Kevin and Egon! I will explore the ideas you guys 
>> provided and keep you updated. 
>>
>> Best Regards, 
>> Chun
>>
>> On Sunday, May 28, 2017 at 2:25:03 AM UTC-4, Egon wrote:
>>>
>>>
>>>
>>> On Saturday, 27 May 2017 14:05:11 UTC+3, Chun Zhang wrote:
>>>>
>>>> Thanks Kevin and Egon!
>>>>
>>>> With a few experiments, I found that the logging, even to a file, is 
>>>> quite time consuming, so turning off logging helps, resulting in 
>>>> 500Mbps-ish no drop rate; however, still not even close to Gbps. 
>>>>
>>>> Then I turned on both lazy and nocopy option in the decoding option, 
>>>> the lazy options seems to help. I got something close to 700Mbps, where 
>>>> the 
>>>> sender's limit is reached. 
>>>>
>>>> Given that said, the program does not nothing but receiving the packet 
>>>> at this moment. Any actual processing of the packet in the same thread 
>>>> significantly hurt the rate. Besides spinning multiple thread to handle 
>>>> the 
>>>> actual work, anything else in the gopacket land that can be done?
>>>>
>>>
>>> Profile your code. :)
>>>  
>>>
>>>>
>>>> Thanks again! 
>>>> Chun
>>>>
>>>>
>>>>
>>>> On Saturday, May 27, 2017 at 5:24:13 AM UTC-4, Kevin Conway wrote:
>>>>>
>>>>> > can only handle up to 250Mbps-ish traffic
>>>>>
>>>>> I'm not familiar with gopacket, but I have seen multiple occasions 
>>>>> where logging to a file or stdout became a bottleneck. Your code snippet 
>>>>> is 
>>>>> logging on every packet which seems excessive. Try logging with less 
>>>>> frequency and, if using stdout, consider using a log destination with 
>>>>> different buffering characteristics like a file or syslog over UDP. 
>>>>>
>>>>> On Fri, May 26, 2017 at 3:59 PM Egon  wrote:
>>>>>
>>>>>> On Friday, 26 May 2017 20:51:55 UTC+3, Chun Zhang wrote:
>>>>>>>
>>>>>>> Good point.  
>>>>>>> as a comparison: tcpdump -w /dev/null can handle up to 750Mbps, 
>>>>>>> where sending machine's  speed limit reached. I think it should be able 
>>>>>>> to 
>>>>>>> handle line rate.
>>>>>>>
>>>>>>> Are those two packages lighter/faster than gopacket?
>>>>>>>
>>>>>

[go-nuts] Re: RFC: Blog post: How to not use an HTTP router

[Egon]

On Monday, 19 June 2017 01:02:37 UTC+3, Axel Wagner wrote:
>
> Hey gophers,
>
> in an attempt to rein in the HTTP router epidemic, I tried writing down a) 
> why I think *any* router/muxer might not be a good thing to use (much 
> less write) and b) what I consider good, practical advice on how to route 
> requests instead. It's not rocket science or especially novel, but I wanted 
> to provide more useful advice than just saying "just use net/http" and 
> haven't seen that a lot previously.
>
> Feedback is welcome :)
> http://blog.merovius.de/2017/06/18/how-not-to-use-an-http-router.html
>

I've also used this approach for very simple endpoints:

func ServeHTTP(w http.ResponseWriter, r *http.Request) {
type rr struct{ method, path string } // rr = "resource request"
switch (rr{r.Method, r.URL.Path}) {
default:
http.Error(w, "Invalid request.", http.StatusBadRequest)
retun
case rr{http.MethodGet, "/"}:
// handle index
case rr{http.MethodGet, "/favicon.ico"}:
// serve icon
case rr{http.MethodGet, "/list"}:
// serve list
case rr{http.MethodPost, "/save"}:
// ..
}
}

Of course this can be combined with getting the ShiftPath and other things, 
when necessary.

+ Egon

-- 
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: Structuring a Go Application based on domain areas

[Egon]

Implement a static-analysis that checks such constraints.

---

For example in file `customer/address.go`

package customer

// category: model
type Address struct {
User user.ID
}

func (address *Address) Update(controller *Controller) { ... }

// alternatively:
var _ = architecture.Model(&Address{})

...

The static analysis tool would parse the "category" or some function that 
registers a type.

By parsing the source AST or alternatively walking the structure with 
reflection you can derive all the dependencies, e.g.
*> model customer.Address* depends on *model user.ID* and *controller *
*customer.**Controller*

Based on this we can see a violation:
*> model *either directly or indirectly depends on a *controller.*

--

That way you can do pretty extensive tests and checks, whatever you deem 
appropriate for your micro-architecture.

Creating separate packages for internal/outer models reduces cohesion... 
controller, view, model (and different layers) work quite tightly together, 
hence they should be close to each.

Also, recommend reading wrt. MVC:

https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
http://wiki.c2.com/?ModelViewControllerHistory

+ Egon


On Thursday, 6 July 2017 05:06:23 UTC+3, Frederik Creemers wrote:
>
> I've already asked this question on softwareengineering.stackexchange.com 
> <https://softwareengineering.stackexchange.com/questions/352099/how-to-structure-a-go-application-architected-according-to-the-clean-architectu>,
>  
> so if you want some reputation points for being helpful, you can answer it 
> there. But in this thread, I'll make my question a little bit more general. 
>
> I recently watched a talk by Robert C Martin (Uncle Bob) 
> <https://youtu.be/WpkDN78P884?t=7m8s> where part of the presentation was 
> on how the directory structure of a project should reflect its intent, not 
> its architecture or framework (link goes directly to the relevant timestamp 
> in the video). So for example, the standard layout of a Ruby on Rails app 
> (with app, db, models folders), makes it clear that you're looking at a 
> rails app, but not what that app actually does. Similarly, if your app has 
> a folder for models, views and controllers,, that makes it clear you're 
> building an app using the MVC architecture, but doesn't describe what it 
> does.
>
> So to apply this to a Go application for a store, you'd have a "customers" 
> package, a "products" package, an "orders" package and so on. So then the 
> question becomes, how do we structure content within these packages? Let's 
> say we're building our project using the MVC architecture. Then each of our 
> domain-specific packages could contain a models.go, controllers.go and 
> views.go. But then we run into another problem.
>
> In an MVC application, the controller should depend on the models and 
> views, but the views shouldn't depend upon the models and vice versa. 
> Import paths make this incredibly visible. If you're in a views package, 
> and you  see an import from a models package, you know there's something 
> wrong. In Go, files within a package share a namespace, so while you could 
> inspect the code in views.go to make sure it's not using anything from 
> controllers.go, it's a lot less visible.
>
> The option i ended up going for, was to make sub-packages within each 
> domain package. While this works, you soetimes end up having to rename 
> imports because you're relying on models from two domain areas, so you end 
> up doing
>
> import (
> ordermodels "github.com/username/project/orders/models"
> customermodels "github.com/username/project/customers/models"
> )
>
>
> So is there a better way to achieve both a domain-specific set of 
> top-level packages, and clear dependencies between architecture-specific 
> layers?
>
> As you'll see if you read the StackOverflow question, I'm not actually 
> using the MVC architecture, but I think this question applies to any 
> architecture, and MVC is the most widely-used, so I thought it might make 
> my question easier to understand. This question could apply to any 
> architecture where knowing the dependencies between "layers" is important. 
>

> Best regards,
> Frederik
>

-- 
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: Programming paradigm.

[Egon]

I suggest reading: 
https://medium.com/@egonelbre/paradigm-is-not-the-implementation-af4c1489c073

+ Egon

On Sunday, 16 July 2017 20:42:34 UTC-7, Mayank Acharya wrote:
>
> Dear all,
> I am new to Go language.
>
> I searched a lot to understand it's paradigm structure but still not 
> getting clear idea about that.
>
> Please if anyone can explain, go language follows which programming 
> paradigm with some clear example for understanding.
>
> I really appreciate responses.
>
> Thank you.
>

-- 
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: [Bug Report] Cannot run GO in Windows Server 2016

[Egon]

Have you tried go1.9beta2? Maybe it's already fixed?

https://golang.org/dl/#unstable

If not then make a bug report to: https://github.com/golang/go/issues

+ Egon

On Monday, 17 July 2017 06:27:38 UTC-7, yanfeizh...@gmail.com wrote:
>
> [Issue]
> When running go, a problem is encountered
> 
> C:\Users\Administrator>go
> Exception 0xc005 0x8 0x0 0x0
> PC=0x0
>
> runtime.asmstdcall(0x8fdd8, 0x40ee8d, 0x10f4000, 0x0, 0x10044f980, 
> 0x20, 0x11, 0x10f4000, 0x44f8c0, 0x10f, ...)
> c:/go/src/runtime/sys_windows_amd64.s:60 +0x5e fp=0x8fd80 
> sp=0x8fd70
> rax 0x0
> rbx 0xa992c0
> rcx 0xab4e20
> rdi 0x204000
> rsi 0x8fea0
> rbp 0x8fe68
> rsp 0x8fd68
> r8  0x42e36e
> r9  0x8fee0
> r10 0xc04200
> r11 0x
> r12 0x0
> r13 0xffee
> r14 0x0
> r15 0x0
> rip 0x0
> rflags  0x10293
> cs  0x33
> fs  0x53
> gs  0x2b
> 
>
> [Environment]
>
> Version:
> Go 1.8.3 From go1.8.3.windows-amd64.msi (newest)
>
> OS:
> Microsoft Windows Server 2016 Datacenter
>
> Hardware:
> ASUSTek COMPUTER INC. Z10PA-D8 Series
> Intel(R) Xeon(R) CPU E5-2620 v4 @2.10GHz, Intel(R) Xeon(R) CPU E5-2620 v4 
> @2.10GHz
> 128GB RAM
> 512GB SSD + 2TB HHD + 6TB HHD
>

-- 
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: Code Review - Applying functions on custom types

[Egon]

In a uniform column situation I would model a single Column, effectively 
have:

type StringColumn struct{ Cells []string }
type FloatColumn struct{ Cells []int }

This should also make many of the operations easier to implement.

But since I'm unclear what the end goal of this solution is, I'm not sure 
whether this is sufficient or whether there are better designs.

+ Egon

On Wednesday, 19 July 2017 13:48:07 UTC-7, Sofiane Cherchalli wrote:
>
> Hi!
>
> I'm a noob in Go and I need some guidance/help on this: 
> https://play.golang.org/p/0TGzKiYQZn
>
> Basically I'm implementing a CSV parser, and applying transformations on 
> column value.
>
> In last part of the code I'm trying to apply a function on CSVFloat type 
> which satisfies Valuer interface, but I got a compiler error.
>
> In Scala language, this could be done by using map function, but how to do 
> it in Golang?
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Bitwise operators applications

[Egon]

Generally when you ask that question you probably won't need to use them.

The main reasons you would use them:

1. bitflags -- allows to easily specify a set of 8 to 64 elements easily 
(https://play.golang.org/p/DZj9FerK19)
2. fast ways to compute something -- see 
https://graphics.stanford.edu/~seander/bithacks.html, 
http://aggregate.org/MAGIC/
3. packing -- e.g. when you have seven 3 bit numbers then you can fit 21 of 
them into a 64bit number; to pack and extract you would need to use bit 
operations; similarly many packing algorithms use them for that reasons
4. bit parallel operations - when you have several packed numbers you can 
do some operations in bit parallel, e.g. you could add together 16 3bit 
numbers together in two computer cycles using a 64bit number.
5. There are also some algorithms that exploit bit operations, e.g. 
shift-or search http://www-igm.univ-mlv.fr/~lecroq/string/node6.html

+ Egon

On Saturday, 22 July 2017 20:36:14 UTC-7, Alexey Dvoretskiy wrote:
>
> Hello golang-nuts.
>
> I'm new to Go language and have no solid experience with C/C++. 
> I was a database programmer with some Python and I was able to get around 
> without bitwise operators easily.
> Of course, I ran into tons of issues with performance, deployment and 
> other stuff. That is why I switched to Go.
>
> The question is what are practical applications of bitwise operations in 
> Go and when I should use/learn them?
>
> Thanks
> Alex
>

-- 
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: Proposal: Blank types instead of Generics for Go 2

[Egon]

On Sunday, 23 July 2017 01:17:04 UTC-7, meta keule wrote:
>
>
> Hi,
>
> here is a proposal for an alternative to Generics for Go2:
>
> https://github.com/golang/go/issues/21132
>
> Please discuss!
>

1. Please see https://blog.golang.org/toward-go2 
2. You didn't mention all the cons your proposed methods has
3. You didn't mention prior art of golang proposals, i.e. how it fixes the 
problems in them.
4. You are missing demonstrations of what problems exactly you are 
targeting with this proposal.

+ Egon

-- 
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: GO Vs D

[Egon]

On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com wrote:
>
> For all the common parts with Go (functions, methods, reference classes, 
> strings, arrays, slices, ranges, foreach, etc), honestly I don't know why 
> you say it's simpler in Go.
>
> Can you show me two examples of code side by side, and tell me "look how 
> much simpler it's with Go's" ?
>
> Because from what I read, I'm sometimes wondering if you really know that 
> the type declarations in D are MUCH simpler than in C/C++.
>

error* (**callbacks)(int);

Error[] function(int)[][string] callbacks;

var callbacks map[string]func(int) []error


> For instance :
>
> int[]
> first_array_of_ints,
> second_array_of_ints;
>
> int[string]
> first_map_of_ints_indexed_by_a_string,
> second_map_of_ints_indexed_by_a_string;
>
> TYPE
> first_reference_to_an_object_of_this_type,
> second_reference_to_an_object_of_this_type;
>
> So, with all due respect, how many applications have you already 
> programmed in D before telling me that Go's syntax is so simpler to use and 
> to learn ?
>
> I agree there are much *less* possibilities in Go, but that doesn't mean 
> it's automatically a simpler language to learn for all the common parts 
> with D. Seriously.
>
> Because I had to learn both, and at least for a C++/Java/C# programmer 
> like me, D transition was almost immediate, really a matter of hours to 
> become comfortable with the language. Everything was alike, but much 
> simpler and easier than in C++.
>
> Believe me or not, I've taught programming with D to my two teenagers with 
> D. Really.
>
> I've chosen it because it was the only strongly-typed language close to 
> Javascript that was really easy to learn, while allowing them to quickly 
> switch to C++, Java or C# later if they wanted to.
>
> Go is much simpler than C++ too, I agree of course, but for having learned 
> both Go then D, again from the point of view of a former C++/Java/C# 
> programmer like me, I didn't feel that quickly at home with Go than with D, 
> mainly because Go diverged much more from its predecessors than D from a 
> syntactic point of view.
>
> So, again from a syntactic point of view, I don't think how you can affirm 
> that it's much easier in Go than in D to declare and use types, references, 
> functions, methods, slices, arrays, foreach, and all the common stuff 
> between both languages.
>
> Honestly, no offense intended.
>
> On Tuesday, August 1, 2017 at 10:11:10 PM UTC+1, Doğan Kurt wrote:
>>
>> But from my personal experience, D is *at least* as easy to learn than 
>>> Go, if not easier.
>>
>>
>> I seriously doubt, no offense. Go is so small and so intuitive, one can 
>> argue that there are people out there who knows most of the Go unknowingly 
>> :) 
>>
>> Just the fact that it doesn't break much with the familiar syntax of C#, 
>>> Java, C++, etc helps a lot in making the transition.
>>>
>>
>> Go's syntax is very familiar to C, i've never heard it was an issue. The 
>> only think you must get used to is declarations and i LOVE the Go way. I 
>> remember the days i was struggling with C's declaration model, the spiral 
>> rule etc. sure we use typedefs but it rather feels like a hack. 
>> I can write any declaration no matter how complex it is, with my eyes 
>> closed in Go. It's so great.
>>
>> And genericity and polymorphism are invaluable tools when optimizing code 
>>> reuse without reducing execution speed.
>>>
>>
>> I don't ever remember duplicating any code in C. I can't understand how 
>> people are unable to write reusable code with C, seriously.  Whenever i 
>> discuss this with a C++ programmer, they immediately share some generic Max 
>> function that works with int and double.  I admit i use macros in that 
>> case, but come on it's not even 1% of the serious programming you do in C. 
>>
>> If you are a competent C programmer (structured programming in general), 
>> you know how to write reusable code. 
>>
>

-- 
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: GO Vs D

[Egon]

The example contained 3 versions, C, D and Go.

function pointer tables aren't that uncommon, maybe the []error part is 
uncommon

Examples from real world code:

https://github.com/egonelbre/fedwiki/blob/master/action.go#L59
https://github.com/ethereum/go-ethereum/blob/master/crypto/sha3/sha3_test.go#L40
https://github.com/jteeuwen/go-bindata/blob/master/testdata/out/compress-memcopy.go#L205
https://github.com/golang/net/blob/master/proxy/proxy.go#L57
https://github.com/golang/go/blob/master/src/cmd/vet/main.go#L150
https://github.com/golang/go/blob/master/src/net/http/server.go#L2391
https://github.com/golang/go/blob/master/src/cmd/compile/main.go#L23

And I've used it in Go, Java, C#, JavaScript, Delphi, C...

The main reason you don't see these one-liners often in C, D et. al. is 
because they are hard to read.

For common C, C++ examples, see signal and interrupt vector tables.

On Wednesday, 2 August 2017 12:05:43 UTC+3, ecstati...@gmail.com wrote:
>
> Still waiting the Go version of this very useful D code...
>
> I'm not asking you to browse the web to find to find most complex 
> declaration you can ever do in D, Go or C++ for instance.
>
> I've never used such ridiculous code in my Go/D/C++/Java/C# applications, 
> and neither will you.
>
> I'm just asking you show me how *simple* code in Go will become much more 
> complicated in D, as this is what you seem to think.
>
> And I mean something we will all use all day long (ex: declaring or using 
> functions/types/arrays/slices/references/loops/etc etc), not the most 
> complicated code you can come up with.
>
> THAT would be useful, and also a fair comparison between both languages.
>
> Because from what I see below, I may think you couldn't manage to find 
> such an example 
>
> But maybe I'm wrong, I don't know...
>   
> On Wednesday, August 2, 2017 at 9:33:48 AM UTC+1, Egon wrote:
>>
>> On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com wrote:
>>>
>>> For all the common parts with Go (functions, methods, reference classes, 
>>> strings, arrays, slices, ranges, foreach, etc), honestly I don't know why 
>>> you say it's simpler in Go.
>>>
>>> Can you show me two examples of code side by side, and tell me "look how 
>>> much simpler it's with Go's" ?
>>>
>>> Because from what I read, I'm sometimes wondering if you really know 
>>> that the type declarations in D are MUCH simpler than in C/C++.
>>>
>>
>> error* (**callbacks)(int);
>>
>> Error[] function(int)[][string] callbacks;
>>
>> var callbacks map[string]func(int) []error
>>
>>
>>> For instance :
>>>
>>> int[]
>>> first_array_of_ints,
>>> second_array_of_ints;
>>>
>>> int[string]
>>> first_map_of_ints_indexed_by_a_string,
>>> second_map_of_ints_indexed_by_a_string;
>>>
>>> TYPE
>>> first_reference_to_an_object_of_this_type,
>>> second_reference_to_an_object_of_this_type;
>>>
>>> So, with all due respect, how many applications have you already 
>>> programmed in D before telling me that Go's syntax is so simpler to use and 
>>> to learn ?
>>>
>>> I agree there are much *less* possibilities in Go, but that doesn't 
>>> mean it's automatically a simpler language to learn for all the common 
>>> parts with D. Seriously.
>>>
>>> Because I had to learn both, and at least for a C++/Java/C# programmer 
>>> like me, D transition was almost immediate, really a matter of hours to 
>>> become comfortable with the language. Everything was alike, but much 
>>> simpler and easier than in C++.
>>>
>>> Believe me or not, I've taught programming with D to my two teenagers 
>>> with D. Really.
>>>
>>> I've chosen it because it was the only strongly-typed language close to 
>>> Javascript that was really easy to learn, while allowing them to quickly 
>>> switch to C++, Java or C# later if they wanted to.
>>>
>>> Go is much simpler than C++ too, I agree of course, but for having 
>>> learned both Go then D, again from the point of view of a former 
>>> C++/Java/C# programmer like me, I didn't feel that quickly at home with Go 
>>> than with D, mainly because Go diverged much more from its predecessors 
>>> than D from a syntactic point of view.
>>>
>>> So, again from a syntactic point of view, I don't think how you can 
>>> affirm that it's much easier i