[go-nuts] Re: I am confused.

[matthewjuran]

The go command prompt program (“go help”) will run the compiler, a separate 
program, when certain commands are used (like “go build”). The compile 
process creates a file that is the program you wrote if no errors are 
found, and you can then run this program file to do the work you coded.

An IDE will do this with the same go programs (the toolchain you are 
installing) but may make organizing and working on your project and calling 
the compiler commands more ordered. The IDE may help you download and 
install the Go toolchain. I haven't used Visual Studio Code but we did use 
Visual Studio at university.

I like using the windows of the OS to have multiple editor windows and 
command prompt windows open; alt-tab is a useful Windows keyboard shortcut 
for managing this. Virtual desktops are an additional way to organize the 
workspace.

Matt

On Tuesday, May 22, 2018 at 11:41:07 PM UTC-5, John wrote:
>
> Is the visual code studio an compiler or a what, I tried it myself but I 
> isn't able to program.
>
>
>

-- 
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: From PHP to Go, here my first side project. What do you think?

[matthewjuran]

Hello, here’s a code review. Thanks for sharing here.

These are my unfiltered opinions that may be wrong, and I hope they are 
useful for you.

Have you considered including an open source license like BSD? There’s a 
base GitHub license applied now.

func CreateRelative(
path string,
confPath string,
scope string,
) string {

could be

func CreateRelative(path, confPath, scope string) {

In package notifier the Notifier interface is unused. Directly writing in 
beeep.Alert and beeep.Notify is clearer than assuming the implementation 
might need to be varied in the future, and these symbols, if necessary, 
should be part of package main, having a separate package just to define an 
interface is unnecessary. If you need to vary the notification 
implementation later then add in the interface then. An interface 
definition should be an input in the same package.

Config is too general of a package name. These symbols should also be part 
of package main. This is another case where the interface is defined but 
not consumed.

Packages shouldn't be used for application structuring like you have with 
config. Packages should be made when portability between projects is 
possible or another package main is needed.

Often Go tools don’t have any text output unless there’s an error. Perhaps 
a flag could surround the watched files print?

This seems like it could be a useful part of a development workflow.

Matt

On Monday, May 21, 2018 at 10:29:26 AM UTC-5, Matthieu Cneude wrote:
>
> Hello everybody,
>
> I am a PHP developer for many years and I am trying to learn Golang. I 
> think knowing a language which offer low level possibilities can be a very 
> good complement to a more high level language.
> Therefore I wrote a little application which watch tests file and run them 
> here: https://github.com/Phantas0s/testomatic
>
> What do you think about the code? About the application itself? How can I 
> improve it?
>
> Any advise is welcome. Even the worst criticism!
>
> 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: I am confused.

[matthewjuran]

Emacs (https://www.gnu.org/software/emacs/), Notepad++ 
(https://notepad-plus-plus.org/), and Vim (https://www.vim.org/) are code 
editors that work on Windows. I use Vim on macOS. Emacs and Vim will take 
longer to learn than Notepad++.

These editors let you open and modify code files (right click on the file, 
click on “open with”, pick the editor) but you then have to process the 
files to work. The Go command line tools do this and are meant to be 
simple, and you can use them through cmd.exe after installing Go (cmd.exe 
is included with Windows already and might be called “Command Prompt” in 
the start menu). If “go help” works in cmd.exe then you’ve correctly 
installed Go.

The installation instructions at https://golang.org/doc/install say this 
for Windows:

You may need to restart any open command prompts for the change to take 
> effect.


An advanced editor (an Integrated Development Environment, IDE) like the 
mentioned Visual Studio Code (https://code.visualstudio.com/) will do the 
command prompting for you.

To pick where to put your code files you’ll need to setup the workspace, 
see https://golang.org/doc/code.html#Workspaces

GitHub is a good place to see examples of real projects: 
https://github.com/topics/go

I found these websites with Google Search at https://google.com

Which version of Windows are you using?

Matt

On Monday, May 21, 2018 at 12:27:52 AM UTC-5, John wrote:
>
>   Hello I am just a random person in this small planet of the creation 
> that happens to think that artificial intelligence will take over the world 
> of jobs in the future. With that point of I started to learn Java Script on 
> Khan Academy but didn't quite make that much progress. So I think that now 
> it is time for me to do some serious coding with my OWN launcher or 
> compiler. And after a while I chosen go and got me here. But before I join 
> this group I tried to download the compiler but it didn't quite work. When 
> I finished downloading the 65 MSI installer it only gave me the option to 
> delete the itself or itself and maybe the actual go compiler or repair 
> itself, which when I clicked it it ran something and nothing visually 
> changed. The source I was unable to open for some reason, the computer says 
> it is to big and needs something program to open it. I tried the Internet 
> Explorer but it didn't do anything. But when i clicked the store it shows 
> me that if I have a Microsoft account it can download an program that can 
> open the source which I don't have. By the way I am on a Windows computer. 
> So please Gophers help me become a Gopher too.
>

-- 
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: Validation checks in Go

[matthewjuran]

An example is nil map access or concurrent map access both cause panics in 
the runtime 
(https://github.com/golang/go/blob/release-branch.go1.10/src/runtime/hashmap.go#L357).

A useful thing panic without recover does is print the stack trace.

Matt

On Saturday, May 19, 2018 at 11:57:33 AM UTC-5, David Skinner wrote:
>
> https://play.golang.org/p/d_fQWzXnlAm
>
> If you are going to use panic, then choose a place where you can recover 
> gracefully and report the error.
>
> I do agree, that it is an mistake to return an error code if your 
> assignment was to write a function that only has valid input. The software 
> engineer giving you the assignment may be doing data validation else where 
> and is wrapping a higher level function with a defer to deal with errors. 
> If you are working on a team, it is best to produce what is expected, not 
> something better.
>
> On Fri, May 18, 2018 at 7:33 PM  wrote:
>
>> I may have misunderstood the question. I follow the idea of panic when 
>> the program is in an invalid state.
>>
>> If Divide can receive any input then this is probably a better API:
>>
>> func Divide(a, b float64) (float64, error) {
>>
>> where you would return an ErrDivideByZero made with errors.New as a 
>> global exported var instead of panicking.
>>
>> But if Divide can only receive valid input then that assert seems 
>> appropriate to me.
>>
>> Matt
>>
>> On Monday, May 14, 2018 at 7:38:32 PM UTC-5, Tristan Muntsinger wrote:
>>>
>>> Is it reasonable to use a function like "Assert" below to do validation 
>>> checking in Go?  If not, why not?
>>>
>>> func Assert(t bool, msg string) {
>>> if !t {
>>> debug.SetTraceback("all")
>>> debug.PrintStack()
>>> log.Fatal("Assertion failed: " + msg)
>>> }
>>> }
>>>
>>> func Divide(a float64, b float64) float64 {
>>> Assert(b != 0, "divide by 0")
>>> return a / b
>>> }
>>>
>>> func main() {
>>> fmt.Println(Divide(10, 5))
>>> }
>>>
>>> Thanks,
>>> -Tristan
>>>
>>> -- 
>> 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/viuz4JTVelE/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.

[go-nuts] Re: [ANN] Pion-TURN, a TURN server designed with ease of use and extensibility in mind

[matthewjuran]

Thanks for the kind reply.

Should I change this name, but still keep things like the realm/socket as 
> members still? I think of turn.Server as the global singleton that handles 
> all traffic (UDP or TCP)


An interface is used to allow varying types to have the same logic applied. 
In this case when you assign a Server interface var the only use will be to 
check client authentication. Sometimes people use type assertions on 
interfaces but my opinion is that shouldn’t be a regular thing. The use of 
the interface var vs how it’s done are decoupled.

I am only at 7% coverage, I am working on adding more. It isn't feature 
> complete, I have been more worried about getting users (and getting 
> valuable testing eyes) I will add more tests this weekend.


Unit tests are one part, but I’d be more interested in some sort of overall 
functionality test maybe with load characteristics that perhaps benchmarks. 
If you can show the example works then that may help attract users.

Does that thinking all seem sane?


Well I don’t think a couple extra directories under examples and a few 
extra tens or hundreds of KB will make much difference. Any dependencies 
like Redis would only be needed if building the example. If necessary a 
vendorer could remove files they don’t want.

I use the pkg repo to export things that people might actually want (like 
> generic packet handling) and will be working on another project that uses 
> it (native WebRTC client in Golang)


I saw the STUN things there which seems to match what I was describing.

Matt

On Saturday, May 19, 2018 at 2:07:38 AM UTC-5, se...@pion.ly wrote:
>
> This review is fantastic! I committed what I understood, I have a few 
> questions though.
>
> > Instead of turn.Server a more idiomatic interface name could be 
> something like turn.ClientAuthenticator
> Should I change this name, but still keep things like the realm/socket as 
> members still? I think of turn.Server as the global singleton that handles 
> all traffic (UDP or TCP)
>
> > package server doesn’t have tests and neither does package turn. How did 
> you validate it? Is there validation code you can include?
> I am only at 7% coverage, I am working on adding more. It isn't feature 
> complete, I have been more worried about getting users (and getting 
> valuable testing eyes) I will add more tests this weekend.
>
> > Instead of cmd/simple-turn perhaps you could have 
> examples/simple/main.go. Having a cmd indicates that the cmd is supported, 
> but the authentication is minimal in simple-turn and might not be good for 
> some uses.
>
> The nice thing about simple-turn is for those easy use cases (I want a 
> TURN server that just has 5 users)
> I was thinking of making another repo, maybe turn-examples? That I could 
> make a bunch of examples like Redis integration a REST server etc... I 
> don't want to put that code in this repo because if it is vendored it will 
> cause bloat for people.
> Does that thinking all seem sane?
>
> > Standards like STUN and TURN are an opportunity to make portable code. 
> This layout might lead to clearer and more reusable code:
> Would it be ok if I kept the current layout, but created a `turn-examples` 
> repo? I am mostly worried about bloating code bases that try to vendor 
> pion-turn
>
> I use the pkg repo to export things that people might actually want (like 
> generic packet handling) and will be working on another project that uses 
> it (native WebRTC client in Golang)
>
>
> Thank you so much for the review again! I really appreciate the 
> improvements you have provided.
>
> On Tuesday, May 15, 2018 at 7:46:46 AM UTC-7, matthe...@gmail.com wrote:
>>
>> Hello, thanks for sharing here and thanks for the MIT license. Here’s a 
>> code review.
>>
>> These are my unfiltered opinions. You may not agree with some or any of 
>> them, and some or all of them might not be reasonable to implement. My goal 
>> is to build an ideal way to write Go code by doing code reviews here. My 
>> hope is this feedback is useful to you in this project or in a future 
>> project.
>>
>> In cmd/simple-turn “type myTurnServer struct {}” is a code smell that 
>> hints at overusing interface, but in this case including usersMap in type 
>> myTurnServer would remove the smell. Having the application do 
>> authentication makes sense.
>>
>> (application meaning code using the library)
>>
>> Instead of turn.Server a more idiomatic interface name could be something 
>> like turn.ClientAuthenticator.
>>
>> package server doesn’t have tests and neither does package turn. How did 
>> you validate it? Is there validation code you can include?
>>
>> Perhaps consider embedding Protocol in allocation.FiveTuple.
>>
>> Instead of cmd/simple-turn perhaps you could have 
>> examples/simple/main.go. Having a cmd indicates that the cmd is supported, 
>> but the authentication is minimal in simple-turn and might not be good for 
>> some uses.
>>
>> Standards like STUN and TURN are an 

[go-nuts] Re: Load balancing with error feedback capabilities

[matthewjuran]

By embedding I meant this:

type ServiceQProperties struct {
...
sync.Mutex
}

which allows you to call p.Lock() instead of p.REMutex.Lock(). It’s just a 
personal preference that I was happy about when I learned about it.

One thought here is you could make it a *sync.Mutex and not use a pointer 
in these function arguments. Maps vars are pointers so you are doing a 
double dereference when accessing RequestErrorLog. This avoids (*sqp) but 
there may be extra memory used and work done to copy the entire struct var 
as an argument. If you get into performance details I would look at pprof 
or package testing benchmarking to decide if it matters, but I try to 
choose cleanest code first.

Thanks for sharing your verification approach.

I haven’t gotten far enough into network services to have much to say about 
the features although maybe I will in the future. I was curious about this:

The buffered requests are forwarded in FIFO order when the service is 
> available next.


wouldn’t you want to do these concurrently if possible?

Matt

On Friday, May 18, 2018 at 11:50:56 AM UTC-5, Ankit Gupta wrote:
>
> Hi Matt,
>
> First of all, thanks so much for the review.
>
> I will revisit the package structure and take care of err handling in a 
> more idiomatic way. Few points - 
>
> - The mutex is embedded in model.ServiceQProperties. Here is the 
> definition in model.balancer_properties.go - 
>
> type ServiceQProperties struct {
> ...
> REMutex sync.Mutex
> }
>
> This is used in two places - error logging to service map in 
> service_error.go and reading in select_service.go.
>
> - I validated 3 things (all tests were done on a cluster of aws t2 medium 
> linux machines) -  
>
> a) Program should reduce probability of selection of errored nodes - this 
> was done by continously bringing 1 to n-1 services down/up and noting the 
> trend of requests sent to each node after every state change. As an 
> example, for a 3 node cluster with 1 node down for 2 mins, the probability 
> of selection of that node reduced (from 33%) by around 1-2% on each 
> subsequent hit.
>
> b) For performance testing, I used apache bench for issuing large number 
> of concurrent requests/issuing requests within a time frame and 
> benchmarking against nginx. There was a 10% difference on average that is 
> attributed to the fact that I preprocess (parse/store) all requests before 
> forwarding and that the code is not the most optimzed version right now.
>
> c) For deferred queue functionality, I specifically wanted to test 
> scenarios where both active and deferred requests are to be sent out 
> simultaneously and if user defined concurrency limits are still valid.
>
> Let me know if I should provide more details on a specific feature.
>
> Thanks,
> Ankit
>
> On Friday, May 18, 2018 at 8:21:12 PM UTC+5:30, matthe...@gmail.com wrote:
>>
>> Hi Ankit, thanks for the Apache license and for sharing here. Here’s a 
>> code review.
>>
>> These are my unfiltered opinions and I hope that they are useful.
>>
>> Without looking at any code yet, the packages might not be idiomatic. 
>> Packages should contain specific behavior that can be decoupled from the 
>> application. These concepts could be represented as files and symbols in 
>> package main.
>>
>> SQP_K_LISTENER_PORT might be more regularly represented as 
>> SQPKListenerPort.
>>
>> In config_manager_test.go you could embed model.ServiceQProperties and 
>> error in type Properties for better readability.
>>
>> The newlines in the functions don’t help readability.
>>
>> Instead of this:
>>
>> if sqp, err := getProperties(getPropertyFilePath()); err == nil {
>> …
>> } else {
>> fmt.Fprintf(os.Stderr…
>>
>> this may be more readable:
>>
>> // or if …; err != nil {
>> sqp, err := getProperties(getPropertyFilePath())
>> if err != nil {
>> fmt.Fprintf(os.Stderr…
>> return
>> }
>> // regular functionality
>>
>> Generally “err == nil” shouldn’t be in the code.
>>
>> In getListener a similar improvement could be made to avoid the 
>> unnecessary indentation:
>>
>> if sqp.SSLEnabled == false {
>> return …
>> }
>> // longer behavior
>>
>> In TestWorkAssignment the sqp could be simpler:
>>
>> sqp := model.ServiceQProperty{
>> ListenerPort: “5252”,
>> Proto:“http”,
>> …
>>
>> More if improvement in algorithm.ChooseServiceIndex:
>>
>> if retry != 0 {
>> return …
>> }
>> // longer behavior
>>
>> The else after “if sumErr == 0” is unnecessary.
>>
>> The mutex could be embedded in model.ServiceQProperties.
>>
>> How did you validate this program?
>>
>> Thanks,
>> Matt
>>
>> On Friday, May 18, 2018 at 2:34:20 AM UTC-5, Ankit Gupta wrote:
>>>
>>> Hello gophers,
>>>
>>> I recently built a small HTTP load balancer with capabilities built 
>>> around error feedback - https://github.com/gptankit/serviceq
>>> Provides two primary functionalities - deferred request queue and 
>>> probabilitically reducing errored nodes selection.

[go-nuts] Re: Load balancing with error feedback capabilities

[matthewjuran]

Hi Ankit, thanks for the Apache license and for sharing here. Here’s a code 
review.

These are my unfiltered opinions and I hope that they are useful.

Without looking at any code yet, the packages might not be idiomatic. 
Packages should contain specific behavior that can be decoupled from the 
application. These concepts could be represented as files and symbols in 
package main.

SQP_K_LISTENER_PORT might be more regularly represented as SQPKListenerPort.

In config_manager_test.go you could embed model.ServiceQProperties and 
error in type Properties for better readability.

The newlines in the functions don’t help readability.

Instead of this:

if sqp, err := getProperties(getPropertyFilePath()); err == nil {
…
} else {
fmt.Fprintf(os.Stderr…

this may be more readable:

// or if …; err != nil {
sqp, err := getProperties(getPropertyFilePath())
if err != nil {
fmt.Fprintf(os.Stderr…
return
}
// regular functionality

Generally “err == nil” shouldn’t be in the code.

In getListener a similar improvement could be made to avoid the unnecessary 
indentation:

if sqp.SSLEnabled == false {
return …
}
// longer behavior

In TestWorkAssignment the sqp could be simpler:

sqp := model.ServiceQProperty{
ListenerPort: “5252”,
Proto:“http”,
…

More if improvement in algorithm.ChooseServiceIndex:

if retry != 0 {
return …
}
// longer behavior

The else after “if sumErr == 0” is unnecessary.

The mutex could be embedded in model.ServiceQProperties.

How did you validate this program?

Thanks,
Matt

On Friday, May 18, 2018 at 2:34:20 AM UTC-5, Ankit Gupta wrote:
>
> Hello gophers,
>
> I recently built a small HTTP load balancer with capabilities built around 
> error feedback - https://github.com/gptankit/serviceq
> Provides two primary functionalities - deferred request queue and 
> probabilitically reducing errored nodes selection.
>
> I am using channel as a in-memory data structure for storing deferred 
> requests. Would love some feedback on this approach and on the project in 
> general.
>
>
>

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

Re: [go-nuts] Re: Go license and fitness for purpose

[matthewjuran]

Thanks for responding Michael.

"decorative item not to be used off-road, in uneven terrain, or relied upon 
> as protection in case of vehicle roll."


The sticker I’ve been looking at says something like “modifying or 
attaching anything to this ROPS will compromise the structure and may cause 
injury or death” and I had a relative roll a tractor last year but is 
luckily ok.

I understand being conservative for the courts, but GCC and Go can make 
programs for computers that can do safety applications reliably. People 
maybe do with GCC derivatives. People do with Ada or C (and Go maybe is 
less mistake-prone than C at the language level).

Leveraging the work of an open or free project and contributing back 
improvements found in testing seems like a good idea to me for liable 
ventures and for the reliability of minimal liability uses that Google does 
with Go and maybe GCC. I don’t think these compiler projects should take on 
unnecessary liability, but one thing that can be done is to be sure there 
aren’t any intentional mistakes, backdoors, or practical jokes as allowed 
under the licenses. I'd like to guarantee that to liable ventures and it's 
a free win for general purpose computing anyway.

Matt

On Thursday, May 17, 2018 at 12:18:30 PM UTC-5, Michael Jones wrote:
>
> perhaps some context will make this clearer. no reference is being made to 
> any actual persons or events.
>
> 1. It is the observed habit of people (plaintiff's) bring suit in court 
> when something goes wrong. 
> Ex: airplane crash, dark spot on potato chip, food is too hot, etc.
>
> 2. Plaintiff's attorneys have developed the habit of including everyone 
> possible in the "bag guy" list; this creates a kind of mutual fund where 
> everyone can settle for $10,000 and that, multiplied by 100 defendants, is 
> $1M. The attorney gets 1/3 of that, so attorneys drive nice cars and fly 
> first class.
> Ex: car accident with fire.: sue the car company, the airbag company, the 
> brake pad company, the glass company, the bumper designer, , the gas 
> station, the gas transport truck, the oil refinery,...,the tire company, 
> the person who designed the tire treads, etc.
>
> 3. After 60+ years of this, everyone who is wise to the situation sells 
> retail products that specifically disclaim every possible dangerous use, 
> and as many kinds of critical or life-safety misuse as can be foreseen, and 
> wholesale products where every possible liability passes to the purchaser 
> as a condition of sale. 
> Ex: "You agree to not use the APIs for any activities where the use or 
> failure of the APIs could lead to death, personal injury, or environmental 
> damage (such as the operation of nuclear facilities, air traffic control, 
> or life support systems)."
>
> 4. After 40+ years of open source having an observable footprint, open 
> source entities, corporate contributors, and individuals have found that 
> this style of "universal disclaimer" is an important defensive bulwark. 
> Most people would not want to lose their house and savings as the result of 
> contributing code to a matrix library that happens to be used in the 
> science payload of a space project where the rocket engines explode on 
> launch and the resulting fires and fumes cause problems for miles around 
> resulting in a class-action suit for much of Florida. (crazy made-up 
> example but perhaps it makes clear the idea of minimizing exposure to legal 
> risks associated in no logical way with individual action.)
>
> This is the context in which various excuse-laden, 
> suitability-disclaiming, crazy-seeming license agreements arise.
>
> As a real example, but with the name removed, I once saw in a parking lot 
> a new pickup truck made by a well-known Japanese car manufacturer. It had a 
> shiny chrome tubular framework rising up from the bed of the truck just 
> behind the cab. The framework had lights attached. It have the truck a 
> tough, off-road character. I said to my wife, "wow, that's quite the 
> roll-bar for a little truck. Look how thick the tubes are." She said, there 
> is a sticker on it what does it say. We looked, it read:  "decorative item 
> not to be used off-road, in uneven terrain, or relied upon as protection in 
> case of vehicle roll."
>
> That is the real world of litigious people, 1/3 hungry attorneys, and 
> juries that like to "do something" when there is a victim.
>
> On Thu, May 17, 2018 at 8:48 AM  wrote:
>
>> I was thinking something like writing an undocumented “Happy New Year!” 
>> to standard out at the start of the year. An obvious but undocumented ‘rm 
>> -rf /‘ attempt was mentioned above.
>>
>> My first program was a practical joke. On the calculator command line I 
>> said “press enter” then put the program call on the next line. The program 
>> would scroll some text forever. The command display state was preserved 
>> through being turned off, so somebody in the next class pressed enter then 
>> 

Re: [go-nuts] Re: Go license and fitness for purpose

[matthewjuran]

I was thinking something like writing an undocumented “Happy New Year!” to 
standard out at the start of the year. An obvious but undocumented ‘rm -rf 
/‘ attempt was mentioned above.

My first program was a practical joke. On the calculator command line I 
said “press enter” then put the program call on the next line. The program 
would scroll some text forever. The command display state was preserved 
through being turned off, so somebody in the next class pressed enter then 
had their calculator lock up and I got in trouble because the teacher had 
to remove the batteries. I had an effect on many people because of the lost 
class time. I explained that there was a key to interrupt any program.

These university licenses allow newcomers to programming to make that kind 
of social mistake and I think it’s right to not punish them for it. I might 
not be a programmer if I had gotten detention for the calculator program, 
and things like GCC might not exist without some wild thinking. I don’t 
think this approach is right for industry, other serious ventures, and 
especially not for safety focused applications though.

It looks like the Intel corporate family thinks Intel, ARM, and Power 
architecture processor implementations are trustworthy enough for safety 
applications. There’s this OS called VxWorks said on the website to be 
intended for safe IoT device applications: 
https://www.windriver.com/products/vxworks/

It appears that WindRiver has worked with the GCC project for the VxWorks 
platform: 
https://www.windriver.com/products/product-notes/tornado2/gnu_relnote.pdf

QNX has a C/C++ toolchain for ARM and x86: 
http://blackberry.qnx.com/en/products/certified_os/safe-kernel

Here’s a 2011 thread about Go and RTOS: 
https://groups.google.com/forum/#!topic/golang-nuts/95BJqJvb7I0

There there’s a claim that the garbage collector makes Go unusable in 
real-time operating systems, but I think there are cases where real-time is 
less important than the OS being developed with reliability in mind. Maybe 
Go could be very useful on RTOS platforms.

My understanding is the intent for Go is to solve problems at Google. I 
think involving varying outside uses of Go will help Google by making a 
toolchain more robust than just Google applications will do, and I think 
the design of the Go language is ideal for a next generation of general 
purpose software like C was before. And I hope this thread adds value.

“No features contrary to documentation” seems like a mistake since 
documentation is usually not right. “No obfuscated features or obviously 
wrong features” seems too vague and may invite incorrect claims. “This 
software has no effects except for documented or obvious use”? Obviously a 
lawyer would have to translate it to match case results and other lawyer 
things, and those writing software under the license would have to be aware 
of the implications. I plan to email a summary of this discussion to FSF 
and OSI mailing lists.

Thanks,
Matt

On Wednesday, May 16, 2018 at 8:55:09 PM UTC-5, kortschak wrote:
>
> I hope so. I provide a package (github.com/kortschak/zalgo) that I 
> cannot promise will not summon demons. It was written intentionally as 
> a joke. I disclaim all liability should use of the package bring about 
> meetings with demonic presences. 
>
> On Wed, 2018-05-16 at 07:25 -0700, matthe...@gmail.com  
> wrote: 
> > I think practical jokes should be allowed under the GPL, BSD, and 
> > similar  
> > licenses. 
>

-- 
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: [ANN] Dependencies for dummies

[matthewjuran]

You answered it, thanks.

Matt

On Wednesday, May 16, 2018 at 4:14:35 AM UTC-5, Gerardo Oscar JT wrote:
>
> Hello Matt,
>
> Having dependencies inside the project is the easiest way to make 
> reproducible builds (without having infrastructure for mirrors) and makes 
> your organization more independent from third parties. Moreover, tools 
> based on dependencies rules (like maven, npm, etc) could make your project 
> ending up with unexpected versions. How many libraries are in a regular 
> project, 10 maybe 20? managing versions by one by one and testing the side 
> effects of upgrading a library is affordable. Also, having all the code in 
> the same place makes the project reproducible for several years even if the 
> original repositories/vcs are not longer available or vcs has been 
> compromised with malicious code.
>
> Also, golla works with any git repos because destination folder is 
> indicated explicitly.
>
> Each tool has its pros and cons, this one fits what I expect from software 
> configuration.
>
> I hope having answered your question :)
>
> Chrs,
> Fulldump
>
>
>
>
>
> El martes, 15 de mayo de 2018, 15:56:23 (UTC+2), matthe...@gmail.com 
> escribió:
>>
>> Hello,
>>
>> I haven’t seen this pattern:
>>
>> src/vendor/github.com/fulldump/goconfig
>>
>> I’ve put vendored dependencies in the project:
>>
>> src/github.com/my/project/vendor/github.com/fulldump/goconfig
>>
>> Why are you doing it this way?
>>
>> Have you tried vgo? https://github.com/golang/vgo
>>
>> Matt
>>
>> On Sunday, May 13, 2018 at 3:12:59 PM UTC-5, Gerardo Oscar JT wrote:
>>>
>>> Hi gophers!
>>>
>>> Golang do not have a canonical way to download dependencies. Glide is 
>>> the last one I have been using and it is like a drunk elephant in my laptop.
>>>
>>> This weekend I have managed to summon the force to work on a silly 
>>> script that read a list of git repos, and do the clones, one by one.
>>>
>>> For the moment it supports:
>>>
>>>- Clone a specific git repo inside a specific directory (removing 
>>>the .git folder)
>>>- Pin a specific tag/branch/commit
>>>- Select a specific file or directory inside a repo to avoid cloning 
>>>all the repo
>>>- Comments prefixed with # are suported
>>>
>>> The project is called *golla*, here is the repo: 
>>> https://github.com/fulldump/golla 
>>>
>>> All dependencies should be specified in a file called golla like this:
>>>
>>> # This is a golla file!
>>> # First, we will clone a repo to a dir:
>>> git@ github.com:fulldump/goconfig.git* ->* src/vendor/
>>> github.com/fulldump/goconfig
>>>
>>> # Here we will clone a specific version:
>>> git@ github.com:fulldump/golax.git*#**v0.6.1* -> src/vendor/
>>> github.com/fulldump/golax
>>>
>>> # Only a file is cloned here (for example, golla script itself):
>>> git@ github.com:fulldump/golla.git*>golla.go* -> golla.go
>>>
>>>
>>> I hope this script could be helpful for anyone else.
>>>
>>> Happy to learn from your feedback,
>>> Fulldump
>>>
>>>
>>>

-- 
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: Validation checks in Go

[matthewjuran]

I may have misunderstood the question. I follow the idea of panic when the 
program is in an invalid state.

If Divide can receive any input then this is probably a better API:

func Divide(a, b float64) (float64, error) {

where you would return an ErrDivideByZero made with errors.New as a global 
exported var instead of panicking.

But if Divide can only receive valid input then that assert seems 
appropriate to me.

Matt

On Monday, May 14, 2018 at 7:38:32 PM UTC-5, Tristan Muntsinger wrote:
>
> Is it reasonable to use a function like "Assert" below to do validation 
> checking in Go?  If not, why not?
>
> func Assert(t bool, msg string) {
> if !t {
> debug.SetTraceback("all")
> debug.PrintStack()
> log.Fatal("Assertion failed: " + msg)
> }
> }
>
> func Divide(a float64, b float64) float64 {
> Assert(b != 0, "divide by 0")
> return a / b
> }
>
> func main() {
> fmt.Println(Divide(10, 5))
> }
>
> Thanks,
> -Tristan
>
>

-- 
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 license and fitness for purpose

[matthewjuran]

>
> It is not necessary to state up front that you are not willful and 
> malicious, or careless or negligent. Society expects that from you anyway.


I think practical jokes should be allowed under the GPL, BSD, and similar 
licenses.

If you really have legal concerns you should talk to a lawyer. Asking for 
> anonymous opinion on a forum isn't legal advice. This should certainly not 
> be the place to discuss legal matters such as the scope of a license. I 
> don't think anybody who answered you is actually a lawyer. If you come upon 
> something which you can't understand its license then don't use it.


I agree. I’m not a lawyer. I can’t recommend any open source license for 
life critical applications, which is an opinion I’ll bring to any future 
employer. On my own I’ve just been making art with Go and hope that the MIT 
license protects me from misuse liability in the general purpose libraries 
I’ve pulled from the art projects and put on GitHub.

I did get a fancy meal from them as we discussed the dangers of becoming 
> obligated because of not reading the fine print.


I hope “oppressive” tends to mean “reasonable compromise”.

Matt

On Tuesday, May 15, 2018 at 9:18:05 PM UTC-5, David Skinner wrote:
>
> Regarding this statement.
>
>> THE AUTHORS OF THIS SOFTWARE DID NOT INTENTIONALLY MAKE MISTAKES OR 
>> INCLUDE PRACTICAL JOKES
>
>
> If you place software out in the wild, and you have a LICENSE with no 
> warranty and indemnification and terms of service and imprint
>
>- You are not protected from frivolous law suits.
>- You are not protected if your actions were willful and malicious, or 
>careless or negligent.
>- You are not protected if you try to represent yourself pro se
>- You are not protected if you are too broke to fight it in court.
>
> If you do go to court and your attorney is computer savvy, he may 
> demonstrate to the judge that there was a legal binding agreement that the 
> damaged party had to have been aware of when visiting the web site or 
> repository where the software was obtained. Most judges will seize upon 
> such proof to dismiss a case or rule in your favor. Especially if your 
> attorney testifies (inappropriate) that the agreement was one he drafted, 
> or reviewed for fitness.
>
> It is not necessary to state up front that you are not willful and 
> malicious, or careless or negligent. Society expects that from you anyway.
>
> This is not to be considered legal advice, it is just a personal 
> observation.
>
> For specific legal advice you should consult with your families attorney 
> in your jurisdiction.
>
> I once wrote a small program for a company on spec, it was too small for a 
> formal contract. What I did for my own protection was to prepare a shrink 
> wrap license that required them to scroll down and click OK before 
> installing. When I went back a couple of weeks later to see if they like 
> the utility program, they were very happy, until a gave them a hard copy of 
> the license agreement. I had included a clause that if they used the 
> program for more than one week they were obligated to provide me additional 
> compensation in the form of lunch at my favorite restaurant. They thought 
> it was a funny joke. I did get a fancy meal from them as we discussed the 
> dangers of becoming obligated because of not reading the fine print.
>
> You should be aware that if you do something as simple as putting your 
> resume on the Internet and getting a programming assignment from Germany, 
> you could be in for a stiff fine if you have not complied with their local 
> regulations regarding imprint. If you have any contact with the EU and you 
> fail to comply with their privacy laws then as a US citizen you may be 
> considered in violation of treaty, big fine. The US is not the only place 
> where the legal system can get oppressive.
>

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

Re: [go-nuts] Go license and fitness for purpose

[matthewjuran]

I get that we have to work with the legal system details and that they may 
cause strange terms. Thanks for sharing some of those US details.

Isn’t there responsibility in putting tools out there publicly for anybody 
to use? Perhaps public distribution under the terms “don’t use this” is 
irresponsible and could be invalidated to the jury. I’m more concerned 
about the event that caused the court to be necessary though.

Can Sears laser engrave “this isn’t useful for anything” on their tools to 
avoid litigation due to poor craftsmanship? Is Sears responsible for poor 
craftsmanship causing injury if the Sears tool was bought second-hand at a 
garage sale?

Matt

On Tuesday, May 15, 2018 at 11:18:04 AM UTC-5, Matthias B. wrote:
>
> On Tue, 15 May 2018 06:39:40 -0700 (PDT) 
> matthe...@gmail.com  wrote: 
>
> > I don’t think I’m suggesting to not disclaim liability. I’m 
> > suggesting to claim that I didn’t hide anything to make a use break 
> > on purpose. It does add liability, but this is liability that is 
> > completely in the author’s control unlike regular bugs or misuse that 
>
> That's where you are wrong. 
> The author has no control over WHAT OTHER PEOPLE CLAIM he did. 
> If he makes a statement that he didn't intentionally put bad things into 
> the code and bad things happen, he ends up having to prove that these 
> are actually bugs and not intentional. And if the developer is unlucky 
> enough to live in the US, this looks like this: 
>
> * a jury of 12 laypersons, with NO UNDERSTANDING OF CODE WHATSOEVER 
> * a very slick and convincing expert who says that he's reviewed the 
>   code and he's 100% certain that this is intentional and not a bug 
> * some awkward nerd claiming it's a bug 
>
> The 12 laypeople decide who they trust more based on their "soft 
> skills". 
>
> It's not a coincidence that this whole EULA and total disclaimer BS was 
> started by US organizations. The US legal system is pure madness and US 
> lawyers are like mosquitoes. If you leave just a tiny bit of skin 
> exposed, they'll smell it and will try to land on it to suck your 
> blood. Whatever drawbacks you perceive from the current language in 
> licenses is way less bad than the alternative. 
>
> MSB 
>
> -- 
> No man is more pitiful than the one who looks to the shadows for warmth. 
>
>

-- 
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: dynamic programming or something else

[matthewjuran]

Hi Alex,

You may want to have logic tests in place to be sure your improvements are 
correct.

Capturing the complete call graph and CPU/memory usage using pprof may help 
reveal improvements. The visualization output has options you might want to 
adjust.

Inspecting the assembly output is another thing to do. Do you have a 
specific platform target? The Go compiler may emit different assembly 
depending on the target platform. Looking at platform tradeoffs may reveal 
improvements like managing virtual memory pages and processor local memory 
caching.

Others have mentioned algorithm improvements like adjusting the big-O 
function.

Matt

On Monday, May 14, 2018 at 7:22:00 PM UTC-5, Alex Dvoretskiy wrote:
>
> Hello Golang Nuts
>
> I'm trying to solve a problem. Algorithm is correct, but too slow. Perhaps 
> you can give me some ideas on how to improve running time?
>
> https://play.golang.org/p/XsXwT8EHtwC
>
>
> 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: [ANN] Pion-TURN, a TURN server designed with ease of use and extensibility in mind

[matthewjuran]

My mistake, I see that there is more library code at 
https://github.com/pions/pkg

Thanks,
Matt

On Tuesday, May 15, 2018 at 9:46:46 AM UTC-5, matthe...@gmail.com wrote:
>
> Hello, thanks for sharing here and thanks for the MIT license. Here’s a 
> code review.
>
> These are my unfiltered opinions. You may not agree with some or any of 
> them, and some or all of them might not be reasonable to implement. My goal 
> is to build an ideal way to write Go code by doing code reviews here. My 
> hope is this feedback is useful to you in this project or in a future 
> project.
>
> In cmd/simple-turn “type myTurnServer struct {}” is a code smell that 
> hints at overusing interface, but in this case including usersMap in type 
> myTurnServer would remove the smell. Having the application do 
> authentication makes sense.
>
> (application meaning code using the library)
>
> Instead of turn.Server a more idiomatic interface name could be something 
> like turn.ClientAuthenticator.
>
> package server doesn’t have tests and neither does package turn. How did 
> you validate it? Is there validation code you can include?
>
> Perhaps consider embedding Protocol in allocation.FiveTuple.
>
> Instead of cmd/simple-turn perhaps you could have examples/simple/main.go. 
> Having a cmd indicates that the cmd is supported, but the authentication is 
> minimal in simple-turn and might not be good for some uses.
>
> Standards like STUN and TURN are an opportunity to make portable code. 
> This layout might lead to clearer and more reusable code:
>
> github.com/pions/turnhost
> library code files that simplify making a TURN host
> /examples
> /simple
> main.go
> /turn
> library code files implementing the symbols and logic of the 
> standards
>
> Can you explain the github.com/pions/pkg/stun pattern? There is no pkg 
> directory included in the base repo.
>
> Thanks,
> Matt
>
> On Monday, May 14, 2018 at 4:35:09 PM UTC-5, se...@pion.ly wrote:
>>
>> Hi list!
>>
>> I wrote a TURN server and would love to get feedback/share 
>> https://github.com/pions/turn 
>>
>>
>> If you aren't interested in the code, but just want a TURN server there 
>> are already built releases that work on Windows/Darwin/Linux/FreeBSD and 
>> should just take 5 mins to get running!
>> These are the goals I had in mind when designing it, I was frustrated 
>> with other solutions and feel like it creates a higher barrier of entry to 
>> building WebRTC products then needed.
>>
>>
>> # Easy Setup 
>>
>> The example cmd (simple-turn) is a statically built TURN server, configured 
>> by environment variables. 
>>
>> The entire install setup is 5 commands, on any platform! The goal is that 
>> anyone should be able to run a TURN server on any platform.
>>
>> # Integration first
>> pion-turn makes no assumptions about how you authenticate users, how you 
>> log, or even your topology! Instead of running a dedicated TURN server you
>> can inherit from github.com/pions/turn and set whatever logger you want.
>>
>> # Embeddable
>> You can add this to an existing service. This means all your config files 
>> stay homogeneous instead of having the mismatch that makes it harder to 
>> manage your services.
>> For small setups it is usually an overkill to deploy dedicated TURN servers, 
>> this makes it easier to solve the problems you care about.
>>
>> ## Readable
>> All network interaction is commented with a link to the spec. This makes 
>> learning and debugging easier, the TURN server was written to also serve as 
>> a guide for others.
>>
>> ## Tested
>> Every commit is tested via travis-ci Go provides fantastic facilities for 
>> testing, and more will be added as time goes on.
>>
>> ## Shared libraries
>> Every pion product is built using shared libraries, allowing others to build 
>> things using existing tested STUN and TURN tools.
>>
>>
>> If you are interested in using it, but it is missing a feature you need I 
>> would love to add it! The more users, the better the software gets.
>>
>>

-- 
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: [ANN] Pion-TURN, a TURN server designed with ease of use and extensibility in mind

[matthewjuran]

Hello, thanks for sharing here and thanks for the MIT license. Here’s a 
code review.

These are my unfiltered opinions. You may not agree with some or any of 
them, and some or all of them might not be reasonable to implement. My goal 
is to build an ideal way to write Go code by doing code reviews here. My 
hope is this feedback is useful to you in this project or in a future 
project.

In cmd/simple-turn “type myTurnServer struct {}” is a code smell that hints 
at overusing interface, but in this case including usersMap in type 
myTurnServer would remove the smell. Having the application do 
authentication makes sense.

(application meaning code using the library)

Instead of turn.Server a more idiomatic interface name could be something 
like turn.ClientAuthenticator.

package server doesn’t have tests and neither does package turn. How did 
you validate it? Is there validation code you can include?

Perhaps consider embedding Protocol in allocation.FiveTuple.

Instead of cmd/simple-turn perhaps you could have examples/simple/main.go. 
Having a cmd indicates that the cmd is supported, but the authentication is 
minimal in simple-turn and might not be good for some uses.

Standards like STUN and TURN are an opportunity to make portable code. This 
layout might lead to clearer and more reusable code:

github.com/pions/turnhost
library code files that simplify making a TURN host
/examples
/simple
main.go
/turn
library code files implementing the symbols and logic of the 
standards

Can you explain the github.com/pions/pkg/stun pattern? There is no pkg 
directory included in the base repo.

Thanks,
Matt

On Monday, May 14, 2018 at 4:35:09 PM UTC-5, se...@pion.ly wrote:
>
> Hi list!
>
> I wrote a TURN server and would love to get feedback/share 
> https://github.com/pions/turn 
>
>
> If you aren't interested in the code, but just want a TURN server there 
> are already built releases that work on Windows/Darwin/Linux/FreeBSD and 
> should just take 5 mins to get running!
> These are the goals I had in mind when designing it, I was frustrated with 
> other solutions and feel like it creates a higher barrier of entry to 
> building WebRTC products then needed.
>
>
> # Easy Setup 
>
> The example cmd (simple-turn) is a statically built TURN server, configured 
> by environment variables. 
>
> The entire install setup is 5 commands, on any platform! The goal is that 
> anyone should be able to run a TURN server on any platform.
>
> # Integration first
> pion-turn makes no assumptions about how you authenticate users, how you log, 
> or even your topology! Instead of running a dedicated TURN server you
> can inherit from github.com/pions/turn and set whatever logger you want.
>
> # Embeddable
> You can add this to an existing service. This means all your config files 
> stay homogeneous instead of having the mismatch that makes it harder to 
> manage your services.
> For small setups it is usually an overkill to deploy dedicated TURN servers, 
> this makes it easier to solve the problems you care about.
>
> ## Readable
> All network interaction is commented with a link to the spec. This makes 
> learning and debugging easier, the TURN server was written to also serve as a 
> guide for others.
>
> ## Tested
> Every commit is tested via travis-ci Go provides fantastic facilities for 
> testing, and more will be added as time goes on.
>
> ## Shared libraries
> Every pion product is built using shared libraries, allowing others to build 
> things using existing tested STUN and TURN tools.
>
>
> If you are interested in using it, but it is missing a feature you need I 
> would love to add it! The more users, the better the software gets.
>
>

-- 
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: [ANN] Dependencies for dummies

[matthewjuran]

Hello,

I haven’t seen this pattern:

src/vendor/github.com/fulldump/goconfig

I’ve put vendored dependencies in the project:

src/github.com/my/project/vendor/github.com/fulldump/goconfig

Why are you doing it this way?

Have you tried vgo? https://github.com/golang/vgo

Matt

On Sunday, May 13, 2018 at 3:12:59 PM UTC-5, Gerardo Oscar JT wrote:
>
> Hi gophers!
>
> Golang do not have a canonical way to download dependencies. Glide is the 
> last one I have been using and it is like a drunk elephant in my laptop.
>
> This weekend I have managed to summon the force to work on a silly script 
> that read a list of git repos, and do the clones, one by one.
>
> For the moment it supports:
>
>- Clone a specific git repo inside a specific directory (removing the 
>.git folder)
>- Pin a specific tag/branch/commit
>- Select a specific file or directory inside a repo to avoid cloning 
>all the repo
>- Comments prefixed with # are suported
>
> The project is called *golla*, here is the repo: 
> https://github.com/fulldump/golla 
>
> All dependencies should be specified in a file called golla like this:
>
> # This is a golla file!
> # First, we will clone a repo to a dir:
> git@ github.com:fulldump/goconfig.git* ->* src/vendor/
> github.com/fulldump/goconfig
>
> # Here we will clone a specific version:
> git@ github.com:fulldump/golax.git*#**v0.6.1* -> src/vendor/
> github.com/fulldump/golax
>
> # Only a file is cloned here (for example, golla script itself):
> git@ github.com:fulldump/golla.git*>golla.go* -> golla.go
>
>
> I hope this script could be helpful for anyone else.
>
> Happy to learn from your feedback,
> Fulldump
>
>
>

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

Re: [go-nuts] Go license and fitness for purpose

[matthewjuran]

I don’t think I’m suggesting to not disclaim liability. I’m suggesting to 
claim that I didn’t hide anything to make a use break on purpose. It does 
add liability, but this is liability that is completely in the author’s 
control unlike regular bugs or misuse that disclaiming other liability 
still protects against.

I'm not a lawyer so I'm guessing what liability means.

In a collaborative project I would think the license contributors sign 
would certify that intentional mistakes will not be added and that the 
individual is liable if their contribution includes such a thing. If the 
project is found liable for the results of a hidden practical joke then the 
liability funnels to the individual and the collaborators removes their 
contributions.

Go uses other open source projects so adjusting the license this way would 
be a very large task, but I’d like top quality free software tools please.

Matt

On Monday, May 14, 2018 at 8:54:35 PM UTC-5, Krzysztof Kowalczyk wrote:
>
> On Monday, May 14, 2018 at 7:25:03 AM UTC-7, matthe...@gmail.com wrote:
>>
>> But you aren't going to get much in the way of guarantees when you 
>>> receive and use something for free. 
>>
>>
>> My work is not free, I want to contribute time back.
>>
>>>
>>>
> It's unclear if you understand the implications.
>
> If you were to contribute to a project that uses a license that doesn't 
> disclaim liability, your contributions would also fall under the same terms.
>
> In other words, if someone decided that they were harmed by your code 
> (e.g. because you made a coding mistake which corrupted their files) they 
> could sue you. Since you didn't disclaim liability, they could win and you 
> would have to pay them money.
>
> For code that you gave them for free.
>
> I'm guessing you wouldn't want to expose yourself to such liability. 
> Neither does anyone else.
>
> That's why every open source license includes a disclaimer of liability.
>
>
>  
>

-- 
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: Validation checks in Go

[matthewjuran]

What I’ve seen in the standard library was no named asserts like this, just 
if checks with panics. The panic functionality does what you’ve described. 
Personally I prefer the look of if+panic instead of another function for 
this.

Matt

On Monday, May 14, 2018 at 7:38:32 PM UTC-5, Tristan Muntsinger wrote:
>
> Is it reasonable to use a function like "Assert" below to do validation 
> checking in Go?  If not, why not?
>
> func Assert(t bool, msg string) {
> if !t {
> debug.SetTraceback("all")
> debug.PrintStack()
> log.Fatal("Assertion failed: " + msg)
> }
> }
>
> func Divide(a float64, b float64) float64 {
> Assert(b != 0, "divide by 0")
> return a / b
> }
>
> func main() {
> fmt.Println(Divide(10, 5))
> }
>
> Thanks,
> -Tristan
>
>

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

Re: [go-nuts] Go license and fitness for purpose

[matthewjuran]

>
> Legalese that OP tried to ridicule (imo) says otherwise. They can be sued 
> but they can not lose, even if they intentionally would put a `rm -rf /` 
> in 
> the code. 


I mentioned email addresses being stolen, but I’m more concerned about 
things like somebody thinking they can use GCC and a regular Dell desktop 
computer to coordinate real trains. Go/GCC don’t have to make misuse 
possibly worse.

Matt

On Monday, May 14, 2018 at 3:54:08 AM UTC-5, ohir wrote:
>
> On Sun, 13 May 2018 22:28:02 -0500 
> Pete Wilson  wrote: 
>
> > All this is true. 
> > But I expect that one of these fine days, someone sueable is going to 
> ship 
> > software with a serious bug, and are going to get sued and lose 
>
>
> > get sued and lose 
>
> Legalese that OP tried to ridicule (imo) says otherwise. They can be sued 
> but they can not lose, even if they intentionally would put a `rm -rf /` 
> in 
> the code. 
>   
> In the law domain: 
>
> (i) words, sentences, punctuation even -- have much stricter meaning. Not 
> necessarily the same as popular one. Sometimes particular wording has 
> meaning to the contrary of what layman may understand. 
>
> (ii) Text written in proper legalese has real life effects. Often 
> immediate 
> ones -- as with widely approved Open Source licenses. 
>
> FYI that enumerated cases in the license disclaimer part stem from past 
> litigation where someone litigated and won on given case. 
> See: [1] "Hojgaard v EON" for most recent example. 
>
> Disclaimer: always hire a lawyer to read any legalese for you. However 
> expensive it could be, it might be way cheaper than future effects of your 
> own understanding of what you read ;). I am not a lawyer of course :). 
>
> [1] https://www.supremecourt.uk/cases/uksc-2015-0115.html 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

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

[go-nuts] Re: RFC - Review request for a project done in Golang

[matthewjuran]

They might have been looking for something like this:

github.com/psankar/network-monitor
package monitor code files
cmd/
minion/
package main code files
server/
package main code files

In a code review I would mention the use of packages as not being ideal, 
but that’s just my opinion. You seem able to write Go code, but there 
aren’t tests in this solution. How did you verify it? Maybe you passed but 
there was a better candidate?

Matt

On Monday, May 14, 2018 at 6:35:23 AM UTC-5, Sankar wrote:
>
> Hi
>
> I was recently asked in an interview to write a golang program for a 
> problem that involves working with a million nodes. I did write a program 
> that solved the problem statement. However, I was told that the solution 
> was "poorly structured", but I did not get any detailed review comments 
> though. 
>
> So, I recreated the solution in github and wanted to know if anyone could 
> give some review comments as to what you see as bad things in the code.
>
> The problem statement, code and the instructions are at: 
> https://github.com/psankar/network-monitor 
>
> I personally felt that the code (written in about 6 hours for the 
> interview) is good and I would've hired anyone writing this, but may be I 
> am biased because it is written by me. I want to improve my Golang skills 
> and your review comments would be helpful. Any help ?
>
> If the golang list is unsuitable for this, you can even email me, 
> individually, with the review comments.
>
> Thanks.
>
> Sankar
>

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

Re: [go-nuts] Go license and fitness for purpose

[matthewjuran]

>
> I suspect you are worrying too much given both the long history of 
> open source software and the large number of 
> groups/organizations/companies that rely on it. 


I was reading about the ILOVEYOU Windows virus and recall hearing about it 
at the time. In that case the way Windows worked led to a program that 
corrupted files across the world and caused some institutions to turn off 
their Internet connection for awhile. Supposedly the person that let it out 
said they did so by mistake. I'm wondering if Microsoft should have been 
liable.

There are already major mistakes in open source software (Heartbleed in 
OpenSSL is a recent example) and I know that more than one computer culture 
involved in open source software in the United States enjoy practical 
jokes. I think it would look bad for many institutions if their software 
included a practical joke that unintentionally enabled email addresses to 
be stolen, but these licenses now invite such an inclusion if the person is 
willing to trade possible world-wide fame for loss of trust in the software 
world. By adding the term to the license I'd think that person is now 
liable instead of the users of the library.

But you aren't going to get much in the way of guarantees when you 
> receive and use something for free. 


My work is not free, I want to contribute time back.

If you really feel you need some sort of legal guarantee then I 
> suggest you look into some paid options that provide Go and/or GCC, 
> such as Red Hat or Ubuntu, where there may be more of a legal 
> framework that is more to your liking. 


That’s interesting, I may look at these kinds of companies depending on the 
task. But how can they guarantee Go and/or GCC don't include these things? 
They don't have a different license.

So, even someone selling you a $300 enterprise motherboard doesn't want to 
> be responsible for ensuring you are using it in a sensible fashion.


I don’t think I’m asking for any extra responsibility, I assume in this 
case there is already an assumption based on trust and money that no 
intentional mistakes or practical jokes are included, unless there’s some 
sort of backdoor.

Who would determine whether an mistaken action was intentional? This 
> seems like a very dangerous inclusion. 


I’d like lawyers to give their interpretation, I’m not a lawyer.

Both Go and GCC get an advantage from using widely-used and 
> well-understood free software licenses.  Making any modification to 
> those licenses would force every large organization that wants to use 
> these tools to reanalyze the license to make sure it will be 
> acceptable.  So the place to change this, if you think there is a need 
> to change it, is not with individual projects, but with an umbrella 
> organization like the Free Software Foundation or the Open Source 
> Initiative. 


I’ll look at bringing this there, thanks. I did have the thought that it 
might give Go a competitive edge.

Thanks,
Matt

On Sunday, May 13, 2018 at 10:45:49 PM UTC-5, Ian Lance Taylor wrote:
>
> On Sun, May 13, 2018 at 1:01 PM,   
> wrote: 
> >> Why would you assume more liability than necessary? 
> > 
> > 
> > My thought is the authors want to gain serious users to increase 
> feedback 
> > quality and improve the developer market. I thought this was why Google 
> let 
> > Go be open source besides attracting academic uses. 
> > 
> >> And as an open source developer who does not get paid, I feel better if 
> >> I have no liability whatsoever. Now, if you were PAYING ME for my 
> >> services, then I will be happy to provide you with assurances that make 
> >> you feel better. 
> > 
> > 
> > I don't think this is the attitude behind GCC, or maybe it is. I want to 
> > write programs that do things worth money and hope to use Go or GCC to 
> do so 
> > (including working with and on those projects for free), but if they 
> might 
> > include unnecessary liability beyond regular bugs then that's a problem 
> for 
> > me. 
>
> Both Go and GCC get an advantage from using widely-used and 
> well-understood free software licenses.  Making any modification to 
> those licenses would force every large organization that wants to use 
> these tools to reanalyze the license to make sure it will be 
> acceptable.  So the place to change this, if you think there is a need 
> to change it, is not with individual projects, but with an umbrella 
> organization like the Free Software Foundation or the Open Source 
> Initiative. 
>
> 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.

Re: [go-nuts] Go license and fitness for purpose

[matthewjuran]

>
> Why would you assume more liability than necessary?


My thought is the authors want to gain serious users to increase feedback 
quality and improve the developer market. I thought this was why Google let 
Go be open source besides attracting academic uses.

And as an open source developer who does not get paid, I feel better if 
> I have no liability whatsoever. Now, if you were PAYING ME for my 
> services, then I will be happy to provide you with assurances that make 
> you feel better. 


I don't think this is the attitude behind GCC, or maybe it is. I want to 
write programs that do things worth money and hope to use Go or GCC to do 
so (including working with and on those projects for free), but if they 
might include unnecessary liability beyond regular bugs then that's a 
problem for me.

Matt

On Sunday, May 13, 2018 at 12:39:05 PM UTC-5, Matthias B. wrote:
>
> On Sun, 13 May 2018 08:56:08 -0700 (PDT) 
> matthe...@gmail.com  wrote: 
>
> > My tools are my responsibility, so I’m wondering what stops the GCC, 
> > Go, or other open source authors from including practical jokes. 
>
> That depends on the jurisdiction and the kind of practical joke. But 
> it's a fact that software has contained practical jokes in the past, in 
> particular in cases where the software determined that it was running 
> without a proper license. So this does indeed happen and I've not heard 
> of any developer being sued for it. 
>
> > These license terms seem to remove all responsibility, and in certain 
> > hands that is an opportunity to cause some chaos. Why isn’t there a 
> > license section about intention of code implementation matching 
> > stated goals? 
>
> Ask yourself: If you can choose between having NO LIABILITY and having 
> just a little bit of liability, which option do you choose? Why would 
> you assume more liability than necessary? Are you Jesus or Gandhi? 
>
> > 
> > THE AUTHORS OF THIS SOFTWARE DID NOT INTENTIONALLY MAKE MISTAKES OR 
> > INCLUDE PRACTICAL JOKES. 
> > 
> > I’m not a lawyer, but I’d feel better about these tools if there was 
> > something like that followed by the fitness disclaimer. 
>
> And as an open source developer who does not get paid, I feel better if 
> I have no liability whatsoever. Now, if you were PAYING ME for my 
> services, then I will be happy to provide you with assurances that make 
> you feel better. 
>
>
>
> MSB 
>
> -- 
> A naked man with a can of beans can eat only one meal 
> but play a hundred soccer games. 
>
>

-- 
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] Go license and fitness for purpose

[matthewjuran]

Hello,

The gccgo license has this section:

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


This seems like a common pattern in open source software. GCC files include 
this:

GCC is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> GNU General Public License for more details.


I’ve been using the MIT license which has this:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
> IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
> AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
> LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS IN THE SOFTWARE.


My tools are my responsibility, so I’m wondering what stops the GCC, Go, or 
other open source authors from including practical jokes. These license 
terms seem to remove all responsibility, and in certain hands that is an 
opportunity to cause some chaos. Why isn’t there a license section about 
intention of code implementation matching stated goals?

THE AUTHORS OF THIS SOFTWARE DID NOT INTENTIONALLY MAKE MISTAKES OR INCLUDE 
PRACTICAL JOKES.

I’m not a lawyer, but I’d feel better about these tools if there was 
something like that followed by the fitness disclaimer.

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] Re: Go could really use a while statement

[matthewjuran]

That would be funny to me.

I have been guilty of being disrespectful to people in person about their C 
code choices, but I thought it was justified because I was hoping to get 
good technical reasons in response and didn’t intend anything personally 
targeted. ‘Crusade’ was a word I’d use for what I cared about. Now I don’t 
think disrespect in service of collaboration is the right approach. I hope 
that backlash Rob mentioned doesn’t exist anymore.

Matt

On Saturday, May 12, 2018 at 1:44:33 PM UTC-5, Michael Jones wrote:
>
> I bet Rob wishes he'd done that after the code reviewer's objections.
>
> On Sat, May 12, 2018 at 8:20 AM  wrote:
>
>> It's certainly diverged from my original post, which is why I'm staying 
>>> quiet.
>>
>>
>> I was hoping to get back on track after you sent this so you’d want to 
>> participate.
>>
>> goto is another way to do loops in Go: 
>> https://play.golang.org/p/0chmb5DeOym
>>
>> Matt
>>
>> On Wednesday, May 9, 2018 at 4:26:44 PM UTC-5, Hugh Fisher wrote:
>>>
>>>
>>>
>>> On Thursday, May 10, 2018 at 4:20:41 AM UTC+10, Marc wrote:

 I'm still not convinced this topic is not some kind of elaborate joke.

>>>
>>> It's certainly diverged from my original post, which is why I'm staying 
>>> quiet.
>>>
>>> cheers,
>>> Hugh Fisher
>>>  
>>>
>> -- 
>> 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.
>>
>
>
> -- 
> Michael T. Jones
> michae...@gmail.com 
>

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

[go-nuts] Re: Go could really use a while statement

[matthewjuran]

>
> It's certainly diverged from my original post, which is why I'm staying 
> quiet.


I was hoping to get back on track after you sent this so you’d want to 
participate.

goto is another way to do loops in Go: https://play.golang.org/p/0chmb5DeOym

Matt

On Wednesday, May 9, 2018 at 4:26:44 PM UTC-5, Hugh Fisher wrote:
>
>
>
> On Thursday, May 10, 2018 at 4:20:41 AM UTC+10, Marc wrote:
>>
>> I'm still not convinced this topic is not some kind of elaborate joke.
>>
>
> It's certainly diverged from my original post, which is why I'm staying 
> quiet.
>
> cheers,
> Hugh Fisher
>  
>

-- 
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 could really use a while statement

[matthewjuran]

The lack of citations makes the content untrustworthy to me, but this 
English Wikipedia article on loops claims some history starting with the do 
loop in FORTRAN (1957): https://en.wikipedia.org/wiki/For_loop

This article says the three part for loop was introduced in C/C++ (1972), 
and container iteration was introduced in Maple (1980).

for e in c while w do
# loop body
od;

The people writing these articles claim “Do while”, “While”, “For”, 
“Foreach”, and “Infinite” are loop constructs. All of these are done by for 
in Go.

Another observation from this novice Go programmer: I'm puzzled why there's 
> no while statement.


I think “it was an arbitrary choice based on experience” might be the 
answer but I don’t know. I like having the one keyword.

Matt

On Tuesday, May 1, 2018 at 6:11:04 AM UTC-5, Hugh Fisher wrote:
>
>
> Another observation from this novice Go programmer: I'm puzzled why
> there's no while statement.
>
> I know it's possible to use a for, but it doesn't feel right to me. I 
> always
> think of for loops as for iterating over data structures. Originally just
> arrays, but languages like Python and Objective-C have extended for
> loops to other collections as well. "Looping until some condition is met"
> for me is a different control structure and needs a different keyword.
>
> There'd be overlap with the for statement, but if-then-else and switch
> with boolean case overlap too.
>
> And since while has been a reserved keyword in a lot of programming
> languages for many decades, I would bet a reasonable amount of
> money that a while statement could be added to Go right now and not
> break anyone's production code.
>
> cheers,
> Hugh Fisher
>
>

-- 
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 could really use a while statement

[matthewjuran]

I’m not sure if C has been directly mentioned. I started with C so 
iteration is just a nice shortcut to me. Assuming you’ve always had 
collection iteration available an explanation is the for loop can make the 
useful pattern of indexing into an array up to the length of the array 
using an index variable.

s := [5]int{0, 1, 2, 3, 4}
// this C-style iteration prints 12345
for i := 0; i < len(s); i++ {
fmt.Print(s[i]+1)
}

Coming from C it makes sense to me to combine all looping, including 
collection iteration, into one keyword. For, while, and do-while all look 
the same to me.

Matt

On Wednesday, May 9, 2018 at 4:26:44 PM UTC-5, Hugh Fisher wrote:
>
>
>
> On Thursday, May 10, 2018 at 4:20:41 AM UTC+10, Marc wrote:
>>
>> I'm still not convinced this topic is not some kind of elaborate joke.
>>
>
> It's certainly diverged from my original post, which is why I'm staying 
> quiet.
>
> cheers,
> Hugh Fisher
>  
>

-- 
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] Cyclic types

[matthewjuran]

More accurately:

const size = 10

type T struct {
a [size]int
// many other fields and comments
b [size*unsafe.Sizeof(int(0))]int
}

Matt

On Wednesday, May 9, 2018 at 1:56:53 PM UTC-5, matthe...@gmail.com wrote:
>
> type T struct {
> a [10]int
> b [len(T{}.a)]int
> }
>
> could appear about as maintainably like this:
>
> const size = 10
>
> type T struct {
> a [size]int
> // many other fields and comments
> b [size]int
> }
>
> This case doesn’t justify more complexity to me.
>
> Matt
>
> On Wednesday, May 9, 2018 at 1:00:34 PM UTC-5, gri wrote:
>>
>> PS: Here's an example where we (humans) can obviously compute the size of 
>> a type, yet neither cmd/compile, gccgo, nor go/types have any success in 
>> doing so:
>>
>> type T struct {
>> a [10]int
>> b [len(T{}.a)]int
>> }
>>
>> The problem is that all implementations have an "eager" (depth-first) 
>> approach somewhere leading to requiring all of T to be set up before we can 
>> determine the size of T.a. Specifically, when determining the size of T.b 
>> we must be careful to not look at the size of T (which is in the process of 
>> being determined), and only at the size of T.a (which we can obviously 
>> tell). Furthermore, we must use an algorithm that computes the size of T.a 
>> "on demand", not in the order as the fields appear (otherwise it wouldn't 
>> work if b was before a). And so forth. All these things make size 
>> computation more complicated and expensive. That question is: Is it worth 
>> the extra cost? Or are these cases esoteric and don't show up in real code? 
>> And if we use simpler algorithms, is there an easy way to describe which 
>> types are accepted and which aren't?
>>
>>
>> On Wed, May 9, 2018 at 10:00 AM Robert Griesemer  wrote:
>>
>>> This sounds all good.
>>>
>>> I am not disputing at all what you are saying, but a) the spec doesn't 
>>> actually state any of this explicitly; and b) I agree that size computation 
>>> is straight-forward once a type data structure is all constructed. The 
>>> caveat is the 2nd part of this sentence: We're not doing always a correct 
>>> job of setting up a type completely before it's used. Hence we have issues 
>>> like #25305. The compiler does a better job than go/types most of the time; 
>>> but sometimes it's the other way around.
>>>
>>> I think we also have been hesitant to simply disallow "cyclical types" 
>>> (per your definition of cyclical) in the spec because we (or at least I) 
>>> don't have a good understanding that our code actually detects exactly 
>>> those. We have plenty of examples of code where we could determine the 
>>> type's size but we still exclude the type. For instance
>>>
>>> type T = *T
>>>
>>> T has clearly the size of a pointer, yet we disallow (in the compiler) 
>>> such types. In this case it's by design (of the type alias proposal), but 
>>> it would be nice if we could relax it. But I'm not sure we (or I) 
>>> understand all the consequences fully, quite yet. And I think we have other 
>>> situations (not involving alias types) where we run into problems, even 
>>> though we can compute the type's size.
>>>
>>> (FWIW, I don't think everybody equates "cyclic type" with "type size is 
>>> not computable". People tend to use "cyclic" and "recursive" 
>>> interchangeably for types. I was definitively using "cyclic" as "recursive" 
>>> in #25305).
>>>
>>> More generally, I think it would be great if we could state exactly what 
>>> you said in the spec:
>>>
>>> 1) Types for which their sizes cannot be computed (see 2) are invalid.
>>> 2) The size of a type is computable if ... (and then we give essentially 
>>> the rules you outlined already).
>>>
>>> As said above, 2) requires all involved types to be set up sufficiently 
>>> such that we can determine the relevant size information. Sometimes that's 
>>> not the case. Hence my comment in the issue #25305.
>>>
>>> Finally, I agree that there shouldn't be a difference between cycle 
>>> detection by a human and a computer. But the problem is that the computer 
>>> may be using an algorithm that may be conservative, or incorrect, or not 
>>> very general (for the sake of speed in the common case).
>>>
>>> On Wed, May 9, 2018 at 1:21 AM Jan Mercl <0xj...@gmail.com> wrote:
>>>
 Robert Griesemer wrote in 
 https://github.com/golang/go/issues/25305#issuecomment-387624488 at 
 May 9th:

 I'm probably using incorrect assumptions. Let me summarize them here:


 1) A type is cyclical iff its size is not computable.


 I'm really not sure if this is what the specification really means. If 
 not then I wonder why not, because


 2) Determining computability of the size of a type is trivial (wrt "we 
 go through great lengths to detect such cycles").


 AFAICT, there are two classes of types.


 In the first (scalar) class the size of T is a constant fully 
 determined by the kind 

Re: [go-nuts] Cyclic types

[matthewjuran]

type T struct {
a [10]int
b [len(T{}.a)]int
}

could appear about as maintainably like this:

const size = 10

type T struct {
a [size]int
// many other fields and comments
b [size]int
}

This case doesn’t justify more complexity to me.

Matt

On Wednesday, May 9, 2018 at 1:00:34 PM UTC-5, gri wrote:
>
> PS: Here's an example where we (humans) can obviously compute the size of 
> a type, yet neither cmd/compile, gccgo, nor go/types have any success in 
> doing so:
>
> type T struct {
> a [10]int
> b [len(T{}.a)]int
> }
>
> The problem is that all implementations have an "eager" (depth-first) 
> approach somewhere leading to requiring all of T to be set up before we can 
> determine the size of T.a. Specifically, when determining the size of T.b 
> we must be careful to not look at the size of T (which is in the process of 
> being determined), and only at the size of T.a (which we can obviously 
> tell). Furthermore, we must use an algorithm that computes the size of T.a 
> "on demand", not in the order as the fields appear (otherwise it wouldn't 
> work if b was before a). And so forth. All these things make size 
> computation more complicated and expensive. That question is: Is it worth 
> the extra cost? Or are these cases esoteric and don't show up in real code? 
> And if we use simpler algorithms, is there an easy way to describe which 
> types are accepted and which aren't?
>
>
> On Wed, May 9, 2018 at 10:00 AM Robert Griesemer  > wrote:
>
>> This sounds all good.
>>
>> I am not disputing at all what you are saying, but a) the spec doesn't 
>> actually state any of this explicitly; and b) I agree that size computation 
>> is straight-forward once a type data structure is all constructed. The 
>> caveat is the 2nd part of this sentence: We're not doing always a correct 
>> job of setting up a type completely before it's used. Hence we have issues 
>> like #25305. The compiler does a better job than go/types most of the time; 
>> but sometimes it's the other way around.
>>
>> I think we also have been hesitant to simply disallow "cyclical types" 
>> (per your definition of cyclical) in the spec because we (or at least I) 
>> don't have a good understanding that our code actually detects exactly 
>> those. We have plenty of examples of code where we could determine the 
>> type's size but we still exclude the type. For instance
>>
>> type T = *T
>>
>> T has clearly the size of a pointer, yet we disallow (in the compiler) 
>> such types. In this case it's by design (of the type alias proposal), but 
>> it would be nice if we could relax it. But I'm not sure we (or I) 
>> understand all the consequences fully, quite yet. And I think we have other 
>> situations (not involving alias types) where we run into problems, even 
>> though we can compute the type's size.
>>
>> (FWIW, I don't think everybody equates "cyclic type" with "type size is 
>> not computable". People tend to use "cyclic" and "recursive" 
>> interchangeably for types. I was definitively using "cyclic" as "recursive" 
>> in #25305).
>>
>> More generally, I think it would be great if we could state exactly what 
>> you said in the spec:
>>
>> 1) Types for which their sizes cannot be computed (see 2) are invalid.
>> 2) The size of a type is computable if ... (and then we give essentially 
>> the rules you outlined already).
>>
>> As said above, 2) requires all involved types to be set up sufficiently 
>> such that we can determine the relevant size information. Sometimes that's 
>> not the case. Hence my comment in the issue #25305.
>>
>> Finally, I agree that there shouldn't be a difference between cycle 
>> detection by a human and a computer. But the problem is that the computer 
>> may be using an algorithm that may be conservative, or incorrect, or not 
>> very general (for the sake of speed in the common case).
>>
>> On Wed, May 9, 2018 at 1:21 AM Jan Mercl <0xj...@gmail.com > 
>> wrote:
>>
>>> Robert Griesemer wrote in 
>>> https://github.com/golang/go/issues/25305#issuecomment-387624488 at May 
>>> 9th:
>>>
>>> I'm probably using incorrect assumptions. Let me summarize them here:
>>>
>>>
>>> 1) A type is cyclical iff its size is not computable.
>>>
>>>
>>> I'm really not sure if this is what the specification really means. If 
>>> not then I wonder why not, because
>>>
>>>
>>> 2) Determining computability of the size of a type is trivial (wrt "we 
>>> go through great lengths to detect such cycles").
>>>
>>>
>>> AFAICT, there are two classes of types.
>>>
>>>
>>> In the first (scalar) class the size of T is a constant fully determined 
>>> by the kind of T: bool, integers, real and complex types, slices, 
>>> interfaces, pointers, maps, channels, functions. (The last three being just 
>>> a special case of a pointer.)
>>>
>>>
>>> In the second (non-scalar) class a type T has size dependent 
>>> (transitively) on other types (T_1, ... T_n), possibly including T itself. 
>>> Scalar T_i brings no 

Re: [go-nuts] Re: I don't know about callbacks in Golang

[matthewjuran]

The first approach with a func argument to a func can be synchronous (which 
is what I was thinking at the time) or it could be asynchronous by using 
the go keyword on the callback.

Matt

On Monday, May 7, 2018 at 11:48:20 AM UTC-5, florent giraud wrote:
>
> ok matthew so what you propose is sync method callback right ?
>
> 2018-05-07 17:24 GMT+02:00 :
>
>> Corrected mistake:
>>
>> func SignalsCallback(arg1 int, arg2 string, callback chan<- struct{})
>>
>> SignalsCallback will only write to callback, not read.
>>
>> Matt
>>
>> On Monday, May 7, 2018 at 10:08:27 AM UTC-5, matthe...@gmail.com wrote:
>>>
>>> Callbacks in Go can be done with a func argument to a func, or a similar 
>>> effect can be made with channels by triggering a callback action by waiting 
>>> on a blocking channel in the application. This Wikipedia article describes 
>>> the pattern: 
>>> https://en.wikipedia.org/wiki/Callback_(computer_programming)
>>>
>>> // this func executes callback at some point
>>> // you can specify any func signature for callback when you construct 
>>> your own func that calls back
>>> func CallsBack(arg1 int, arg2 string, callback func())
>>>
>>> // this func sends a signal on callback that you listen for on another 
>>> goroutine to execute your callback action
>>> // SignalsCallback may block until callback is read by you, or if the 
>>> chan is buffered it may continue without callback being read
>>> func SignalsCallback(arg1 int, arg2 string, callback <-chan struct{})
>>>
>>> The difference is that CallsBack will execute callback in order, while 
>>> SignalsCallback will continue concurrently after callback is read by your 
>>> goroutine.
>>>
>>> Matt
>>>
>>> On Friday, May 4, 2018 at 7:53:13 PM UTC-5, Eduardo Moseis Fuentes wrote:

 HI everyone I´m Eduardo from Guatemala and I'm beginer. I'm  
 interesting in all scope golang in fact  I was download a little book 
 about 
 it, but I need learn more about callbacks because the book don´t has 
 enough 
 information on callbacks. May somebody  tell me where can I  find more 
 information?. HELP ME PLEASE  THANKS God Bless 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
>- FLORENT GIRAUD
>- mail : *fgi...@student.42.fr *
>- tel : *06.62.56.10.85*
>
>
>

-- 
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: I don't know about callbacks in Golang

[matthewjuran]

Corrected mistake:

func SignalsCallback(arg1 int, arg2 string, callback chan<- struct{})

SignalsCallback will only write to callback, not read.

Matt

On Monday, May 7, 2018 at 10:08:27 AM UTC-5, matthe...@gmail.com wrote:
>
> Callbacks in Go can be done with a func argument to a func, or a similar 
> effect can be made with channels by triggering a callback action by waiting 
> on a blocking channel in the application. This Wikipedia article describes 
> the pattern: https://en.wikipedia.org/wiki/Callback_(computer_programming)
>
> // this func executes callback at some point
> // you can specify any func signature for callback when you construct your 
> own func that calls back
> func CallsBack(arg1 int, arg2 string, callback func())
>
> // this func sends a signal on callback that you listen for on another 
> goroutine to execute your callback action
> // SignalsCallback may block until callback is read by you, or if the chan 
> is buffered it may continue without callback being read
> func SignalsCallback(arg1 int, arg2 string, callback <-chan struct{})
>
> The difference is that CallsBack will execute callback in order, while 
> SignalsCallback will continue concurrently after callback is read by your 
> goroutine.
>
> Matt
>
> On Friday, May 4, 2018 at 7:53:13 PM UTC-5, Eduardo Moseis Fuentes wrote:
>>
>> HI everyone I´m Eduardo from Guatemala and I'm beginer. I'm  interesting 
>> in all scope golang in fact  I was download a little book about it, but I 
>> need learn more about callbacks because the book don´t has enough 
>> information on callbacks. May somebody  tell me where can I  find more 
>> information?. HELP ME PLEASE  THANKS God Bless 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: I don't know about callbacks in Golang

[matthewjuran]

Callbacks in Go can be done with a func argument to a func, or a similar 
effect can be made with channels by triggering a callback action by waiting 
on a blocking channel in the application. This Wikipedia article describes 
the pattern: https://en.wikipedia.org/wiki/Callback_(computer_programming)

// this func executes callback at some point
// you can specify any func signature for callback when you construct your 
own func that calls back
func CallsBack(arg1 int, arg2 string, callback func())

// this func sends a signal on callback that you listen for on another 
goroutine to execute your callback action
// SignalsCallback may block until callback is read by you, or if the chan 
is buffered it may continue without callback being read
func SignalsCallback(arg1 int, arg2 string, callback <-chan struct{})

The difference is that CallsBack will execute callback in order, while 
SignalsCallback will continue concurrently after callback is read by your 
goroutine.

Matt

On Friday, May 4, 2018 at 7:53:13 PM UTC-5, Eduardo Moseis Fuentes wrote:
>
> HI everyone I´m Eduardo from Guatemala and I'm beginer. I'm  interesting 
> in all scope golang in fact  I was download a little book about it, but I 
> need learn more about callbacks because the book don´t has enough 
> information on callbacks. May somebody  tell me where can I  find more 
> information?. HELP ME PLEASE  THANKS God Bless 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.

Re: [go-nuts] [ANN] GoKi Trees and GoGi GUI

[matthewjuran]

>
> I’m pretty sure you can just type "go get …” and it finds all the 
> dependencies automatically, and they are likely to change over time, so I’m 
> not sure it is conventional to list them?


You may want to vendor them 
(https://golang.org/cmd/go/#hdr-Vendor_Directories) so if they ever go away 
or change API then your project will still work.

Matt

On Monday, May 7, 2018 at 1:05:13 AM UTC-5, Randall O'Reilly wrote:
>
> Steve — thanks for your impressions.  I’ll definitely contact you directly 
> when I get around to trying to integrate rasterx — I haven’t even had a 
> chance to look at it all, but a first question is when you expect it to be 
> stable and reasonably feature-complete?  e.g., one of the main things I 
> would love to be able to use in the GUI are gradients, and your 
> announcement mentioned that those were still pending? 
>
> I’m pretty sure you can just type "go get …” and it finds all the 
> dependencies automatically, and they are likely to change over time, so I’m 
> not sure it is conventional to list them?  For example, I just removed the 
> json-iterator dependency as it wasn’t even working, to make that list 
> smaller by a few.. 
>
> Re the all-platform GUI, it definitely seems tricky, and I’m developing on 
> a Mac and only spent a minimal amount of effort getting Linux and Windows 
> working, relative to the original Shiny framework.  Unfortunately on linux 
> any time you close a window it exits the event loop through some mechanism 
> that I have yet to find!  That is what is causing the lack of 
> responsiveness — if you just don’t close any windows, everything should 
> work fine :)  I’m pretty sure Shiny was only tested with a single window, 
> as there have been several issues related to that across the platforms. I 
> don’t see those text field editing issues you report — did you install the 
> MS TTF fonts?  I also removed the /usr/local/share/fonts path per 
> Wojciech’s comments — users can add via prefs if needed, so you shouldn’t 
> be seeing any font path issues on the most recent version. 
>
> One thing I’ve found so far is that the specific demands of the GUI logic 
> place specific demands on the OS-specific logic, so I’ve been happy to have 
> full control over that at the lowest level.  The Shiny framework provides a 
> really nice, maximally-Go-based OS-specific interface that I’ve easily been 
> able to modify per my needs, so I’m hopeful that with a bit more effort 
> things will be pretty smooth.. 
>
> Re the full-featured nature of the Ki nodes, one consideration is that 
> each node in the tree needs to support the relevant capabilities for them 
> to work properly: e.g., properties can be inherited, and signals need to 
> disconnect when a node has been deleted (and more generally, the node 
> signals like “Updated” are an essential part of the basic functionality, 
> and could not be made optional).  Also, I wanted to automatically support 
> things like JSON in the same way that a slice or map natively does, so an 
> end-user doesn’t have to struggle with all that themselves (and I don’t 
> ever have to deal with it again myself :)  Anyway, in my estimation, the Ki 
> node is minimal relative to the core desired functionality, but I’m very 
> open to specific suggestions about how it could be simplified or more 
> efficiently decomposed.  Cheers, 
>
> - Randy 
>
> > On May 6, 2018, at 2:11 PM, Steven Wiley  > wrote: 
> > 
> > It sure does look like you put a great deal of effort into this project. 
> Here are a couple of impressions after trying the demos and skimming 
> through part of the source code. 
> > 
> > First, I had to pull down a lot of other packages in order to get things 
> to build. Did you happen to write up a dependency list somewhere? It might 
> be helpful to list them in the readme so that fumblers like me won't have 
> to do it trail and error. (FYI: I just added the non-standard lib 
> dependency list to oksvg and rasterx.) Here are the additional packages I 
> needed for gi : 
> > • https://github.com/BurntSushi/xgb 
> > • https://github.com/chewxy/math32 
> > • https://github.com/go-gl/mathgl 
> > • https://github.com/goki/prof 
> > • https://github.com/jinzhu/copier 
> > • https://github.com/json-iterator/go 
> > • https://github.com/modern-go/reflect2 
> > • https://github.com/modern-go/concurrent 
> > Also, I noticed that you need a go version greater than 1.9.4. I was 
> getting a "math.Round not found" error until I upgraded to go1.10.2. 
> > 
> > 
> > 
> > So, once I got everything building, I was getting a few font path not 
> found errors during runtime. (OS: Fedora 27), but still text was visible. 
> Some things worked quite smoothly, like the transition from a simple panel 
> to a scrolling panel as a window was resized to smaller than the window 
> content.  Other things were not behaving so well, like typing text into a 
> 

[go-nuts] Re: fallthrough for select

[matthewjuran]

The proposal I opened for this was declined recently: 
https://github.com/golang/go/issues/23196

Matt

On Saturday, May 5, 2018 at 11:35:08 PM UTC-5, Simon Chevrier wrote:
>
> Hi, I know this is kind of old and I'm not sure anyone will answer, but 
> even after the previous discussion I feel like any kind of switch-like 
> statements should be able to fallthrough.
>
> The answer that it doesn't make sense because you're supposed to choose 
> between different available channel operations is not really a good point 
> because you could say the same thing for the switch statement.
> The switch statement is supposed to choose from a set of unique values, so 
> it doesn't make sense to fallthrough another value?
>
> My point is that the fallthrough operation allows us to define common code 
> for different cases, which could be really useful in any switch-like 
> statements.
>
> On Thursday, January 22, 2015 at 6:26:40 PM UTC-5, i3dmaster wrote:
>>
>> In Go, select and switch statements are similar just that select is 
>> specific for channel multiplex operations. The fallthrough statement is 
>> defined to flow the control to the next case statement, upon reading the 
>> lang spec, it does not seem that specific to the "switch" statement, but 
>> yet for some reason, it is only defined for switch.
>>
>> Anyway, maybe someone could enlighten me a bit as of why we have chosen 
>> not to support fallthrough in select. And just for my greedy heart, can we 
>> add it to select...
>>
>

-- 
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: [ANN] GoKi Trees and GoGi GUI

[matthewjuran]

In a generic container I would expect to see items typed as interface{} and 
the behavior defined on a slice of interface{} or struct with private slice 
of interface{} field.

>From the godoc it looks like type Node implements type Ki, and there’s no 
other type that implements Ki. I don’t understand why this is necessary, 
why not just define the methods on type Node?

* But a diversity of functionality at each node (i.e., many different 
> possible node types) 


My thought is this calls for a type Node interface, then there would be 
more types that implement Node. This line of thinking may lead to similar 
code to what you have already, I’m not sure.

The addition of a type registry was extremely simple and I don’t see any 
> “maintenance and reliability burden” engendered by this design (but maybe 
> I’m missing something?).


You may not be missing anything. My experience is that general purpose 
libraries can be more work than they’re worth, but that doesn’t mean yours 
is. Here’s a generic container library I wrote and hope to use in the 
future (I haven’t put it back into the project it came from yet): 
https://github.com/pciet/unordered

I appreciate you taking my feedback into consideration, and I appreciate 
that you are working on making and sharing good Go programs.

Thanks,
Matt

On Saturday, May 5, 2018 at 1:51:35 AM UTC-5, Randall O'Reilly wrote:
>
> Here’s a few responses to some of the overall “Smell” issues, and per 
> Wojciech’s comments I don’t really do blogging but here are just a few of 
> the “lessons learned / issues confronted” in this effort.  Overall the ONLY 
> thing I would change about Go based on my experience so far is some of the 
> messaging / docs that appear to go too far in attempting to distance itself 
> from OOP and C++ paradigms.  In my experience, you can have the best of 
> everything in Go, and sometimes a more standard OOP class hierarchy is 
> exactly the right solution for a given problem (see below). 
>
> First, the essential requirements for a scene graph, and structural trees 
> of that sort more generally, are: 
>
> * A common API for navigating, managing the tree 
>
> * But a diversity of functionality at each node (i.e., many different 
> possible node types) 
>
> Thus, a common embedded base type that does all the basic tree stuff seems 
> like the most natural solution.  Trees are not one-off things where a 
> simple “Stringer” kind of paradigm is going to work.  They are containers, 
> but unlike Go’s builtin, “privileged” containers with their magic generics 
> functionality, they also naturally have a lot more complexity to them, and 
> although my initial thoughts about this were that maybe Go2 could have a 
> native tree container, I now think that doesn’t make sense.  The Ki tree 
> was really easy to build on top of slices, and slices do all the actual 
> containing work — the rest of it is just all the hierarchical 
> infrastructure, which someone else might want to do differently, and 
> definitely doesn’t belong as built-in to the language. 
>
> I also think the following functionality for a robust “tree” system is 
> essential: 
>
> * An “end user” (in an app, or through a GUI) should be able to create 
> nodes of any type at any point in the hierarchy, through some kind of 
> general-purpose “InsertNewChild” kind of method, which takes as an arg the 
> type of child to create. 
>
> * The tree should automatically support basic infrastructure such as JSON 
> saving / loading, copying parts of the tree, etc. 
>
> This then introduces a lot of “generics” kinds of demands, but I found the 
> combination of the interface and reflect mechanisms entirely adequate (if 
> sometimes maddeningly frustrating in the case of reflect) for this job. 
>  The addition of a type registry was extremely simple and I don’t see any 
> “maintenance and reliability burden” engendered by this design (but maybe 
> I’m missing something?).  Any new node type must be registered, so it is an 
> extra line of code, but it is a simple, clear one, easy to copy/paste.  I 
> also ended up adding a “New” function for each node because I was hitting 
> massive slowdowns in reflect.New at one point (which turned out to just be 
> the GC and nothing about reflect per say, and I minimized those by getting 
> rid of all unnec. pointers) — could get rid of that and go back to 
> reflect.New if people think that makes more sense? 
>
> One key trick for getting the most flexibility out of an Interface is to 
> keep a “This” interface pointer of the struct in the struct itself (e.g., 
> see ki.Node.This) — you can then ensure full virtual function calling in 
> any method just by doing: 
>
> n.This.Function() 
>
> It works great and always calls the properly overridden version of the 
> interface Function() defined for the actual type of object in question.  I 
> had a bit of an email discussion in this group with Ian about this back in 
> March, and he emphasized how you 

Re: [go-nuts] Implementing method overloading using first class functions

[matthewjuran]

>
> I sorta only vaguely understand what you mean about being 'too big'.


I’m being vague and I haven’t read this thread in detail besides seeing 
type B in the first email. I plan to read it in detail and send another 
response. I’m speaking from the idea behind a version of this story: 
http://cs.txstate.edu/~br02/cs1428/ShortStoryForEngineers.htm

Matt

On Friday, May 4, 2018 at 5:28:30 PM UTC-5, Louki Sumirniy wrote:
>
> I sorta only vaguely understand what you mean about being 'too big'. I 
> only have 4 comparators, 5 walk operators and a small collection maybe 
> around 8 helper functions. But now that I'm working with inter-convertible 
> slice types, I don't have to do any interfaces in fact. I only have 5 types 
> I actually need to use now, byte, uint8, 16, 32 and 64. I can use switch 
> blocks to implement each one depending on the data being worked on. There 
> won't be any package scoping issues either nor any closure scoping issues 
> as I won't need to do this, the configurations in the main struct will be 
> used as conditions in the switches.
>
> Scoping and side effects from it were causing me huge headaches up to now. 
> Data was not being read or written to the right locations and I couldn't 
> figure out why, something to do with interfaces and package scoping I 
> think. None of this will be a problem as I kinda don't even need to use 
> type interfaces at all, I will try to avoid this. It's a very low level 
> code I will be writing, something that will evoke halcyon days of assembly 
> programming, but with GC, type safety and neat infix operators.
>
> On Saturday, 5 May 2018 00:26:11 UTC+3, matthe...@gmail.com wrote:
>>
>> With byte slices you’ll need to pay attention to reallocation of the 
>> backing array as a possible source of performance problems (
>> https://blog.golang.org/go-slices-usage-and-internals).
>>
>> I can see clearly how freakin complex code gets when you try to do 
>>> generics and polymorphism.
>>
>>
>> I think it’s only complex because you’re not using the best possible 
>> idioms. For example I mentioned in the other thread that I think your 
>> interface is too big. Have you thought of other ways to do the typing?
>>
>> Perhaps try another language like Rust?
>>
>>
>> I think Go could work.
>>
>> Matt
>>
>> On Friday, May 4, 2018 at 1:45:52 PM UTC-5, atomly wrote:
>>>
>>> Perhaps try another language like Rust?
>>>
>>> atomly
>>>
>>> On Fri, May 4, 2018 at 10:44 AM, Louki Sumirniy <
>>> louki.sumir...@gmail.com> wrote:
>>>
 Well after bashing my head against a brick wall I finally understand 
 what a mess it is for my specific purpose to work with Go. Nobody really 
 specifically said it in any discussions up to now but what my design needs 
 is generics. If code generation could be done more transparently I could 
 use that but it really kicks interactivity and flow in the nuts. I'm going 
 to probably abandon Golang on this basis. I am inclined to go with C but I 
 am nervous about  issues relating to pointers and runtime breaks but oh 
 well. . 

 If there was a way to transparently add code generation that would be 
 sufficient and remain type safe. *sigh*

 The biggest headache I am running up against is that between packages. 
 I think that before I throw in the towel I am going to study exactly how 
 the sort package is implemented, since in essence my library does the same 
 thing, so maybe I just don't understand well enough how to use interfaces, 
 embedding and composition.


 On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote:
>
> Yep, you are correct, more or less. My code is using interfaces and 
> panicking when it's fed the wrong thing.
>
> For example, in my test I had a literal number going into a write 
> function to put a value into a node in the tree. The insert 
> implementation 
> panicked saying it couldn't put an int into a uint32 slot. Eventually I 
> worked out it was the assumed int typing of the literal causing the 
> problem 
> (happens all the time, I should be used to it by now).
>
> The thing is, it is intended that the user of the type specific 
> library that imports the tree library will not make a type assumption 
> like 
> the compiler did about a literal. The type specific part has to be 
> written 
> for any given type. There is a little verbosity in the part that wraps 
> the 
> injected functions with syntactic sugar so the base library has the 
> functions to work on the concrete data agnostic of its content and only 
> the 
> return values provided by the functions it gets to do various comparisons 
> and whatnot. It's not excessively wordy for my tastes and I know it's 
> doing 
> it the best way possible.
>
> It's just learning how to play with interfaces that I was struggling 
> with and I seem to have 

[go-nuts] Re: Is there any #blog which writes about how to succeed as a fresher Go programmer?

[matthewjuran]

I’m assuming you’re asking how to make a career around Go.

For a career you might be best served by blogs about general software 
development or software engineering. Others here may be able to point you 
in the right direction for blogs. I’m not sure if “software” is still the 
best word for it.

Often these jobs will require ability to work in more than one programming 
language and with varying kinds of computing systems. Go is like a hammer 
and you probably won’t be hired as just a hammer operator.

A university might be the most straightforward career maker. I like 
electrical engineering specializing in computer programming, but computer 
science is another route to software work. Some universities may offer 
direct software degrees.

Being a software professional is not the only way to use programming, you 
may find Go or other languages help you with information work applied to 
another career.

Matt

On Friday, May 4, 2018 at 2:06:51 PM UTC-5, heyi...@gmail.com wrote:
>
> Is there any blog which writes about how to succeed as a new Go coder? 
>
> I mean: 
>
> - How should one learn Go and make his/her career? 
> - What should one do after learning Go? 
> - How should one get/find job as freshman Go programmer? 
> - and what skills should one have to land to his first Go programming Job 
> as starter? 
>
> Please suggest some good blogs if you know, because it will be very 
> helpful to me to follow the right way/track.

-- 
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] Implementing method overloading using first class functions

[matthewjuran]

With byte slices you’ll need to pay attention to reallocation of the 
backing array as a possible source of performance problems 
(https://blog.golang.org/go-slices-usage-and-internals).

I can see clearly how freakin complex code gets when you try to do generics 
> and polymorphism.


I think it’s only complex because you’re not using the best possible 
idioms. For example I mentioned in the other thread that I think your 
interface is too big. Have you thought of other ways to do the typing?

Perhaps try another language like Rust?


I think Go could work.

Matt

On Friday, May 4, 2018 at 1:45:52 PM UTC-5, atomly wrote:
>
> Perhaps try another language like Rust?
>
> atomly
>
> On Fri, May 4, 2018 at 10:44 AM, Louki Sumirniy  > wrote:
>
>> Well after bashing my head against a brick wall I finally understand what 
>> a mess it is for my specific purpose to work with Go. Nobody really 
>> specifically said it in any discussions up to now but what my design needs 
>> is generics. If code generation could be done more transparently I could 
>> use that but it really kicks interactivity and flow in the nuts. I'm going 
>> to probably abandon Golang on this basis. I am inclined to go with C but I 
>> am nervous about  issues relating to pointers and runtime breaks but oh 
>> well. . 
>>
>> If there was a way to transparently add code generation that would be 
>> sufficient and remain type safe. *sigh*
>>
>> The biggest headache I am running up against is that between packages. I 
>> think that before I throw in the towel I am going to study exactly how the 
>> sort package is implemented, since in essence my library does the same 
>> thing, so maybe I just don't understand well enough how to use interfaces, 
>> embedding and composition.
>>
>>
>> On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote:
>>>
>>> Yep, you are correct, more or less. My code is using interfaces and 
>>> panicking when it's fed the wrong thing.
>>>
>>> For example, in my test I had a literal number going into a write 
>>> function to put a value into a node in the tree. The insert implementation 
>>> panicked saying it couldn't put an int into a uint32 slot. Eventually I 
>>> worked out it was the assumed int typing of the literal causing the problem 
>>> (happens all the time, I should be used to it by now).
>>>
>>> The thing is, it is intended that the user of the type specific library 
>>> that imports the tree library will not make a type assumption like the 
>>> compiler did about a literal. The type specific part has to be written for 
>>> any given type. There is a little verbosity in the part that wraps the 
>>> injected functions with syntactic sugar so the base library has the 
>>> functions to work on the concrete data agnostic of its content and only the 
>>> return values provided by the functions it gets to do various comparisons 
>>> and whatnot. It's not excessively wordy for my tastes and I know it's doing 
>>> it the best way possible.
>>>
>>> It's just learning how to play with interfaces that I was struggling 
>>> with and I seem to have pretty much got it all figured out now.  I'm happy 
>>> with how the code is developing and pretty much joyous that I can do this 
>>> inside a type safe language. Type safety is a big part of how Go is such a 
>>> fast compiling language. Implicit casts and inheritance have a massive cost 
>>> in complexity not just a naive translation to binary code, but also in 
>>> optimising it. When can it cut out the dereferencing to methods and when 
>>> not? Since one could be using a method to do a relatively simple thing, in 
>>> very long, tight loops, if the OOP compiler guesses wrong and puts 
>>> dereferences in where they are not needed, it's a big cost over 1 million 
>>> iterations compared to being aware of it, like in my code, and avoiding the 
>>> need for dereferencing.
>>>
>>> I firmly believe that Go could replace C as a language to write systems 
>>> kernels in. I saw an amusing post recently relating to Dan Larimer's work 
>>> on EOS mentioning an automated code correctness checking application for 
>>> C++... Having intimately dealt with Dan's C++ source code, I can see why he 
>>> might be waking up to this, especially with the ether leaks going on, that 
>>> EOS has inherited (literally, I presume).
>>>
>>> This would not happen if it were written in Go. Note also that Geth 
>>> lacks this problem and there was almost going to be a split over code 
>>> changes from the Go side.
>>>
>>> Linus Torvalds famously said he wrote the Git CVS in C specifically to 
>>> exclude C++ programmers. But as any avid gopher would know, C has all kinds 
>>> of gotchas to do with busting out of stacks, heaps, allocated memory, and 
>>> forgetting to free memory. This does not happen in Go. 
>>>
>>> So to cut a long story short, this is why I choose to program in Go. I 
>>> have a background in low level programming, I used to do a bit of M68k 
>>> 

[go-nuts] Re: [ANN] GoKi Trees and GoGi GUI

[matthewjuran]

Hi Randy, here’s a code review.

Thanks for the BSD license.

I prefer the look of a minimized import path, I would have put the title 
library at the top level (github.com/goki/ki).

To me the README doesn’t balance text and code examples well enough, I’d 
like to see more example uses and less text. In package ki I’d hope the 
library does enough work to not require so much README.

I think ki isn’t a bad package name after reading what it means but seeing 
the package used in app code won’t show the point as obviously as an 
English word for some people. tree.New() to me says “new data structure 
var” while ki.New() says “I have to read the docs now”.

(when I say 'app' I mean a program that uses your library or a program 
written to compile with a Go compiler; an application of the library, an 
application of the Go programming language)

The Ki interface is a code smell to me. Usually I interpret library 
interfaces as saying “the app provides an implementation of the interface 
and the library provides shared logic that uses the interface methods” or 
in this case I expect the ki lib will provide varying data structures and 
behaviors that implement the ki var. Just reading down to line 42 of ki.go 
I feel like this isn’t very Go-like.

You’re getting into generics territory with this:

func NewOfType(typ reflect.Type) Ki {

My view is idiomatic Go code tends to avoid this kind of thing due to 
maintenance and readability burden. I haven’t used your lib but I am 
concerned about it not being a big win over a per-app implementation. I can 
see you’ve done a lot of work to make generics work.

In type Node I would consider embedding Props.

I haven’t looked at all of the methods but do the methods on Node need to 
be to a pointer?

func (n *Node) Fields() []uintptr {

Seeing uintptr in a public method is a code smell to me.

In type Deleted consider maybe embedding sync.Mutex.

// fmt.Printf("finding path: %v\n", k.Path)

Instead of comments you may want to consider this pattern:

const debug = false
…
if debug {
fmt.Printf("finding path: %v\n", k.Path)
}

I think this library would be a good study for the Go 2 
(https://blog.golang.org/toward-go2) generics effort, if you have time 
consider writing an experience report and posting it: 
https://github.com/golang/go/issues/15292

Perhaps consider embedding ki.Signal in gi.Action, and MakeMenuFunc, 
ki.Signal, *Icon, and ButtonStates in ButtonBase, some fields in ColorView, 
Dialog, FillStyle, FontStyle, LayoutStyle, LayoutData, Layout, MapView, 
MapViewInline, Node2DBase, Paint, ImagePaintServer, SliceView, 
SliceViewInline, SliderBase, SplitView, StrokeStyle, StructView, 
StructViewInline, BorderStyle, ShadowStyle, Style, TabView, TextStyle, 
TextField, SpinBox, ComboBox, TreeView, ValueViewBase, Viewport2D, Window. 
I like to avoid any unnecessary field symbols.

These kinds of structs are a code smell to me:

type ColorValueView struct {
ValueViewBase
}

Why a Base type? Can your types be simpler?

type Node2D and type ValueView seem like other possible overuses of 
interface to me. The size of type PaintServer is closer to what I’d expect 
with an interface, and Labeler seems idiomatic.

I like the screenshot.

// check for interface implementation
var _ Node2D = {}

I don’t like this pattern.

Given the amount of code and project maturity I wouldn’t expect you to make 
a lot of changes, but I do think it could have been built with a stronger 
resilience to change. Thanks for sharing here.

Matt

On Friday, May 4, 2018 at 5:39:35 AM UTC-5, Randall O'Reilly wrote:
>
> https://github.com/goki/goki — key demo in: 
> https://github.com/goki/goki/tree/master/gi/examples/widgets 
>
> This is the first release of a new Go framework built around the Tree as a 
> core data structure (Ki = Tree in Japanese), which includes as its first 
> application a fully-native Go GUI (built on top of a modified version of 
> the Shiny OS-specific backend drivers, supporting Mac, Linux, and Windows 
> so far). 
>
> Building on the central idea in Go that having a few powerful 
> data-structures is essential for making many problems easier to solve, the 
> GoKi trees are an attempt to provide a powerful tree structure that can 
> support things like scene graphs, DOM’s, parsing trees, etc. 
>
> The GoGi graphical interface system is a kind of “proof is in the pudding” 
> test, which weighs in at under 20k LOC and provides a reasonably 
> full-featured GUI — with a bit more work it should be able to do most of 
> the stuff you can do in Qt, and already includes a (self) reflection-driven 
> GUI designer. 
>
> The overall design is an attempt to integrate existing standards and 
> conventions from widely-used frameworks, including Qt (overall widget 
> design), HTML / CSS (styling), and SVG (rendering). Rendering in SVG is 
> directly supported by the GoGi 2D scenegraph, with enhanced functionality 
> for interactive GUI's. This 2D framework also 

[go-nuts] Re: Go could really use a while statement

[matthewjuran]

>
> These threads are akin to bike shedding thus a waste of time.


In storytelling relief is part of good tragedy.

I consider the overloading of for to be a plus because for, while, do-while 
are just loops with conditions. Maybe ‘loop’ is a more Go-like keyword.

loop i, e := range c {

Matt

On Thursday, May 3, 2018 at 8:46:36 AM UTC-5, M P r a d e s wrote:
>
> Can anybody point me to a single discussion on golang-nuts that led to a 
> significant syntax change? These threads are akin to bike shedding thus a 
> waste of time. 
>
> Adding while provide nothing of value in a language that supports basic 
> looping. And for those who compare if and switch arguing it is equivalent, 
> you can't do type switches with an if statement.
>
> This is discussion is going nowhere.
>

-- 
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 go programmers for game company

[matthewjuran]

I may be interested. Can you share background about your company here?

Thanks,
Matt

On Saturday, April 28, 2018 at 10:52:01 PM UTC-5, smga...@gmail.com wrote:
>
> Hey gophers. I have a multi platform game company that is also integrating 
> blockchain technology as well as crypto currency. I am looking for one or 
> two full time GO programmers. We are in Los Angeles but are running most 
> people remote. If you are a mid to high level programmer and interested, 
> please let me know. 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: Beginner question about interface

[matthewjuran]

grep -r ") Read(" .

If you have grep this works ok (-r to recursively look in directories) if 
you want to isolate one method.

Matt

On Saturday, April 28, 2018 at 12:06:07 AM UTC-5, k1at...@gmail.com wrote:
>
> Hi
>
> How can i get a list of types which implement a particular interface ? ( 
> for exmaple io.Reader)
>
> Thank you in advance 
> Attila
>
>

-- 
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: Using variadic function / context in an interface?

[matthewjuran]

Each call to Run could check if the struct has been initialized and 
initialize it if not. An approach is a function field could be swapped out 
after initialization.

Matt

On Thursday, April 26, 2018 at 11:55:07 AM UTC-5, Nimrod Shneor wrote:
>
> Hey everyone,
> I've encountered a design issue - 
> I have an the following interface -
>
> type Runner interface {
>   Run(x X,y Y)
> }
>
> I want to add to it an Init(...) method which will initialize the internal 
> fields of the Runner before performing `Run`..
> My issue is that different structs implementing the `Runner` interface 
> require different fields in order to initialize, How should I solve this?
>
> Thanks a lot!
> Nimrod.
>

-- 
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] Article: Go for art

[matthewjuran]

Hello,

Here’s an article I’ve written about Go: https://github.com/pciet/goforart

“Go for art. An article about the Go programming language and greater 
professional software community.”

I wrote this today but there is a lot of research built into it. There is 
discussion about religion, and you might consider the article U.S.A. 
propaganda. I try to keep those out of my emails here. For some people this 
might be a good introduction to computer programming or the online Go 
community.

I’m happy to discuss any points although maybe the points about Go are the 
most appropriate.

Thanks,
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] [ANN] oksvg and rasterx; SVG 2.0 path compliant renderer and rasterizer

[matthewjuran]

>
> So it sounds like the AGPL is a good license to choose if you want to keep 
> your code from being used by big companies… ;-)


If your project is secret software with a public network interface then 
don’t apply the AGPL to it. That’s not the only kind of software used at 
big companies.

Matt

On Wednesday, April 25, 2018 at 12:25:24 PM UTC-5, Andy Balholm wrote:

> So it sounds like the AGPL is a good license to choose if you want to keep 
> your code from being used by big companies… ;-)
>
> On Apr 25, 2018, at 8:48 AM, 'David Chase' via golang-nuts <
> golan...@googlegroups.com > wrote:
>
>
>
> On Tuesday, April 24, 2018 at 10:45:35 AM UTC-4, matthe...@gmail.com 
> wrote:
>>
>> I’m curious if some companies juggle the GPL. I guess if the app is used 
>> internally only then there’s no problem with accidentally requiring a 
>> proprietary program to be released as source code to the world. I’d have 
>> thought the case would be the same with the AGPL. Do people count as 
>> individuals in a corporate license with the ability to freely redistribute?
>>
>> I can understand completely avoiding the issue. Language is interpretable 
>> and only a court or whatever would decide what was really agreed to. The 
>> FSF seems to put a lot of work into building up their licenses with legal 
>> precedence.
>>
>
> I have never worked anywhere that could touch AGPL code.
> It was at the level of "just don't, and don't waste anyone's time asking.  
> Don't."
> This is not legal advice, I am just telling you what the policy is/was at 
> all these companies.
>
>
>
> -- 
> 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.

Re: [go-nuts] Type func binding and interfaces

[matthewjuran]

>
> Any code that keeps data aligned to memory page and disk page sizes is 
> automatically significantly faster, because misalignment automatically 
> doubles the amount of memory that has to be accessed to satisfy a request. 
> This is why Binary Heaps are way slower than B-heaps.


My opinion is without measurement you will miss necessary knowledge found 
between assumptions. The package testing benchmark has non-obvious features 
for repeatable data: 
https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go

I see you have logic tests 
(https://github.com/calibrae-project/bast/blob/master/pkg/bast/bast_test.go), 
and benchmarks are another step.

Matt

On Wednesday, April 25, 2018 at 9:37:48 AM UTC-5, Louki Sumirniy wrote:
>
> Always the elements are inserted according to greater than and less than. 
> equal can't happen. The first value inserted will be the root to begin 
> with, but if the tree gets heavy on one side, you rotate the root to 
> rebalance. from any given node, you know that you will find the element you 
> are looking for according to the node you are at, and its greater or less 
> than test. You can know this is always going to be true because that's how 
> the inserts will populate the tree, and the 'completeness' constraint 
> enforces a requirement for the 'bunching up' of data. So long as there is 
> space between two nodes, they can be as high up in the tree as the distance 
> between them, each row downwards allows a power of two sequence of 
> increasing numbers. The 'completeness' constraint is extended by not 
> allowing orphans, every child has a parent, until you get to the root, so 
> vice versa, you know that you will find every element in the tree by 
> walking downwards and going left or right depending on greater than and 
> less than, this is the comparability constraint. You should be able to see 
> that a number of architectural features in this data storage system imply 
> heuristics for optimisation.
>
> Just to update, reading about B-heaps and how it structures storage, I 
> realised that I need to think of the tree in terms of 4kb blocks (well, for 
> most platforms) as this is the amount of memory that will be accessed in 
> one operation. However many rows a payload size fits into 4kb is the size 
> of each subtree. So for 32 bit values, I have one page at the top, and then 
> 1024 pages that are the left and right pairs of the 512 elements at the 
> bottom of the first page, and, of course, this repeats again. This changes 
> how I have to implement the walk functions, as when it overflows past 512, 
> I know I have moved to the second page-row.
>
> So... I have to kinda go back to the drawing board a little on the 
> structuring of the algorithm since it is working on 4kb page sizes. I may 
> have to switch up the design so that the pages are the primary indices of 
> the first dimension, and then the pages themselves, the subtrees, can be 
> allocated as fixed length arrays, which also simplifies how Go will deal 
> with them. Further, instead of allocating whole rows at a time, only those 
> rows that have been breached require allocation of a new page for a 
> subtree. In this respect, then the question about search cost becomes a 
> little different, since we use 4k pages, and we know walking them goes on 
> inside 14Gb/s SRAM cache, performance optimisation by tree balancing has a 
> somewhat different character than the Binary Heap linear mapping.
>
> Why do I seem so confident about the performance of this, potentially? 
> Look up B-heaps and Varnish reverse proxy. It is designed at the low level 
> with the same basic concept in mind, using B-heaps - structure the heap 
> segments according to memory pages. If you are familiar with filesystems, 
> you may know about block alignment. It's not quite so important for 
> spinning disks but for flash and S/DRAM, memory is only ever handled on the 
> hardware level in these block sizes. Disks usually use 512 byte blocks in 
> the FS level and generally most disks have 512 byte blocks, some have 1k, 
> 2k, 4k or 8k. Most current generation FS's use 4k blocks as the default 
> size, for the reason it is a 1:1 mapping with memory pages.
>
> The difference with what I am designing is that it does not order 
> vertically, it orders horizontally. It's basically fractal, each subtree 
> has the same number of potential subtrees below it.
>
> Any code that keeps data aligned to memory page and disk page sizes is 
> automatically significantly faster, because misalignment automatically 
> doubles the amount of memory that has to be accessed to satisfy a request. 
> This is why Binary Heaps are way slower than B-heaps.
>
> Anyway, because many of my assumptions based on my conceptual model have 
> changed, and big thanks to you guys, I have to rework the design to account 
> for this. Thanks :p
>
> On Wednesday, 25 April 2018 15:11:15 UTC+3, rog wrote:
>>
>> On 25 April 2018 at 10:24, Louki Sumirniy 
>> 

Re: [go-nuts] Type func binding and interfaces

[matthewjuran]

>
> I worked for a little while on the C++ server application for the Steem 
> network node, and I was intending to remove a whole swathe of code relating 
> to protocol changes at various hard forks. The number of times I ran across 
> poorly ordered if/then (not even using switch!) that would perform 
> unnecessary comparisons in more cases than not, to me it explained the 
> ballooning amount of time that was required to play the blockchain into a 
> database shared file. 


What I’ve been saying is you should look at a performance measure to prove 
a hypothesis like this one. Removing that code may or may not work.

I think you’ve mixed optimizing the algorithm and code, and we have to look 
at one at a time to effectively reach your goal. A program that measures 
progress toward the goal (performance) is a foundation I think we can more 
seriously start from for the code part. Can you share something like this 
with us?

Matt

On Wednesday, April 25, 2018 at 4:08:17 AM UTC-5, Louki Sumirniy wrote:
>
> I think that it's not necessarily non-idiomatic to use closures instead of 
> interfaces in Go, it's more that Go has had interfaces longer than it's had 
> closures, and so more code has been written this way.
>
> In Angular 2+ you have the option of embedding HTML, CSS and TS code 
> inside one file, or instead having 4, with the main file importing the 
> other three. I don't like this for several reasons, but mainly because it 
> makes a more complex interlinking between them, and I think even you can 
> say that if your application is big enough, all this extra import work will 
> also cost a lot of time, though in Go of course that time is not so big in 
> the first place due to how efficient its compiler is.
>
> The way I see it is that closures and interfaces are two ways to do 
> exactly the same thing, binding namespaces together. One requires more 
> accessory declarations and lines of code, not a huge extra overhead, but 
> then for exported stuff - well, this is the one upside of it but I don't 
> think it is that great, gofmt wants to see header comments on every 
> exported function. Which is a nice idea, in theory, but in my opinion if 
> you need comments your naming scheme sucks.
>
> That's also why I created distinct comparators with meaningful names 
> instead of creating named return values. b.IsEqual(data, cursor) compared 
> to b.Compare(data, cursor) == EQUAL is not just a lot longer, but harder to 
> read. I think technically it may also consume more code cache space to 
> implement this extra operation, though on the other side, there is a small 
> extra overhead for having three instead of 1. The compare function has to 
> run three cases, most concisely expressed as 
>
> switch{
> case b.Store(c.index)>d: 
> return GREATER; 
> case b.Store(c.index) return LESSER
> }
> return EQUAL 
>
> If my function only needs to know if it's equal (for example a search tree 
> walk), it's just done two comparison/branch operations for absolutely no 
> reason, and if I switch the order to benefit search, I raise the cost of 
> determining which direction to step next after no match on a node.
>
> I worked for a little while on the C++ server application for the Steem 
> network node, and I was intending to remove a whole swathe of code relating 
> to protocol changes at various hard forks. The number of times I ran across 
> poorly ordered if/then (not even using switch!) that would perform 
> unnecessary comparisons in more cases than not, to me it explained the 
> ballooning amount of time that was required to play the blockchain into a 
> database shared file. Literally, over a week, at that point, almost 9 
> months ago, and last I heard 270Gb of memory is required because this 
> playback takes a stupid amount of time (effectively, eternity) unless the 
> shared file is stored in a ramdisk.
>
> So, just to be clear, I am not using OOPish techniques because I am a 
> believer, and I don't think that convention should dictate effective 
> programming either. Closures are a more compact notation than interfaces, 
> and for me this is equally important as writing code that does not waste 
> cycles doing things for the sake of some arbitrary model that does not 
> greatly improve maintainability and readability at the cost of overhead 
> that will stack up the more this approach is used.
>
> Heaps have certainly got some disadvantages compared to bucket sorts and 
> reference based trees but the one thing they have is data locality. Data 
> locality can be a huge advantage because of CPU cache misses being avoided. 
> Cache memory on my i5 CPU is 14Gb/s write speed. The DDR4-2400 memory in my 
> system writes at 4Gb/s. This is linear writing, in the case of the main 
> memory, so not only does conventional binary tree architecture cause a very 
> high bandwidth load on the main memory, it also seeks the data randomly 
> which adds even 

Re: [go-nuts] [ANN] oksvg and rasterx; SVG 2.0 path compliant renderer and rasterizer

[matthewjuran]

I’m curious if some companies juggle the GPL. I guess if the app is used 
internally only then there’s no problem with accidentally requiring a 
proprietary program to be released as source code to the world. I’d have 
thought the case would be the same with the AGPL. Do people count as 
individuals in a corporate license with the ability to freely redistribute?

I can understand completely avoiding the issue. Language is interpretable 
and only a court or whatever would decide what was really agreed to. The 
FSF seems to put a lot of work into building up their licenses with legal 
precedence.

Matt

On Tuesday, April 24, 2018 at 9:19:58 AM UTC-5, Zellyn wrote:
>
> On Tuesday, April 24, 2018 at 9:38:36 AM UTC-4, matthe...@gmail.com wrote:
>>
>> For Go you may want to consider the AGPL which also requires any network 
>>> app to provide its source code. These GNU licenses are from the Free 
>>> Software Foundation which has a traditionally radical philosophy toward 
>>> computers: https://www.gnu.org/licenses/why-affero-gpl.en.html So far I 
>>> personally like the AGPL approach.
>>
>>
> Nobody at Google (or many other companies) can touch anything AGPL.
>
> 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.

Re: [go-nuts] Type func binding and interfaces

[matthewjuran]

>
> I'd suggest starting with the basic algorithm without any abstraction 
> (just hard-code in the type you want to store), then benchmark/tweak 
> the algorithm, and only then try to make it general. 


This is my conclusion too. Abstracting the code is a lot of churn if we’re 
not sure performance without abstraction works. We’ll be able to help on 
the Go front better with a foundation.

Matt

On Tuesday, April 24, 2018 at 9:22:21 AM UTC-5, Louki Sumirniy wrote:
>
> Reading through the wikipedia description of a heap, and especially a 
> binary heap... it's a heap. But that's not a sexy name! Technically it's 
> not a heap because it sorts left to right, heaps sort bottom to top.
>
> I am stripping down my code and directly declaring the struct variables as 
> function types, and I will be removing the method-interface completely, as 
> I don't need it. I will be able to then isolate the external interface 
> functions and 'hide' the internals while being able to easily link the 
> scope of functions to the structure.
>
> If I really need a secondary value to flag empty or not, then the memory 
> efficient way would be to have a bit-indexed flag for this property, so for 
> every 32 bits of data one bit of flag and keep this in an orthogonal entry 
> in the structure. You are correct, though the odds are small, probably 
> 1/2^40 for 32 bit hashes making zeros, that kinda works out to 2^32/2^40 
> frequency of all zeroes and I think that amounts to 0.390625% being zero. 
> That would have been a problem! So for 30 rows of 32 bits I will need 2^30 
> array elements, 2^30/8 bytes to store the empty/fill. I can't think of a 
> more space efficient way to store this property. About 134Mb would be 
> required for this, based on 30 rows. It can, however, be extended at the 
> same time as the tree so its size will keep this proportion linear to the 
> size of the tree array, it's not a big overhead compared to the 4Gb the 30 
> row store will use.
>
> If it seems like this is excessive numbers, this stores 1/4 of the total 
> magnitude of possible values of 32 bit hashes, or half hashes. In the 
> application I have in mind, probably most of the time trees won't grow to 
> more than about 15 rows anyway, which is not that much, before the required 
> pattern is found in a hashchain, at least until the number of miners on the 
> network gets really big. I am writing a Proof of Work algorithm and I was 
> aiming for something that would scale down to short time periods at low 
> difficulty.
>
> This tree store would satisfy that by allowing solutions to pop out at a 
> particular sequence in a hash chain derived from a nonce, and so workers 
> would be able to find solutions in a much more temporally distributed 
> manner than occurs with Cuckoo Cycle and Equihash, which both use array 
> sorts to do their searches. Hence the reason for using this type of 
> structure. And the reason for wanting to use a compact underlying storage 
> is precisely about maximising the caching efficiency in the CPU, because I 
> want to write a solver that can't be sped up significantly with a faster 
> memory bus and/or memory cell retrieval latency (and further, retrieval 
> latency in memory cells still has a minor but significant amount of extra 
> latency for random access, thus wanting to reduce the memory footprint, and 
> increase linearity). It makes absolutely no sense to use a reference based 
> binary tree for values that are as small as the references themselves, as 
> this implies automatically a 4x size of memory required.
>
> ok. again, big thanks for your help with this, I really will stop 
> ruminating, I promise!
>

-- 
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: About start with Capital letter as public API and golang's no generic

[matthewjuran]

Here's the generics discussion: https://github.com/golang/go/issues/15292

Matt

On Tuesday, April 24, 2018 at 9:06:10 AM UTC-5, Deven You wrote:
>
> I am a newbie on Golang and find go syntax is pretty concise and I like it.
>
> However,  the syntax for public API seems a little trouble for me.
>
> Whenever I import a package, say:
> import dwu
>
> I need use a var or function with Capital first letter identifier:
>
> dwu.MyFunction
> dwu.MyVar
>
>
> I wonder since we can not use private lower case started identifier within 
> a package, perhaps we can just make a set of rules for how to control 
> referencing a package public memeber:
>
> 1. function and var and types directly from primitive type
>we can just use lower case to use them like:
> dwu.myFunction
> dwu.myVar
> dwu.integer
>
> //definition of above
> // dwu.go
> package dwu
>  
> funcMyFunction(...)...
> var MyVar :="..."
> type Integer int
>
> Inside the dwu.go we just can not define the same identifiers which only 
> differentiate from first letter cases like myFunction, myVar, integer etc.
>
> 2. Struct and interfaces still remain the Captial letters
>
> // dwu.go
> ...
> type Foos truct{
> ...
> }
>
> type Less interface{
> ...
> }
>
> //use dwu
> var afoo Foo=...
> var aless Less= ...
>
>  3. We can enforce the use of upper and lower first letters
>
> type Integer+ int//can only refernce it with dwu.Integer
>
> type Integer- int// can only reference it with dwu.integer
>
> type -Integer int // private identifier within dwu, but must use it as: 
> var a Integer = 1
>
>
>
>  I think using as many as possible lower case started API is more 
> convenient and with the point 3 we still have full control of how we 
> reference the public API.
>
> I also find golang with no generic syntax. Maybe this is for the original 
> difficulty or complexity of generic. But sometimes, generic is indeed 
> useful. A common case is for add() for any numeric types. 
>
> I think we can invent different but more simple syntax to achieve the same 
> behavior of generic. Here is my little thoughts:
>
> In C++:
>
> template 
> T add(T first, T second) {
>return first+ second;
> }
>
> In Go:
>
> func add(first as a Addable, second a.type) { // or (first Addable as 
> Atype, second Atype)
>var result a.type
>return first + second // or first.add(second) if Go won't support 
> operator overload in any future version
> }
>
> We just use a.type or Atype to ensure first and second belong to one 
> certain same type which implements the Addable interface.
>

-- 
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] [ANN] oksvg and rasterx; SVG 2.0 path compliant renderer and rasterizer

[matthewjuran]

>
> On the other hand oksvg is completely de novo, so I can slap whatever 
> license I want on that package. I take it people here prefer the Go 
> license? Can anyone briefly describe the difference? I will definitely 
> change it if someone can give me a good reason.  I just want to make it as 
> convenient and useful as possible for everyone.


Don’t consider golang-nuts for professional advice. Here’s my understanding:

GPL requires that if the code is distributed or included in a distributed 
application (source or binary) then the entirety of the source code is also 
distributed and the license remains. “Viral” is a term associated with GPL, 
if you use a GPL library then your entire project must become GPL compliant.

For Go you may want to consider the AGPL which also requires any network 
app to provide its source code. These GNU licenses are from the Free 
Software Foundation which has a traditionally radical philosophy toward 
computers: https://www.gnu.org/licenses/why-affero-gpl.en.html So far I 
personally like the AGPL approach.

My understanding is the source inclusion is only in effect in distribution. 
If you give your program to a person then that doesn’t require you to post 
it all on GitHub, but if you have a website where anybody can download your 
app then you have to make the source code available to all of those people. 
Note that GitHub also has a default license applied to your work which 
allows people to fork it and view it on GitHub.

I usually see the MIT, BSD, Apache licenses here. These give you permission 
to use the code without requiring you distribute the source code. There may 
be attribution requirements and usually the license says something about no 
warranty or support provided. If you want your library used here you’ll 
probably want one of these.

Matt

On Monday, April 23, 2018 at 7:19:59 PM UTC-5, Steven Wiley wrote:
>
> Thanks for the compliments, everyone.
>
> I will check out the vector package and further test SVG examples are 
> welcome.  If I have isolated concepts as well as I hope I have, re-writing 
> the Scanner to use the vector package might not be too hard. Gradients are 
> also near the top of the to-do list, because they are just so darn pretty. 
>
> As for the license part of it...(snnzz.., huh, what?) Oh yes, the 
> rasterx package has parts that are straight copies, and parts that are 
> somewhat modified from the freetype raster package, as well as parts that 
> are completely new. So, I think I need to stay within the terms of the 
> freetype license for that bit. Apparently, freetype wants derivatives  to 
> use their license, or GPL 2.0 or higher, so I just selected  the highest 
> GPL open on github, and also kept around a copy of their terms.
>
> On the other hand oksvg is completely *de novo*, so I can slap whatever 
> license I want on that package. I take it people here prefer the Go 
> license? Can anyone briefly describe the difference? I will definitely 
> change it if someone can give me a good reason.  I just want to make it as 
> convenient and useful as possible for everyone.
>
> On Monday, April 23, 2018 at 3:42:55 PM UTC-7, Nigel Tao wrote:
>>
>> Nice!
>>
>>
>> On Mon, Apr 23, 2018 at 3:41 AM, Steven Wiley  
>> wrote:
>>
>>> I refactored and enhanced the raster package from  the golang 
>>> translation of freetype, 
>>>
>>
>> It'd be a bunch of work, but you might consider basing off of 
>> golang.org/x/image/vector instead:
>>
>> 1. Its technique is based on "Inside the fastest font renderer in the 
>> world" at 
>> https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445
>>  
>> although rasterizing SVG images might perform differently than rasterizing 
>> font glyphs. Both are vector graphics, but SVG images often have multiple, 
>> overlapping shapes while font glyphs are typically simpler.
>>
>> There's also 
>> https://github.com/golang/exp/blob/master/shiny/iconvg/internal/gradient/gradient.go.
>>  
>> It's currently pretty slow, as I wanted to get the API right before 
>> optimizing the implementation, then haven't really had the free time to 
>> work on it since. But you might find it (and IconVG in general) interesting.
>>
>> 2. Its license is the Go license (i.e. BSD-like, 
>> https://github.com/golang/image/blob/master/LICENSE), not the 
>> Freetype-or-GPL2+ license (
>> https://github.com/golang/freetype/blob/master/LICENSE). OTOH, if you 
>> really want GPL3, then perhaps golang/freetype is a better foundation. 
>> Disclaimer: I am not a laywer, this is not legal advice, etc.
>>
>

-- 
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 lang best practices and git repo structure for newbies

[matthewjuran]

Hi Teja,

I found Effective Go to be generally helpful: 
https://golang.org/doc/effective_go.html

Here’s my best example: https://github.com/pciet/wichess

My golang-nuts code review points:

- don’t overuse interface (consider closures and function types/fields)
- don’t overuse packages, make more files in the same package first
- focus on the godoc presentation
- consider struct embedding
- slices are more efficient and readable than maps for some kinds of 
unordered sets
- a struct of pointers is similar to a pointer to a struct
- profile before making any choice away from easy code

For newbies:

- Writing computer programs with if, for, types, functions, and libraries 
is an art that many people might like. What Go brings is less wading 
through mud than C, Java, and scripting languages.
- Pointers are a hard part of Go and you should learn them well enough to 
not have any pointer questions. Map and interface vars are pointers, and a 
slice has a pointer to the array (a slice is a struct).
- stackoverflow.com, golang.org, golang-nuts, and Dave Cheney's blog are 
good resources among others.

Matt

On Monday, April 23, 2018 at 12:39:10 PM UTC-5, vteja...@gmail.com wrote:
>
> Hello,
>
> I was quite new to go lang. It would be good if anyone can help with best 
> practices and practical git repo structure example for getting inspiration 
> to kick start.
>
> Thanks,
> Teja
>

-- 
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: Type func binding and interfaces

[matthewjuran]

Is the need for a memory efficient implementation backed by a performance 
profile?

Matt

On Monday, April 23, 2018 at 10:26:41 AM UTC-5, Louki Sumirniy wrote:
>
> First issue is that BAST does not use references. This is so that searches 
> proceed linearly through memory. Instead it uses a flat array that it cuts 
> into sequentially doubling sized rows, representing the slots that a binary 
> tree has.
>
> Secondly, you just complicated my design even further with 'is left 
> equal'. why not just 'go left' 'is this equal'?
>
> The implementation of the comparison could be different for all kinds of 
> reasons. Number one reason that is already on my plan of action is where I 
> have an arbitrary bit-width data, say 64 bits, but I want to sort one tree 
> by the first 32 bits, and the same data feed into another tree at the same 
> time that searches/sorts by the second 32 bits. This is the main reason for 
> needing this flexibility. Mainly I want to stick to small blobs of memory, 
> just numbers, mostly, but that at least includes 256 bit values. Much 
> beyond that will destroy the advantage of this scheme, in that the tree 
> will be too big in memory because of how large the probably 1/4 to 
> half-filled node collection will generally be.
>
> On Monday, 23 April 2018 17:28:09 UTC+3, matthe...@gmail.com wrote:
>>
>> But I don't want to tie my users down to integers and floats. What if 
>>> they want to sort strings? What if they want to sort complex numbers, 
>>> matrixes, or what have you?
>>
>>
>> This is what the interface concept was made for.
>>
>> Why would the implementation of IsLeft be different if the BAST data is 
>> organized another way? I think the abstraction you're expressed isn't 
>> narrow enough.
>>
>> I don’t know the BAST details, but why not start here?
>>
>> type Node struct {
>> Element
>> Left  *Node
>> Right *Node
>> }
>>
>> func (a Node) LeftEqual() bool {
>> if a.Left == nil {
>> return false
>> }
>> return a.Equal(a.Left.Element)
>> }
>>
>> type Element interface {
>> Equal(Element) bool
>> Null() bool
>> }
>>
>> Matt
>>
>> On Monday, April 23, 2018 at 8:55:14 AM UTC-5, Louki Sumirniy wrote:
>>>
>>> I did look at the Red/Black tree on Github and that was what got me 
>>> started. But you need to understand exactly why those functions seem great 
>>> in number. First of all, of course you could swap out 3 of those 
>>> comparators for 1, and you probably don't even get why there is the 'empty' 
>>> one. The datatype uses zero as a null value, as it is aimed at hashes and 
>>> pretty much nothing hashes to zero (99.% to understate it). 
>>>
>>> In the code the caller would have to use, and this starts with my own 
>>> code, so I am considering my own capacity to decode my code versus writing 
>>> it in such a way that it is simple to understand. If I collapse those three 
>>> functions into one, I either have to define a set of constants to put a 
>>> human readable name on it - or, for a very small cost of maybe 10-15 bytes 
>>> extra, human can read the code and know what it does and why it isn't 
>>> incorrect. When you look further down to see what these functions are 
>>> actually implemented with, you'll discover they are mostly one-liners. On 
>>> the micro scale, it might seem making separate calls for these is a waste. 
>>> But on the other side, if my caller code has to run a 3 level or longer 
>>> if/then or switch/case, did I, as the programmer of the library, do my 
>>> users (my fellow programmers) any favours? Nope!
>>>
>>> With this, the user can just say 'b.IsLeft(number, cursor)'. Sure, maybe 
>>> there is no point in even having more than two conditions, since !IsLeft is 
>>> the same as IsRight. But what if I wanted to descend the sort order. Then 
>>> my code is riddled with '!IsRight' while I am trying to travel left. It's 
>>> not good for the reader, and not good to read is hard to maintain, hard to 
>>> maintain is expensive, and probably will be replaced by something else 
>>> later. Reusability is very important for low level functions. It would be 
>>> better for everyone if someone did the job right, first time, and for a 
>>> long time afterwards, everyone can depend on it.
>>>
>>> And coming back full circle to how I came up with this, it was precisely 
>>> by reading the cryptic and difficult to understand code of others, like 
>>> that Red/Black tree. Computer programming is a heavy cognitive load task as 
>>> it is. Arbitrary concepts of efficiency that don't take account for the 
>>> cost of decoding the results of this theory tend to lead to reinventing the 
>>> wheel, because the wheel was too cryptically constructed to simply modify 
>>> it.
>>>
>>> 
>>>
>>> The IsNull function is actually just a way of implementing x == 0. But I 
>>> don't want to tie my users down to integers and floats. What if they want 
>>> to sort strings? What if they want to sort complex numbers, matrixes, or 

[go-nuts] Re: Type func binding and interfaces

[matthewjuran]

>
> But I don't want to tie my users down to integers and floats. What if they 
> want to sort strings? What if they want to sort complex numbers, matrixes, 
> or what have you?


This is what the interface concept was made for.

Why would the implementation of IsLeft be different if the BAST data is 
organized another way? I think the abstraction you're expressed isn't 
narrow enough.

I don’t know the BAST details, but why not start here?

type Node struct {
Element
Left  *Node
Right *Node
}

func (a Node) LeftEqual() bool {
if a.Left == nil {
return false
}
return a.Equal(a.Left.Element)
}

type Element interface {
Equal(Element) bool
Null() bool
}

Matt

On Monday, April 23, 2018 at 8:55:14 AM UTC-5, Louki Sumirniy wrote:
>
> I did look at the Red/Black tree on Github and that was what got me 
> started. But you need to understand exactly why those functions seem great 
> in number. First of all, of course you could swap out 3 of those 
> comparators for 1, and you probably don't even get why there is the 'empty' 
> one. The datatype uses zero as a null value, as it is aimed at hashes and 
> pretty much nothing hashes to zero (99.% to understate it). 
>
> In the code the caller would have to use, and this starts with my own 
> code, so I am considering my own capacity to decode my code versus writing 
> it in such a way that it is simple to understand. If I collapse those three 
> functions into one, I either have to define a set of constants to put a 
> human readable name on it - or, for a very small cost of maybe 10-15 bytes 
> extra, human can read the code and know what it does and why it isn't 
> incorrect. When you look further down to see what these functions are 
> actually implemented with, you'll discover they are mostly one-liners. On 
> the micro scale, it might seem making separate calls for these is a waste. 
> But on the other side, if my caller code has to run a 3 level or longer 
> if/then or switch/case, did I, as the programmer of the library, do my 
> users (my fellow programmers) any favours? Nope!
>
> With this, the user can just say 'b.IsLeft(number, cursor)'. Sure, maybe 
> there is no point in even having more than two conditions, since !IsLeft is 
> the same as IsRight. But what if I wanted to descend the sort order. Then 
> my code is riddled with '!IsRight' while I am trying to travel left. It's 
> not good for the reader, and not good to read is hard to maintain, hard to 
> maintain is expensive, and probably will be replaced by something else 
> later. Reusability is very important for low level functions. It would be 
> better for everyone if someone did the job right, first time, and for a 
> long time afterwards, everyone can depend on it.
>
> And coming back full circle to how I came up with this, it was precisely 
> by reading the cryptic and difficult to understand code of others, like 
> that Red/Black tree. Computer programming is a heavy cognitive load task as 
> it is. Arbitrary concepts of efficiency that don't take account for the 
> cost of decoding the results of this theory tend to lead to reinventing the 
> wheel, because the wheel was too cryptically constructed to simply modify 
> it.
>
> 
>
> The IsNull function is actually just a way of implementing x == 0. But I 
> don't want to tie my users down to integers and floats. What if they want 
> to sort strings? What if they want to sort complex numbers, matrixes, or 
> what have you? I can't overload the equality operator, and even if I could, 
> then there would be the issue of type inference, implicit casts, or the 
> wordiness of explicit casts. Instead, the IsNull is already typed to the 
> data you want to work with, it can have something other than zero as its 
> null sentinel, or in other words, my slightly wordy interface means your 
> sleek, svelte application that is easy to debug.
>
> On Monday, 23 April 2018 16:25:17 UTC+3, matthe...@gmail.com wrote:
>>
>> This is a code smell for me:
>>
>> type BAST interface {
>> AddRow() error
>> IsLeft(interface{}, Cursor) bool
>> IsRight(interface{}, Cursor) bool
>> IsEqual(interface{}, Cursor) bool
>> IsEmpty(Cursor) bool
>> …
>>
>> Interfaces should be small. This looks like a class definition which 
>> isn’t a Go pattern. Also I would avoid interface{} if possible, and the 
>> function types seem more complicated than necessary. I’m not convinced your 
>> types/API are optimal.
>>
>> I still don’t exactly understand the goal, but this is my thinking about 
>> the playground example: https://play.golang.org/p/KNdrYbebpuo
>>
>> Matt
>>
>> On Monday, April 23, 2018 at 3:46:03 AM UTC-5, Louki Sumirniy wrote:
>>>
>>> I spent two hours wrestling with this, but as you can see in this 
>>> playground, the method I proposed totally works: 
>>> https://play.golang.org/p/FMvisWS9tuP
>>>
>>> I propose that the type builtin when dealing with functions should have 
>>> an extension made to it to 

[go-nuts] Re: Type func binding and interfaces

[matthewjuran]

This is a code smell for me:

type BAST interface {
AddRow() error
IsLeft(interface{}, Cursor) bool
IsRight(interface{}, Cursor) bool
IsEqual(interface{}, Cursor) bool
IsEmpty(Cursor) bool
…

Interfaces should be small. This looks like a class definition which isn’t 
a Go pattern. Also I would avoid interface{} if possible, and the function 
types seem more complicated than necessary. I’m not convinced your 
types/API are optimal.

I still don’t exactly understand the goal, but this is my thinking about 
the playground example: https://play.golang.org/p/KNdrYbebpuo

Matt

On Monday, April 23, 2018 at 3:46:03 AM UTC-5, Louki Sumirniy wrote:
>
> I spent two hours wrestling with this, but as you can see in this 
> playground, the method I proposed totally works: 
> https://play.golang.org/p/FMvisWS9tuP
>
> I propose that the type builtin when dealing with functions should have an 
> extension made to it to add the method binding to the type signature so 
> this workaround is not necessary. It would not break the spec, old code, or 
> any of the goals that Go works towards. It would actually help with getting 
> adoption by OOP programmers, in my view, because method overriding for this 
> exact purpose of enabling the abstraction of backend type stuff (in my case 
> it's just an array, but it could easily be a storage protocol or network 
> protocol) would help immensely in implementing pluggable architectures.
>
> On Monday, 23 April 2018 08:23:24 UTC+3, Louki Sumirniy wrote:
>>
>> https://github.com/golang/go/issues/24996#issuecomment-383424588
>>
>> It seems that (Type).FuncName in the assignment binds to the struct... I 
>> am glad I found an answer so quickly because my hackish solution was gonna 
>> be implemented today.
>>
>> On Monday, 23 April 2018 02:20:47 UTC+3, Louki Sumirniy wrote:
>>>
>>> You will see in the code I linked in the previous message that I already 
>>> do have the interfaces in there. They can't be bound to the struct directly 
>>> because I can't specify a function type that matches the signature, thus 
>>> the use of a wrapper, and the interface types in the parameters.
>>>
>>> I just can't override them, and the great bulk of the code is not these 
>>> small set of initialiser/allocator/comparator/getter/setter functions, so 
>>> to have to search and replace through the whole thing, and maintain 
>>> multiple nearly identical pieces of source code for the sake of 7 functions 
>>> that are all very short, and differ between these versions, when everything 
>>> else is the same... then I find a bug in one version, in the outer shell of 
>>> the code and I have to merge every change of it into the other 5 
>>> versions... it's extremely cumbersome. 
>>>
>>> The solution I have shown is just the first thing that looks to me like 
>>> it would work. I have read tons of tutorials about composition and 
>>> polymorphism and embedding in go, and in the end I pieced this together 
>>> from several different things I learned. I tried several different things. 
>>> It just makes absolutely no sense to have to go through and add a load of 
>>> maintenance work to my code just so I can create, expand, read, write and 
>>> compare values stored within the otherwise identical data structure.
>>>
>>> On Monday, 23 April 2018 01:44:43 UTC+3, matthe...@gmail.com wrote:

 Interface types are useful when the data structure is varied. Why not 
 an interface containing these varying functions as methods instead of 
 function types?

 Matt

 On Sunday, April 22, 2018 at 5:20:12 PM UTC-5, Louki Sumirniy wrote:
>
> I essentially am trying to find an effective method in Go, preferably 
> not too wordy, that lets me create an abstract data type, a struct, and a 
> set of functions that bind to a different data type, and that I can 
> write, 
> preferably not in too much code, a change that allows the data type of 
> the 
> embedded data to be changed. It's basically kinda inheritance, but after 
> much fiddling I found a hackish sorta way that isn't *too* boilerplate 
> filled:
>
> type nullTester func(*Bast, uint32) bool
>
> type Bast struct {
>   ...
>   isNullnullTester
>   ...
>  }
>
> func isNull(b *Bast, d uint32) bool {
>   return d == 0
> }
>
> func NewBast() (b *Bast) {
>   ...
>   b.isNull = isNull
>   ...
> }
>
> // IsNull - tests if a value in the tree is null
> func (b *Bast) IsNull(d uint32) bool {
>   return b.isNull(b, d)
> }
>
>
> Now, bear in mind I haven't shown all of the code. But there is a 
> slice array in the Bast struct, and I it is defined as an interface{} and 
> isNull is one of a set of operators that have to be written to match the 
> type used in the slice store, this might be a bad example because it 
> doesn't actually act on the interface typed slice, but 

[go-nuts] Re: Type func binding and interfaces

[matthewjuran]

Interface types are useful when the data structure is varied. Why not an 
interface containing these varying functions as methods instead of function 
types?

Matt

On Sunday, April 22, 2018 at 5:20:12 PM UTC-5, Louki Sumirniy wrote:
>
> I essentially am trying to find an effective method in Go, preferably not 
> too wordy, that lets me create an abstract data type, a struct, and a set 
> of functions that bind to a different data type, and that I can write, 
> preferably not in too much code, a change that allows the data type of the 
> embedded data to be changed. It's basically kinda inheritance, but after 
> much fiddling I found a hackish sorta way that isn't *too* boilerplate 
> filled:
>
> type nullTester func(*Bast, uint32) bool
>
> type Bast struct {
>   ...
>   isNullnullTester
>   ...
>  }
>
> func isNull(b *Bast, d uint32) bool {
>   return d == 0
> }
>
> func NewBast() (b *Bast) {
>   ...
>   b.isNull = isNull
>   ...
> }
>
> // IsNull - tests if a value in the tree is null
> func (b *Bast) IsNull(d uint32) bool {
>   return b.isNull(b, d)
> }
>
>
> Now, bear in mind I haven't shown all of the code. But there is a slice 
> array in the Bast struct, and I it is defined as an interface{} and isNull 
> is one of a set of operators that have to be written to match the type used 
> in the slice store, this might be a bad example because it doesn't actually 
> act on the interface typed slice, but the point here is just this:
>
> It does not appear to be possible to make the type specification from the 
> top line match the function signature of the type-bound function in the 
> bottom of the code snippet. I haven't been able to find anything that shows 
> that a func type can have a method binding.
>
> https://github.com/calibrae-project/bast/blob/master/pkg/bast/bast.go is 
> where my WiP lives. This slightly hacky solution seems sound to me, I just 
> don't like to be forced to use workarounds like this. If a type signature 
> cannot be written that matches a method, yet I can do it this way, I don't 
> see what purpose this serves as far as any kind of correctness and 
> bug-resistance issues go. I would have to deal with a lot more potential 
> bugs if I had to concretely implemennt this library for the sake of 1 slice 
> and 7 functions out of a much larger library that conceptually is intended 
> to only deal with comparable, mainly numerical values anyway.
>

-- 
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: Fancy Comments & Documentation

[matthewjuran]

gofmt and godoc remove choices that are fun, artistic, or tempting, but 
distracting. I think you'll be best served by Go without the box.

Matt

On Thursday, April 19, 2018 at 6:42:40 PM UTC-5, Chris FractalBach wrote:
>
> Test #1
> Source:
> /*
> +--+
> |   fancy box  |
> +--+
> package goexplore explores Go!
> */
> package goexplore
>
> Result:
>
>
> 
>
>
>
> Test #2
> Source:
> /*
> +--+
> |   fancy box  |
> +--+
> */
>
> /*
> package goexplore explores Go!
> */
> package goexplore
>
>
> Result:
>
>
> 
>
>

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

[go-nuts] Re: http "alt" attribute value for img tag?

[matthewjuran]

I would start by isolating the alt=“…” string with splits 
(https://golang.org/pkg/strings/#Split) then use Sscanf 
(https://golang.org/pkg/fmt/#Sscanf) to parse the number. There may be 
other approaches like regular expressions.

Matt

On Wednesday, April 18, 2018 at 9:52:28 PM UTC-5, l vic wrote:
>
> I need to get "alt" value from html "img" tag:
>
> 
> ...
> message
>
> 
>
> 
>
> 
>
>
> 
>
> What would be the correct way in Go to read "alt" values into array?
>
> 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: Extension for type assertion of interface array

[matthewjuran]

I think if you opened a proposal it would be merged into the generics 
discussion: https://github.com/golang/go/issues/15292

There may be other ways to write the program, can you provide a concrete 
example of where you’ve needed this?

Matt

On Wednesday, April 18, 2018 at 9:13:59 AM UTC-5, Sakthi Natesan wrote:
>
> Go supports below type assertion 
>
> t := i.(T)
> and 
> t, ok := i.(T)
>
> Can this feature be extended to array of interfaces as mentioned below?
>
> t := i.([]T)
> and 
> t, ok := i.([]T)
>
>
> I have been using Golang for almost four years and I have come across use 
> cases requiring this feature many times. So far, I write a function for 
> each specific case which clones the array into new array with type asserted 
> to new type. I repeat the same pattern of assertion for array of different 
> types and perform extra array copy each time I assert. Is there a better 
> alternative solution with existing Go feature or Is there a chance that 
> this feature will be supported in future?
>
> sample 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] Usage example inside a lib project

[matthewjuran]

An example directory works too and is pretty common.

Matt

On Wednesday, April 18, 2018 at 7:45:45 AM UTC-5, Federico Paolinelli wrote:
>
> Il giorno mercoledì 18 aprile 2018 08:41:30 UTC-4, Jan Mercl ha scritto:
>>
>> On Wed, Apr 18, 2018 at 2:35 PM Federico Paolinelli  
>> wrote:
>>
>> See https://golang.org/pkg/testing/#hdr-Examples. Put the examples into 
>> the foo_test.go file.
>>
>>
>>
> Oh, didn't realize that it was a convention. Thanks a lot! 
>

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

[matthewjuran]

Consider putting each ishell.Cmd in a separate file. Otherwise you can put 
them in a slice var so you don’t have to AddCmd each one explicitly.

I’m not sure what defining a struct accomplishes, can you provide more 
detail?

Matt

On Tuesday, April 17, 2018 at 8:25:17 PM UTC-5, Keith Brown wrote:
>
> I am writing an interactive CLI tool which looks like this, using 
> abisoft/ishell
>
> ./tool
> >>> help
>
> Sample Interactive Shell
> >>> help
>
> Commands:
>   clear  clear the screen
>   greet  greet user
>   exit   exit the program
>   help   display help
>
> >>> greet Someone Somewhere
> Hello Someone Somewhere
> >>> exit
>
> My tool will have many subcommands. 
>
> So, greet  < subcommand> and I was wondering what would be a good 
> way to structure the program. I was thinking of putting everything in one 
> large struct and have nested structs for commands similar to JSON encoded 
> file.
>
> any thoughts?
>
>

-- 
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: Concurrent and blocking data

[matthewjuran]

>
> 2. What does “concurrent and blocking” mean for a data structure?


I think this means they’re asking about a form of concurrent programming 
where a caller will stop executing (block) while the data structure is 
accessed by a concurrent path. Non-blocking means the caller can continue 
without the access completing.

Concurrent means multiple code paths (either interwoven on one processor 
core or happening parallel on multiple cores) can read or write a shared 
data structure at the same time without data corruption. A key point to 
this explanation is that the data is in one computer memory that is shared 
between the code paths, but concurrency may also apply in different ways to 
programs designed for networks of computers (distributed computing) or 
other kinds of computer/OS architectures.

The approach I know for “concurrent and blocking” is the mutex 
(https://golang.org/pkg/sync/#RWMutex). This approach is prone to deadlocks 
in some cases.

There’s formal definitions in the study of concurrency that I avoided, the 
concept has been written about since the 1960s. See 
https://en.wikipedia.org/wiki/Mutual_exclusion for a Wikipedia starting 
point.

3. What does accessing one var from concurrent goroutines look like?


Having a mutex is one way, either as a separate var or as part of the 
struct type, where a data interaction locks the mutex before accessing the 
data structure and unlocks it when done. With the Go sync.RWMutex any 
number of goroutines can read from a data structure concurrently, but if a 
write is happening then RLock will wait until the write completes (Unlock) 
before continuing (and Lock will wait for all RUnlock and Unlock to happen 
before continuing).

Another is to use channels. These block while waiting to be read, or they 
can be buffered, so they could be part of a blocking or non-blocking 
concurrent data structure. I’ll probably explore this approach in the 
future since it doesn’t require a standard library dependency like the 
mutex does.

Matt

On Monday, April 9, 2018 at 12:03:10 PM UTC-5, Robert Solomon wrote:
>
> I would like to know the answers to 2 and 3 
>
> I'm a relatively new gopher 
>
> On Mon, Apr 9, 2018, 12:59 PM Robert Solomon  > wrote:
>
>> I would like to know the answers to 2 and 3
>>
>> I'm a relatively new gopher 
>>
>>>

-- 
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: Interface Literals

[matthewjuran]

Here’s a way to do a similar thing now: 
https://play.golang.org/p/CtEYUo6MuqN

func main() {
x := []int{5, 1, 4, 2, 3}
sort.Sort(ClosureSort(func() int { return (len(x)) },
func(i, j int) bool { return x[i] < x[j] },
func(i, j int) { x[i], x[j] = x[j], x[i] }))
fmt.Print(x)
}

The inside func could take a struct instead of multiple arguments to keep 
the interface method names. It would be a straightforward package that 
could probably be simplified from this playground example.

Matt

On Sunday, April 8, 2018 at 1:35:06 PM UTC-5, Kenneth Duda wrote:
>
> Seven years later, I had the same idea as Js.
>
> Before:
>
> type intslice []int func (x intslice) Len() int { return len(x) } func (x 
> intslice) Less(i, j int) bool { return x[i] < x[j] } func (x intslice) 
> Swap(i, j int) { x[i], x[j] = x[j], x[i] } func main() { x := intslice{5, 
> 1, 4, 2, 3} sort.Sort(x) log.Print(x) }
> After: 
> func main() { x := []int{5, 1, 4, 2, 3} sort.Sort(sort.Interface{ Len() { 
> return(len(x)) }, Less(i,j int) { return x[i] < x[j] }, Swap(i,j int) { 
> x[i], x[j] = x[j], x[i] }, } log.Print(x) }
>
> In my opinion, the latter is more elegant, because I don't have to change 
> x's type to get the behavior I want, and because I can place the code that 
> satisfies the interface where I use the interface.  Like Js indicated, the 
> closure in which the interface literal is created would serve as the state 
> for the interface literal's implementation.
>
> Thanks,
>-Ken
>
> Kenneth Duda
>  
>

-- 
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: Concurrent and blocking stack

[matthewjuran]

1. What are a stack and queue?

2. What does “concurrent and blocking” mean for a data structure?

3. What does accessing one var from concurrent goroutines look like?

We can answer these for you if you don't know the answer.

Matt

On Sunday, April 8, 2018 at 12:37:26 AM UTC-5, Xen wrote:
>
> Hi everyone, I have this mock interview question, "How would you implement 
> concurrent and blocking stack and queue in Go?" which I have no idea on how 
> to answer it. If anyone can guild me
>

-- 
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: Language is a platform, which golang still does not pay attention to !!!

[matthewjuran]

>
> But it solves the common problem in the IT industry.


In my mind the major common problem is solved by computer hardware, not by 
a new programming language. Ordering machine instructions is doable for 
significant work.

My take is we’re mostly worried about art here besides those doing big data 
collection law enforcement or war applications. Those politics are 
important but I personally don’t want to view art through that lens, so 
I’ll assume Go is about art and getting to art. Maybe there will be use in 
peacefully exploring and exploiting the oceans, moon and other planets, or 
in safely automating transport, agriculture, and factories, but that kind 
of work requires rigor that is independent of programming language.

Programming computer hardware with explicit if, loops, functions, data 
structures, and libraries is an art that I think many people might like. 
What Go brings is less wading through mud than is expected as part of C, 
Java, or scripting languages.

I’m in the “make it popular” camp. I think Go solves the common problem of 
writing computer programs better than anything else.

Until now, programs written in golang still does not have binary 
> distribution format like jar, dll or so. People have to share libraries by 
> source code. It is so foolish.


But viewing the source code of others is the best way to be able to fix 
problems and improve skill. I believe in copyright and patent morals and I 
don’t think the state of Go libraries is completely foolish.

Matt

On Friday, April 6, 2018 at 12:36:28 AM UTC-5, T L wrote:
>
>
>
> On Thursday, April 5, 2018 at 6:32:46 PM UTC-4, matthe...@gmail.com wrote:
>>
>> I think if it is not popular until 2020, it will never be popular.
>>
>>
>> I’m not sure popularity is a shared goal in the community; the original 
>> goal is to solve problems at Google. 
>>
>
>> Matt
>>
>
> But it solves the common problem in the IT industry.
> Before Go, there are only two popular choices to do backend progrmaming, 
> Java (as a compiled langauge) and several dynamic languages.
> Now Go presents as an alternative to Java, with many advantages to Java.
>  
>
>>
>> On Thursday, April 5, 2018 at 12:26:19 PM UTC-5, bingj...@gmail.com 
>> wrote:
>>>
>>> Almost 10 years golang appears in the world. 10 years is not a short 
>>> duration. I think if it is not popular until 2020, it will never be popular.
>>>
>>> Golang is designed for cloud and internet areas. Really?
>>>
>>> The creators of golang have a lot of experience in C and C++. And golang 
>>> borrows features from C and C++. But C and C++ do not fit the requirements 
>>> of cloud and internet areas.
>>>
>>> Let's look at two popular programming languages java and php. What is 
>>> the most important features of these two languages? Simple, ugly but 
>>> practical... I find one feather: they are both not just programming 
>>> languages but also platforms. They are almost the same in Windows and 
>>> Linux. That's why java and php are very popular in recent days.
>>>
>>> C and C++ are just pure programming languages, not platforms. On Unix 
>>> and Windows, C and C++ are very different. A developer of windows C++ is 
>>> not a developer of UNIX C++, and a Linux C developer is not a Windows C 
>>> developer.
>>>
>>> If golang wants to be widely used by developer all over the world before 
>>> 2020, it must learn some thing from java and php, must be a 
>>> programming-language-is-a-platform.
>>>
>>> Until now, programs written in golang still does not have binary 
>>> distribution format like jar, dll or so. People have to share libraries by 
>>> source code. It is so foolish.
>>>
>>> Yes, Golang is very like C and C++, which are only pure programming 
>>> language, But this times, we need "language as/is platform" technologies, 
>>> just like php and java.
>>>
>>> I have watched golang for many years, but never turn to it. Why? I think 
>>> it is still semi-finished product. Creators of golang are researchers, not 
>>> engineers, they worked too slow.
>>>
>>

-- 
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: Language is a platform, which golang still does not pay attention to !!!

[matthewjuran]

>
> I think if it is not popular until 2020, it will never be popular.


I’m not sure popularity is a shared goal in the community; the original 
goal is to solve problems at Google.

Matt

On Thursday, April 5, 2018 at 12:26:19 PM UTC-5, bingj...@gmail.com wrote:
>
> Almost 10 years golang appears in the world. 10 years is not a short 
> duration. I think if it is not popular until 2020, it will never be popular.
>
> Golang is designed for cloud and internet areas. Really?
>
> The creators of golang have a lot of experience in C and C++. And golang 
> borrows features from C and C++. But C and C++ do not fit the requirements 
> of cloud and internet areas.
>
> Let's look at two popular programming languages java and php. What is the 
> most important features of these two languages? Simple, ugly but 
> practical... I find one feather: they are both not just programming 
> languages but also platforms. They are almost the same in Windows and 
> Linux. That's why java and php are very popular in recent days.
>
> C and C++ are just pure programming languages, not platforms. On Unix and 
> Windows, C and C++ are very different. A developer of windows C++ is not a 
> developer of UNIX C++, and a Linux C developer is not a Windows C developer.
>
> If golang wants to be widely used by developer all over the world before 
> 2020, it must learn some thing from java and php, must be a 
> programming-language-is-a-platform.
>
> Until now, programs written in golang still does not have binary 
> distribution format like jar, dll or so. People have to share libraries by 
> source code. It is so foolish.
>
> Yes, Golang is very like C and C++, which are only pure programming 
> language, But this times, we need "language as/is platform" technologies, 
> just like php and java.
>
> I have watched golang for many years, but never turn to it. Why? I think 
> it is still semi-finished product. Creators of golang are researchers, not 
> engineers, they worked too slow.
>

-- 
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: API fixes for sync.Mutex and friends?

[matthewjuran]

The pointer logic is a hard part of Go. I don’t know how much performance 
is gained by worrying about it, but I’ve learned to like having 
function/method call argument copies in some cases.

I think becoming an expert on when to pick a pointer or not is a 
fundamental part of Go programming. This shouldn’t be a subtle issue and 
working around it invites poor code.

Matt

On Monday, April 2, 2018 at 6:37:36 PM UTC-5, Andrew Pennebaker wrote:
>
> Some Go types like sync.Mutex have a subtle API issue, where the objects 
> really shouldn't be copied or passed around into different function calls, 
> e.g. to a goroutine worker. However, this is not enforced by the current 
> API, but merely mentioned in the documentation, which is easily ignored.
>
> Is there a way to better protect these types, so that users can't 
> accidentally copy and corrupt them? Maybe a linter or the Go compiler could 
> check for these types being passed in non-pointer form to function calls. I 
> wonder if this problem still appears in Rust, or if the borrow checker 
> could model this API distinction more safely and automatically?
>

-- 
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] corrupt stack?

[matthewjuran]

Does the program use cgo?

Matt

On Monday, April 2, 2018 at 6:48:14 PM UTC-5, Erik Quanstrom wrote:
>
> after upgrading to 1.9 (50% reduction) and finding a data race we didn't 
> see in testing,
> we're still hunting down about 1 crash per 67 million hours of runtime.
>
> needless to say, the economical thing to do is to ignore the problem, but 
> it sure bugs (!)
> me.  the correct number of crashes is 0.
>
> - erik
>
> On Tuesday, December 5, 2017 at 4:37:46 PM UTC-8, Erik Quanstrom wrote:
>>
>> the failure rate is high enough to be motivating.  :-)  i now have go 1.9 
>> working for
>> production builds.  i will report back with results as soon as i have 
>> them.
>>
>> - erik
>>
>> On Monday, December 4, 2017 at 6:16:29 PM UTC-8, Ian Lance Taylor wrote:
>>>
>>> On Sun, Dec 3, 2017 at 6:42 PM,   wrote: 
>>> > 
>>> > i'm running go 1.8.3 on linux.  about 1 in ~10 billion calls (spread 
>>> across 
>>> > many machines), i get 
>>> > a backtrace that looks like the following: 
>>> > 
>>> > panic: runtime error: invalid memory address or nil pointer 
>>> dereference 
>>> > [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 
>>> pc=0x4c3406] 
>>> > goroutine 441026 [running]: 
>>> > bufio.(*Reader).ReadSlice(0x0, 0xa, 0x30, 0xc420256ec8, 0xc4201b9ef0, 
>>> > 0xc420315580, 0x0) 
>>> > #011/usr/lib/golang/src/bufio/bufio.go:316 +0x26 
>>> > bufio.(*Reader).ReadLine(0x0, 0xa1f378, 0x30, 0xc4201b9ef0, 0x30, 
>>> > 0xc4201b9ef0, 0x30) 
>>> > #011/usr/lib/golang/src/bufio/bufio.go:367 +0x37 
>>> > fakexpkg.(*Xpkg).tableParse(0x, 0x0, 0x0) 
>>> > <- HERE 
>>> > #011/builddir/build/BUILD/posthoc-1.1/src/fakexpkg/xpkg.go:175 +0x86 
>>> > created by fakexpkg.(*Xpkg).List 
>>> > #011/builddir/build/BUILD/posthoc-1.1/src/fakexpkg/xpkg.go:225 +0x2ac 
>>> > 
>>> > the code calling tableparse looks something like this.  no references 
>>> to 
>>> > anything 
>>> > table at the end are kept in other places. 
>>> > 
>>> > ret := make(chan []*Info, 1) 
>>> > go x.tableParse(bufio.NewReader(outpipe), ret) 
>>> > table := <-ret 
>>> > 
>>> > other c programs that i run on these same machines do not core dump at 
>>> all. 
>>> > 
>>> > since there is no use of the unsafe package anywhere in this program, 
>>> i'm 
>>> > confused as to 
>>> > how the Xpkg receiver could be -1 unless something has gone wrong with 
>>> the 
>>> > runtime. 
>>> > i feel like i must be missing something though, since it's never the 
>>> layer 
>>> > below. 
>>> > 
>>> > does anyone have any idea what's going on here, or some hints on 
>>> debugging 
>>> > this? 
>>>
>>> Assuming that the race detector doesn't report any problems, this is a 
>>> strange example of memory corruption: not only is the receiver pointer 
>>> invalid, the two arguments to the function are nil even though the 
>>> code fragment shows that that is not possible.  From your description 
>>> the problem is very very rare.  How much time and energy do you have 
>>> for experimentation?  If you have some, the first step is certainly to 
>>> try using Go 1.9, as various bugs have been fixed.  If it still 
>>> happens the same way, the next step is to try to reduce the program to 
>>> a self-contained example that you can share.  At a guess given that 
>>> three words appear to be corrupt, it may have something to do with the 
>>> way that goroutine arguments are saved.  I don't see any way that 
>>> could fail, but then this is a very rare problem. 
>>>
>>> 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: Is there any way to define a struct member to hold a generic type channel?

[matthewjuran]

With interface{} it has to be a type check at 
runtime: https://play.golang.org/p/t2jip9E__F1

Matt

On Monday, March 26, 2018 at 12:34:34 PM UTC-5, 刘焱 wrote:
>
> 'chan interface {}' dosen't work.
>
> package main
>
> import "fmt"
>
> type ChannelWrapper struct {
> Channel chan interface{}
> }
>
> func main() {
> x := make(chan int)
> y := ChannelWrapper { x }
> fmt.Println(y)
> }
>
> Build this will yield 
> cannot use x (type chan int) as type chan interface {} in field value
>
>
> Cast x as follow:
> chan interface{} (x)
>
> Will yield 
> cannot convert x (type chan int) to type chan interface {}
>
>
>
> 在 2018年3月24日星期六 UTC+8上午1:41:59，matthe...@gmail.com写道：
>>
>> An empty interface var can hold any type, so you could have a chan 
>> interface{} then use an interface type assertion when you read a value. 
>>
>> 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.

[go-nuts] Re: [ANN] A golang source code query language

[matthewjuran]

Hi Forud, here’s a code review.

Thanks for the MIT license.

Seeing an empty struct type is a code smell to me, but I understand that 
this pattern may be required to be a database/sql driver.

The unit tests seem good but I’d add an example or more in-depth overall 
test.

In astdata/file.go perhaps consider embedding *File and *Package in type 
walker.

I’m not convinced that astdata should be a separate package from 
fzerorubigd/goql. Perhaps private types in the primary package would work 
fine? My thought is if this isn’t used anywhere else then files like 
ast_const.go in goql would be just as readable and clearly not be public 
types, and the astdata types could be simplified by avoiding encapsulation. 
Do you use astdata anywhere else outside of this project?

Generally I find your code readable with good structure and error handling.

If there’s only one cmd then why not just have a goql/main.go?

In package executor perhaps consider embedding fieldType in type field, 
*parse.Query and parse.Stack in type context, parse.ItemType in type dummy, 
and parse.Orders in type sortMe. I have the same comment about maybe 
eliminating this package.

Using interface{} in executor/filter.go is a code smell but I don’t 
understand what’s happening well enough to say if there’s a better way. A 
possible suggestion is to put the interface{} behind a named type that 
documents what kind of things can be assigned to the interface{}.

I’m not sure I understand the internal packages. Why not have them as part 
of package goql too?

This is small, but in package structures func HasFunction you could call 
fnLock.RUnlock() right after the read instead of as a defer. More 
importantly, are you sure this function isn’t introducing a race condition 
where you see a true, the function is unregistered concurrently, then you 
try to execute?

I don’t understand the name package structures. Could this one be part of 
the primary package too?

You’ve mentioned that documentation is a TODO, but the godoc is definitely 
important and to me drives the package architecting.

Matt

On Friday, March 23, 2018 at 5:11:07 AM UTC-5, Forud A wrote:
>
> Hello, 
>
> GoQL  is a hubby project of mine, 
> for extracting global var/func/const/type from go source code using simple 
> sql. the project is in early stage and any contribution/advice is welcome!
>
> A Clumsy :) Demo (asscinema) https://asciinema.org/a/170483
> https://github.com/fzerorubigd/goql
>
> 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] Is there any way to define a struct member to hold a generic type channel?

[matthewjuran]

An empty interface var can hold any type, so you could have a chan interface{} 
then use an interface type assertion when you read a value.

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] Re: Long running task in select case

[matthewjuran]

It’s channels either way: https://play.golang.org/p/OTNPsxiDSOp

A difference is no access to context.Context.Err(), but in this example the 
error isn’t checked. My opinion is there’s no reason to bring in the whole 
context when all that’s needed is a cancel action. Also there’s an added 
compile check for no writes to the cancel channel this way.

If this is package main then I’m fine with some API leeway, but in a 
library there’s good reason to reduce dependencies, especially on the API.

Matt

On Tuesday, March 20, 2018 at 1:26:36 AM UTC-5, Reinhard Luediger wrote:
>
> Because then you have to deal with all the chennels by yourself. Using the 
> Context API looks for me a bit cleaner and even easier.
>
> Am Montag, 19. März 2018 15:04:17 UTC+1 schrieb matthe...@gmail.com:
>>
>> Only a detail, but why not this instead as the API?
>>
>> func LongRunningTask(cancel <-chan struct{}, index int) (err error) {
>>
>> Matt
>>
>> On Monday, March 19, 2018 at 7:43:19 AM UTC-5, rog wrote:
>>>
>>> Why not something more like this? https://play.golang.org/p/3t4UtoFkoIt 
>>>
>>> A lot of this comes down to what that long running task is doing. 
>>> If it's hard at work doing computational work, the polling approach 
>>> might be appropriate. 
>>> If it's mostly waiting on external events then passing the context 
>>> instance down and selecting 
>>> on the Done channel is probably the way forward. 
>>>
>>> On 19 March 2018 at 07:44, Sathish VJ  wrote: 
>>> > Looks like this last one works but also quite complicated. 
>>> > 
>>> > One question ... what is the effect of having "default" on line 24 as 
>>> empty? 
>>> > 
>>> > 
>>> > On 18 March 2018 at 14:21, 'Reinhard Luediger' via golang-nuts 
>>> >  wrote: 
>>> >> 
>>> >> I came to the following solution for my long running tasks, using 
>>> >> go-routines & the context package, 
>>> >> 
>>> >> https://play.golang.org/p/2V_29lHt4Wn 
>>> >> 
>>> >> package main 
>>> >> 
>>> >> import ( 
>>> >>"context" 
>>> >>"fmt" 
>>> >>"time" 
>>> >> ) 
>>> >> 
>>> >> //LongRunningTask 
>>> >> func LongRunningTask(ctx context.Context, index int) (err error) { 
>>> >>// we'll signal on that channel when we finished 
>>> >>var finished chan struct{} 
>>> >>fmt.Printf("Starting task %d at: %s\n", index, time.Now()) 
>>> >>var cancelWork =  make(chan struct{},0) 
>>> >>go func() { 
>>> >>   workloop: 
>>> >>   for i:= 0 ;i < 10 ;i++{ 
>>> >>  // sleeping for a  long time 
>>> >>  time.Sleep(time.Second * 2) 
>>> >>  select { 
>>> >>  case <-cancelWork: 
>>> >> fmt.Printf("Canceling work for Index: %d\n",index) 
>>> >> break workloop 
>>> >>  default: 
>>> >>  } 
>>> >>   } 
>>> >>   finished <- struct{}{} 
>>> >>}() 
>>> >> 
>>> >>select { 
>>> >>// when the task finished normal we'll get a notification on the 
>>> >> finished channel 
>>> >>case <-finished: 
>>> >>   fmt.Printf("Task %d  finished at:%s\n", index, time.Now()) 
>>> >>   return nil 
>>> >> 
>>> >>// If the context gets canceled we receive a signal on that 
>>> channel 
>>> >>case <-ctx.Done(): 
>>> >>   err := ctx.Err() 
>>> >>   _=err 
>>> >>   //the context.Err() method gives us the reason why it was 
>>> canceled 
>>> >>   fmt.Printf("task %d aborted reason:%s at: %s\n", index, 
>>> ctx.Err(), 
>>> >> time.Now()) 
>>> >>   cancelWork <- struct{}{} 
>>> >>   return ctx.Err() 
>>> >>} 
>>> >> 
>>> >> } 
>>> >> 
>>> >> func main() { 
>>> >>var ctx context.Context 
>>> >> 
>>> >>// get a new Context and  the corresponding cancel function 
>>> >>ctx, cancel := context.WithCancel(context.Background()) 
>>> >> 
>>> >>// create a new context with a timeout value of 4 Seconds derived 
>>> from 
>>> >> the context above 
>>> >>ctx, _ = context.WithTimeout(ctx, time.Second*4) 
>>> >> 
>>> >>// Sleeping for one Second to clarify that the timeout is running 
>>> from 
>>> >> the point where it is created 
>>> >>time.Sleep(time.Second * 1) 
>>> >> 
>>> >>fmt.Printf("Starting background tasks time %s", time.Now()) 
>>> >>for i := 0; i < 7; i++ { 
>>> >>   go LongRunningTask(ctx, i) 
>>> >> 
>>> >>} 
>>> >> 
>>> >>// if we sllep longer than the timeout we'll see that the tasks 
>>> will be 
>>> >> canceled after timeout 
>>> >>time.Sleep(time.Second * 8) 
>>> >> 
>>> >>// The call of the cancel function has only effect when we slept 
>>> >> shorter then the defined timeout 
>>> >>// if so the single call of the cancel function will send a 
>>> >> cancellation information to all child context 
>>> >>cancel() 
>>> >> 
>>> >>// Sleep a while to see the cancellation messages 
>>> >>time.Sleep(time.Second * 4) 
>>> >> 
>>> >> } 
>>> >> 
>>> >> 
>>> >> Am Freitag, 16. März 2018 15:45:00 UTC+1 schrieb Sathish VJ: 
>>> >>> 
>>> >>> All the 

Re: [go-nuts] Re: Long running task in select case

[matthewjuran]

Only a detail, but why not this instead as the API?

func LongRunningTask(cancel <-chan struct{}, index int) (err error) {

Matt

On Monday, March 19, 2018 at 7:43:19 AM UTC-5, rog wrote:
>
> Why not something more like this? https://play.golang.org/p/3t4UtoFkoIt 
>
> A lot of this comes down to what that long running task is doing. 
> If it's hard at work doing computational work, the polling approach 
> might be appropriate. 
> If it's mostly waiting on external events then passing the context 
> instance down and selecting 
> on the Done channel is probably the way forward. 
>
> On 19 March 2018 at 07:44, Sathish VJ  
> wrote: 
> > Looks like this last one works but also quite complicated. 
> > 
> > One question ... what is the effect of having "default" on line 24 as 
> empty? 
> > 
> > 
> > On 18 March 2018 at 14:21, 'Reinhard Luediger' via golang-nuts 
> >  wrote: 
> >> 
> >> I came to the following solution for my long running tasks, using 
> >> go-routines & the context package, 
> >> 
> >> https://play.golang.org/p/2V_29lHt4Wn 
> >> 
> >> package main 
> >> 
> >> import ( 
> >>"context" 
> >>"fmt" 
> >>"time" 
> >> ) 
> >> 
> >> //LongRunningTask 
> >> func LongRunningTask(ctx context.Context, index int) (err error) { 
> >>// we'll signal on that channel when we finished 
> >>var finished chan struct{} 
> >>fmt.Printf("Starting task %d at: %s\n", index, time.Now()) 
> >>var cancelWork =  make(chan struct{},0) 
> >>go func() { 
> >>   workloop: 
> >>   for i:= 0 ;i < 10 ;i++{ 
> >>  // sleeping for a  long time 
> >>  time.Sleep(time.Second * 2) 
> >>  select { 
> >>  case <-cancelWork: 
> >> fmt.Printf("Canceling work for Index: %d\n",index) 
> >> break workloop 
> >>  default: 
> >>  } 
> >>   } 
> >>   finished <- struct{}{} 
> >>}() 
> >> 
> >>select { 
> >>// when the task finished normal we'll get a notification on the 
> >> finished channel 
> >>case <-finished: 
> >>   fmt.Printf("Task %d  finished at:%s\n", index, time.Now()) 
> >>   return nil 
> >> 
> >>// If the context gets canceled we receive a signal on that channel 
> >>case <-ctx.Done(): 
> >>   err := ctx.Err() 
> >>   _=err 
> >>   //the context.Err() method gives us the reason why it was 
> canceled 
> >>   fmt.Printf("task %d aborted reason:%s at: %s\n", index, 
> ctx.Err(), 
> >> time.Now()) 
> >>   cancelWork <- struct{}{} 
> >>   return ctx.Err() 
> >>} 
> >> 
> >> } 
> >> 
> >> func main() { 
> >>var ctx context.Context 
> >> 
> >>// get a new Context and  the corresponding cancel function 
> >>ctx, cancel := context.WithCancel(context.Background()) 
> >> 
> >>// create a new context with a timeout value of 4 Seconds derived 
> from 
> >> the context above 
> >>ctx, _ = context.WithTimeout(ctx, time.Second*4) 
> >> 
> >>// Sleeping for one Second to clarify that the timeout is running 
> from 
> >> the point where it is created 
> >>time.Sleep(time.Second * 1) 
> >> 
> >>fmt.Printf("Starting background tasks time %s", time.Now()) 
> >>for i := 0; i < 7; i++ { 
> >>   go LongRunningTask(ctx, i) 
> >> 
> >>} 
> >> 
> >>// if we sllep longer than the timeout we'll see that the tasks will 
> be 
> >> canceled after timeout 
> >>time.Sleep(time.Second * 8) 
> >> 
> >>// The call of the cancel function has only effect when we slept 
> >> shorter then the defined timeout 
> >>// if so the single call of the cancel function will send a 
> >> cancellation information to all child context 
> >>cancel() 
> >> 
> >>// Sleep a while to see the cancellation messages 
> >>time.Sleep(time.Second * 4) 
> >> 
> >> } 
> >> 
> >> 
> >> Am Freitag, 16. März 2018 15:45:00 UTC+1 schrieb Sathish VJ: 
> >>> 
> >>> All the examples I've seen use some kind of ticker to run various 
> cases 
> >>> of a select statement.  But how does one run a long running task that 
> is 
> >>> still cancelable? 
> >>> 
> >>> 
> >>> In the example below the quit part is never reached. 
> >>> 
> >>> https://play.golang.org/p/PLGwrUvKaqn  (it does not run properly on 
> >>> play.golang.org). 
> >>> 
> >>> package main 
> >>> 
> >>> 
> >>> import ( 
> >>>  "fmt" 
> >>>  "os" 
> >>>  "time" 
> >>> ) 
> >>> 
> >>> 
> >>> func f(quit chan bool) { 
> >>>  for { 
> >>>select { 
> >>>case <-time.After(0 * time.Second): 
> >>>  // start long running task immediately. 
> >>>  for { 
> >>>time.Sleep(500 * time.Millisecond) 
> >>>fmt.Printf(". ") 
> >>>  } 
> >>>case <-quit: 
> >>>  fmt.Println("quit called") 
> >>>  //deallocate resources in other long running task and then return 
> >>> from function. 
> >>>  os.Exit(0) // or return 
> >>>} 
> >>>  } 
> >>> } 
> >>> 
> >>> 
> >>> func main() { 
> >>>  var quit chan bool 
> >>>  

[go-nuts] Re: Flutter and golang

[matthewjuran]

>
> I gave up matching the native OS. It's futile and just way too much work. 

Don't kill me but it's really down to your philosophy in the end.


I’m asking because I’ve only done a web interface (where a cross-browser 
standardization library is useful for me), but I’ve used plenty of 
apps/programs that have terrible performance, look, interaction, or other 
problems, which doesn’t seem acceptable but still is ubiquitous for some 
reason. If I make something with a UI I don’t want to repeat those mistakes 
again and effort savings by Flutter is intriguing.

Thanks for your feedback.

Matt

On Monday, March 19, 2018 at 2:18:26 AM UTC-5, Ged Wed wrote:
>
> It's a horses for courses situation Matt.
>
> I can live with Material design everywhere with a customised there so I 
> emget the same branded corporate look everywhere.
>
> I gave up matching the native OS. It's futile and just way too much work.
>
> Don't kill me but it's really down to your philosophy in the end.
>
>

-- 
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: Long running task in select case

[matthewjuran]

>
> Only if it doesn't leave the shop like that, but with a P>0, it will. 


Before commit I usually go through many iterations, but what I shared was 
iteration one. I’m confident that iteration two wouldn’t have the data race 
in my case.

I don’t think these playgrounds are a good place to find production code.

Matt

On Saturday, March 17, 2018 at 5:56:24 PM UTC-5, kortschak wrote:
>
> Only if it doesn't leave the shop like that, but with a P>0, it will. 
>
> On Sat, 2018-03-17 at 15:24 -0700, matthe...@gmail.com  
> wrote: 
> > Defending my reputation, I’m here for people making things, not for 
> > being  
> > an educator. Thinking quickly and making it work even with mistakes 
> > can be  
> > a valid approach sometimes. 
> > 
> > Matt 
> > 
> > On Saturday, March 17, 2018 at 2:05:55 PM UTC-5, Michael Jones wrote: 
> > > 
> > > 
> > > these are excellent answers.  
> > > 
> > > i offer a harsher one:* the wrong answer faster is not 
> > > optimization. *the  
> > > law of programming has correctness at its core--imagine reasoning 
> > > about a  
> > > program where "if 5 < 7{stuff}" executed 50% of the time, or even 
> > > 99.%  
> > > of the time. if it was faster, that simply would not matter. this 
> > > is what  
> > > you cause then deny when you embrace race conditions of any kind, 
> > > anywhere,  
> > > ever. it means that your work only kind of works, in some cases, at 
> > > some  
> > > time, at the very best. 
> > > 
> > > it is the software equivalent of saying that cracked bridges have 
> > > "not all  
> > > that many cracks." don't go there. not just for your reputation, 
> > > but for  
> > > users and that of careful programmers. 
> > > 
> > > On Sat, Mar 17, 2018 at 9:40 AM,  > > >  
> > > wrote: 
> > > 
> > > > 
> > > > Hi all, 
> > > > 
> > > > In this particular case, this is a toy example of course, but for 
> > > > this  
> > > > toy example, it is absolutely a case where the performance of 
> > > > the  
> > > > synchronization primitive literally does not matter at all. (If I 
> > > > followed  
> > > > here, the intent is seemingly to watch a long running task, and 
> > > > the example  
> > > > has a 500ms sleep, etc.). 
> > > > 
> > > > That said, sometimes performance does matter. 
> > > > 
> > > > If instead this was a DIFFERENT example that was instead in some 
> > > > tight  
> > > > performance critical inner loop, the performance of the 
> > > > synchronization  
> > > > primitive for a stop flag can start to be meaningful (which of 
> > > > course  
> > > > should first be demonstrated by your benchmarking and/or your 
> > > > profiling of  
> > > > your particular program -- "premature optimization is the root of 
> > > > all evil"  
> > > > and all that). 
> > > > 
> > > > Empirically speaking, that is then a situation where I've seen 
> > > > people  
> > > > start to get into discussion around "well on amd64 you can rely 
> > > > on X and Y  
> > > > so we can get away with a stop flag that doesn't use a mutex or 
> > > > an atomic",  
> > > > and then people start talking about benign data races, and then 
> > > > other  
> > > > people start talking about "there are no benign data races", and 
> > > > then  
> > > > there's the reference to Dmitry Vyukov's article on benign data 
> > > > races, etc.: 
> > > > 
> > > >
> > > > https://software.intel.com/en-us/blogs/2013/01/06/benign-data-rac 
> > > > es-what-could-possibly-go-wrong 
> > > > 
> > > > To be honest I've seen it take up a fair amount of energy just 
> > > > to  
> > > > discuss, and again empirically speaking I've seen very smart 
> > > > people make  
> > > > mistakes here. 
> > > > 
> > > > One question I have regarding using an atomic for a stop flag is 
> > > > whether  
> > > > or not there is material performance overhead compared to a 
> > > > simple  
> > > > unprotected/non-atomic stop flag. 
> > > > 
> > > > I looked at that question a bit circa go ~1.7, so possibly stale 
> > > > info  
> > > > here, and I haven't gone back to look at my more detailed notes, 
> > > > but if I  
> > > > recall correctly I think my conclusion at the time was: 
> > > > 
> > > > 1. If your use case is a stop flag that will be checked many 
> > > > times (say,  
> > > > in a tight inner loop), and the stop flag only gets set rarely, 
> > > > then the  
> > > > performance of the set doesn't matter much, the assembly emitted 
> > > > for an  
> > > > atomic load (such as atomic.LoadUint64) seems to be identical for 
> > > > the  
> > > > assembly emitted for a simple load (say, *myUnint64Ptr) based on 
> > > > some spot  
> > > > checking a while ago (with a sample of assembly from 1.9 pasted 
> > > > in at the  
> > > > bottom of this post for comparison purposes). 
> > > > 
> > > > 2. Basic micro benchmarks didn't show a difference between an 
> > > > atomic load  
> > > > and an unprotected load for a stop flag. 
> > > > 
> > > > 3. There might be some theoretical 

Re: [go-nuts] Re: Long running task in select case

[matthewjuran]

Defending my reputation, I’m here for people making things, not for being 
an educator. Thinking quickly and making it work even with mistakes can be 
a valid approach sometimes.

Matt

On Saturday, March 17, 2018 at 2:05:55 PM UTC-5, Michael Jones wrote:
>
> these are excellent answers. 
>
> i offer a harsher one:* the wrong answer faster is not optimization. *the 
> law of programming has correctness at its core--imagine reasoning about a 
> program where "if 5 < 7{stuff}" executed 50% of the time, or even 99.% 
> of the time. if it was faster, that simply would not matter. this is what 
> you cause then deny when you embrace race conditions of any kind, anywhere, 
> ever. it means that your work only kind of works, in some cases, at some 
> time, at the very best.
>
> it is the software equivalent of saying that cracked bridges have "not all 
> that many cracks." don't go there. not just for your reputation, but for 
> users and that of careful programmers.
>
> On Sat, Mar 17, 2018 at 9:40 AM,  
> wrote:
>
>> Hi all,
>>
>> In this particular case, this is a toy example of course, but for this 
>> toy example, it is absolutely a case where the performance of the 
>> synchronization primitive literally does not matter at all. (If I followed 
>> here, the intent is seemingly to watch a long running task, and the example 
>> has a 500ms sleep, etc.).
>>
>> That said, sometimes performance does matter.
>>
>> If instead this was a DIFFERENT example that was instead in some tight 
>> performance critical inner loop, the performance of the synchronization 
>> primitive for a stop flag can start to be meaningful (which of course 
>> should first be demonstrated by your benchmarking and/or your profiling of 
>> your particular program -- "premature optimization is the root of all evil" 
>> and all that).
>>
>> Empirically speaking, that is then a situation where I've seen people 
>> start to get into discussion around "well on amd64 you can rely on X and Y 
>> so we can get away with a stop flag that doesn't use a mutex or an atomic", 
>> and then people start talking about benign data races, and then other 
>> people start talking about "there are no benign data races", and then 
>> there's the reference to Dmitry Vyukov's article on benign data races, etc.:
>>
>>   
>> https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong
>>
>> To be honest I've seen it take up a fair amount of energy just to 
>> discuss, and again empirically speaking I've seen very smart people make 
>> mistakes here.
>>
>> One question I have regarding using an atomic for a stop flag is whether 
>> or not there is material performance overhead compared to a simple 
>> unprotected/non-atomic stop flag.
>>
>> I looked at that question a bit circa go ~1.7, so possibly stale info 
>> here, and I haven't gone back to look at my more detailed notes, but if I 
>> recall correctly I think my conclusion at the time was:
>>
>> 1. If your use case is a stop flag that will be checked many times (say, 
>> in a tight inner loop), and the stop flag only gets set rarely, then the 
>> performance of the set doesn't matter much, the assembly emitted for an 
>> atomic load (such as atomic.LoadUint64) seems to be identical for the 
>> assembly emitted for a simple load (say, *myUnint64Ptr) based on some spot 
>> checking a while ago (with a sample of assembly from 1.9 pasted in at the 
>> bottom of this post for comparison purposes).
>>
>> 2. Basic micro benchmarks didn't show a difference between an atomic load 
>> and an unprotected load for a stop flag.
>>
>> 3. There might be some theoretical possible overhead due to the go 
>> compiler will do instruction reordering in general, but won't do 
>> instruction reordering across function calls, so that could be one 
>> difference that might or might not make a difference depending on your 
>> exact code (though likely modest impact)?  Regarding this last point, I'm 
>> just an interested spectator when it comes to the go compiler, so just to 
>> be clear I don't really know this definitively.
>>
>> At least for us at the time, the quick test program & comparison of 
>> assembly was enough to move us past the whole "Well, on amd64 you can get 
>> away with X" discussion, so I didn't delve too much deeper than that at the 
>> time.
>>
>> In any event, sharing this sample assembly with the community in case 
>> anyone is interested and/or has additional commentary on the particulars 
>> here in terms of performance impact in go of using an atomic load vs an 
>> unprotected stop flag for the (admittedly somewhat rare) cases when the 
>> nanoseconds do indeed matter. (And for me, a clean report from the race 
>> detector trumps the performance arguments, but that doesn't mean I'm not 
>> curious about the performance...).
>>
>> Here is a simple test program:
>>
>> https://play.golang.org/p/PaCQwb5m9ag
>>
>> func simpleLoadUint64(inputPtr *uint64) 

[go-nuts] Re: Long running task in select case

[matthewjuran]

>
> I think the second example alternative given (playground link above) has a 
> data race?


I’m not surprised that the race detector sees something (a read can happen 
during a write of the checked bool) but I don’t think this could actually 
cause problems because the var’s memory value will always be 0 or 1.

There may be implementation details or future implementation details that 
cause a problem though, so one option could be to protect the bool as a 
shared resource with a mutex or equivalent, but I think rog’s solution is 
better anyway (the first one).

They all involve either repeatedly checking on a timer or checking the 
> value of another field (like polling) to see whether the long running task 
> should be stopped.


Right, now every iteration of the loop has more work added.

Using os.Cmd may be an option, where you can call Kill on the separate 
process.

Matt

On Saturday, March 17, 2018 at 8:01:33 AM UTC-5, thepud...@gmail.com wrote:
>
> *> "Here's another way: https://play.golang.org/p/gEDef3LolAZ 
>>  "*
>
>
> Hi all,
>
> I think the second example alternative given (playground link above) has a 
> data race?
>
> Sample race detector run just now. (The two reports are inverses of each 
> other: read then write vs. write then read).
>
> ---
> go run -race stop_flag_from_gonuts.go
>
> . . . . . quit sending ...
> after quit sent==
> .
> WARNING: DATA RACE
> Write at 0x00c042072000 by goroutine 8:
>   main.f.func1()
>   C:/cygwin64/bin/gonuts/stop_flag_from_gonuts.go:13 +0x59
>
> Previous read at 0x00c042072000 by goroutine 6:
>   main.f()
>   C:/cygwin64/bin/gonuts/stop_flag_from_gonuts.go:17 +0x102
>
> Goroutine 8 (running) created at:
>   main.f()
>   C:/cygwin64/bin/gonuts/stop_flag_from_gonuts.go:11 +0x8a
>
> Goroutine 6 (running) created at:
>   main.main()
>   C:/cygwin64/bin/gonuts/stop_flag_from_gonuts.go:28 +0x70
> ==
> ==
> WARNING: DATA RACE
> Read at 0x00c042072000 by goroutine 6:
>   main.f()
>   C:/cygwin64/bin/gonuts/stop_flag_from_gonuts.go:17 +0x102
>
> Previous write at 0x00c042072000 by goroutine 8:
>   main.f.func1()
>   C:/cygwin64/bin/gonuts/stop_flag_from_gonuts.go:13 +0x59
>
> Goroutine 6 (running) created at:
>   main.main()
>   C:/cygwin64/bin/gonuts/stop_flag_from_gonuts.go:28 +0x70
>
> Goroutine 8 (finished) created at:
>   main.f()
>   C:/cygwin64/bin/gonuts/stop_flag_from_gonuts.go:11 +0x8a
> ==
> quit called
> Found 2 data race(s)
> exit status 66
> ---
>
> --thepudds
>
> On Friday, March 16, 2018 at 11:04:38 AM UTC-4, matthe...@gmail.com wrote:
>>
>> While this is running, your select won't be receiving on the quit 
>>> channel, even if it is non-nil. 
>>> If you want to be able to cancel it, you'll need to make the code in 
>>> the loop responsive to the quit channel 
>>> (for example, by using a select like you're using in f already). 
>>
>>
>> The default select case does it: https://play.golang.org/p/jlfaXu6TZ8L
>>
>> Here's another way: https://play.golang.org/p/gEDef3LolAZ
>>
>> Matt
>>
>> On Friday, March 16, 2018 at 9:45:00 AM UTC-5, Sathish VJ wrote:
>>>
>>> All the examples I've seen use some kind of ticker to run various cases 
>>> of a select statement.  But how does one run a long running task that is 
>>> still cancelable?  
>>>
>>>
>>> In the example below the quit part is never reached.  
>>>
>>> https://play.golang.org/p/PLGwrUvKaqn  (it does not run properly on 
>>> play.golang.org).
>>>
>>> package main
>>>
>>>
>>> import (
>>>  "fmt"
>>>  "os"
>>>  "time"
>>> )
>>>
>>>
>>> func f(quit chan bool) {
>>>  for {
>>>select {
>>>case <-time.After(0 * time.Second):
>>>  // start long running task immediately.
>>>  for {
>>>time.Sleep(500 * time.Millisecond)
>>>fmt.Printf(". ")
>>>  }
>>>case <-quit:
>>>  fmt.Println("quit called")
>>>  //deallocate resources in other long running task and then return 
>>> from function.
>>>  os.Exit(0) // or return
>>>}
>>>  }
>>> }
>>>
>>>
>>> func main() {
>>>  var quit chan bool
>>>  go f(quit)
>>>
>>>
>>>  println("quit sending ... ")
>>>  quit <- true
>>>  println("after quit sent")
>>>
>>>
>>>  var i chan int
>>>  <-i
>>> }
>>>
>>>
>>>

-- 
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: Long running task in select case

[matthewjuran]

>
> While this is running, your select won't be receiving on the quit 
> channel, even if it is non-nil. 
> If you want to be able to cancel it, you'll need to make the code in 
> the loop responsive to the quit channel 
> (for example, by using a select like you're using in f already). 


The default select case does it: https://play.golang.org/p/jlfaXu6TZ8L

Here's another way: https://play.golang.org/p/gEDef3LolAZ

Matt

On Friday, March 16, 2018 at 9:45:00 AM UTC-5, Sathish VJ wrote:
>
> All the examples I've seen use some kind of ticker to run various cases of 
> a select statement.  But how does one run a long running task that is still 
> cancelable?  
>
>
> In the example below the quit part is never reached.  
>
> https://play.golang.org/p/PLGwrUvKaqn  (it does not run properly on 
> play.golang.org).
>
> package main
>
>
> import (
>  "fmt"
>  "os"
>  "time"
> )
>
>
> func f(quit chan bool) {
>  for {
>select {
>case <-time.After(0 * time.Second):
>  // start long running task immediately.
>  for {
>time.Sleep(500 * time.Millisecond)
>fmt.Printf(". ")
>  }
>case <-quit:
>  fmt.Println("quit called")
>  //deallocate resources in other long running task and then return 
> from function.
>  os.Exit(0) // or return
>}
>  }
> }
>
>
> func main() {
>  var quit chan bool
>  go f(quit)
>
>
>  println("quit sending ... ")
>  quit <- true
>  println("after quit sent")
>
>
>  var i chan int
>  <-i
> }
>
>
>

-- 
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: Would this race condition be considered a bug?

[matthewjuran]

sync.Mutex is an easy way to guard shared resources. I’ve heard hints to 
use channels instead of a mutex though.

Matt

On Thursday, March 15, 2018 at 9:11:49 PM UTC-5, Anmol Sethi wrote:
>
> https://play.golang.org/p/82Um1jSntBo
>
> Please run with the race detector to see the race.
>
> This race condition arises because private variables are read via 
> reflection by the fmt package. Is there any elegant way to avoid such a 
> race?
>
> -- 
> Best,
> Anmol
>
>

-- 
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 build doesn't propagate options that disable optimizations

[matthewjuran]

This looks like it changed between 1.9.4 and 1.10.

Here’s the documentation: 
https://github.com/golang/go/blob/release-branch.go1.10/src/cmd/go/internal/work/build.go#L113-L127

I guess the package patterns thing is new. Try this:

go build -a -x -gcflags=“all=-N -l”

Matt

On Thursday, March 15, 2018 at 1:52:28 PM UTC-5, Patrick Turley wrote:
>
> I build my Go project with the -N and -l options, but they only seem to 
> apply to the top-most package -- imported packages are still optimized.  
> From what I can tell, this is because go build isn't propagating the 
> options that disable optimization as it tracks down and builds dependencies.
>
> I *claim* that:
>
>
>- If I tell  go build  to disable optimizations, it makes sense that 
>optimizations should be disabled for *everything* it ends up building.
>
>- Therefore, this is a bug.
>
>
> I'm writing here because I'm a Go n00b, and there may be something I'm 
> missing.
>
> Let me show my evidence...
>
> Consider the following trivial Go project:
>
> .
> ├── main.go
> └── help
> └── help.go
>
>
>
> Here's main.go:
>
>
> package main
>
> import "./help"
>
> func main() {
> help.Help()
> }
>
>
>
> Here's help.go:
>
>
> package help
>
> import "fmt"
>
> func Help() {
> fmt.Println("I'm helping")
> }
>
>
>
> Here's how I built the project:
>
>
> go build -gcflags="-N -l" main.go
>
>
>
> The -N option disables optimization, and the -l option disables inlining.
>
> This produced an executable called main in my current directory (as 
> expected).  I tried to debug this executable with delve and saw this:
>
>
> $ dlv exec main
> Type 'help' for list of commands.
> (dlv) b main.main
> Breakpoint 1 set at 0x108e83f for main.main() ./main.go:5
> (dlv) c
> > main.main() ./main.go:5 (hits goroutine(1):1 total:1) (PC: 0x108e83f)
>  1: package main
>  2:
>  3: import "./help"
>  4:
> =>   5: func main() {
>  6: help.Help()
>  7: }
> (dlv) s
> > main.main() ./main.go:6 (PC: 0x108e84b)
>  1: package main
>  2:
>  3: import "./help"
>  4:
>  5: func main() {
> =>   6: help.Help()
>  7: }
> (dlv) s
> > _/Users/pturley/Workspace/Go/src/debug-problem/help.Help() 
> ./help/help.go:5 (PC: 0x108e76f)
> Warning: debugging optimized function
>  1: package help
>  2:
>  3: import "fmt"
>  4:
> =>   5: func Help() {
>  6: fmt.Println("I'm helping")
>  7: }
>
>
>
> Notice that main() isn't optimized (as expected), but Help() is 
> optimized, and delve prints a warning about that.  If, for example, Help() 
> had local variables, it would be unlikely you could view their values.
>
> I tried building again with a few more options:
>
>
> go build -a -x -gcflags="-N -l" main.go > log 2>&1
>
>
>
> The -a option ensures Go doesn't rely on any cached build artifacts.  The 
> -x option causes Go to print all commands before executing them.
>
> Here's the command that built main.go (white space inserted to improve 
> clarity):
>
>
> /opt/local/lib/go/pkg/tool/darwin_amd64/compile
> -o $WORK/b001/_pkg_.a
> -trimpath $WORK/b001
> -N -l
> -p main
> -complete
> -buildid XMSzm8g7wNG80cfFP4Nw/XMSzm8g7wNG80cfFP4Nw
> -goversion go1.10
> -D _/Users/pturley/Workspace/Go/src/debug-problem
> -importcfg $WORK/b001/importcfg
> -pack -c=4
> ./main.go
>
>
>
> Here's the command that built help.go:
>
>
> /opt/local/lib/go/pkg/tool/darwin_amd64/compile
> -o $WORK/b002/_pkg_.a
> -trimpath $WORK/b002
> -p _/Users/pturley/Workspace/Go/src/debug-problem/help
> -complete
> -buildid Td3vdeSGgO-nwcrs810U/Td3vdeSGgO-nwcrs810U
> -goversion go1.10
> -D _/Users/pturley/Workspace/Go/src/debug-problem/help
> -importcfg $WORK/b002/importcfg
> -pack -c=4
> ./help.go
>
>
>
> Note that the -N and -l options are missing in the latter command.  If 
> they had been propagated by  go build (which I *claim* makes the most 
> sense), *all* my code would be debuggable.
>
>

-- 
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 does crypto/rand expose Reader?

[matthewjuran]

We've been talking about this 
here: https://github.com/golang/go/issues/24160

and here: https://github.com/golang/go/issues/23267

Matt

On Thursday, March 15, 2018 at 11:02:08 AM UTC-5, Volker Dobler wrote:
>
> Importing malicious code will lead to desaster.
>
> Protecting crypto/rand.Reader somehow from being
> tempered with won't help at all. It wouldn't be much
> more than cosmetics and feel good security theater.
> So why bother?
>
> V.
>
> On Monday, 26 February 2018 19:40:48 UTC+1, Fred Akalin wrote:
>>
>> crypto/rand exposes an io.Reader variable Reader as "a global, shared 
>> instance of a cryptographically strong pseudo-random generator." 
>> Furthermore, crypto/rand.Read implicitly uses Reader for its crypto source.
>>
>> This seems problematic to me because then any package can just overwrite 
>> crypto/rand.Reader to point to some other object, affecting the security of 
>> any packages that rely on crypto/rand.Read or crypto/rand.Reader for 
>> security, e.g. x/crypto/nacl.
>>
>> One can say that a language can never ultimately defend against code 
>> running in your same process, but I think it should be possible to write 
>> something that depends on crypto/rand for security that wouldn't require 
>> auditing other packages for a single malicious variable write.[1]
>>
>> I have a proof of concept here: https://github.com/akalin/randtest . The 
>> main code looks like:
>>
>> package main
>>
>> import (
>> "alice/eightball"
>> "crypto/rand"
>> "fmt"
>> )
>>
>> func main() {
>> eightball.Ask()
>>
>> var b [32]byte
>> rand.Read(b[:])
>> fmt.Printf("%x\n", b)
>> }
>>
>> which prints:
>>
>> Outlook not so good
>> deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef
>>
>> and where I half-heartedly attempt to obfuscate the code that actually 
>> modifies crypto/rand.Reader. I'm sure more clever people can come up with 
>> more sneaky ways to hide the write.[2]
>>
>> The main API flaw here, IMO, is that Reader is an io.Reader variable, 
>> whereas it should be a function that returns an io.Reader. A new API would 
>> look something like:
>>
>> // Reader returns an io.Reader that reads from a cryptographically strong 
>> pseudo-random number generator.
>> func Reader() io.Reader
>>
>> // Read is a helper function that calls Reader() and then passes it to 
>> io.ReadFull. 
>> func Read(b []byte) (n int, err error)
>>
>> Alas, with the Go 1 compatibility guarantee Reader would have to remain, 
>> and Read would still have to use Reader. But the above could be added as 
>> new functions, say MakeReader() and SafeRead(). And the standard library 
>> (and other important external packages like x/crypto/nacl) could be changed 
>> to use those safe functions.
>>
>> Unfortunately it seems difficult to mitigate against malicious tampering 
>> with crypto/rand.Reader. My coworker suggested using reflect to examine its 
>> underlying type, and assert that it's *crypto/rand.devReader, but that's 
>> probably the best that can be done.
>>
>> I'm interested to hear what everyone else thinks, and whether anyone know 
>> of any particular reason why Reader is exposed like this, before I file a 
>> bug. Thanks!
>>
>> -- Fred
>>
>> [1] Without this flaw, a malicious package would have to use the unsafe 
>> package to poke around in the internals of crypto/rand, or call out to the 
>> external OS to e.g. try to redirect access to the random device, which 
>> seems easier to audit for than a write to crypto/rand.Reader. Of course, 
>> I'm already assuming that a project worried about this is vendoring all of 
>> its dependencies.
>>
>> [2] One nice thing about go is that it's more difficult to write 
>> underhanded code in than, say, C ( http://www.underhanded-c.org/ ), or 
>> dynamic languages like Python or Javascript ( 
>> https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
>>  
>> ) where monkeypatching is easily done. But it seems plausible to me that 
>> code that modifies crypto/rand.Reader can be snuck into some innocuous 
>> package that would pass a cursory audit.
>>
>

-- 
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] fixed random number trouble

[matthewjuran]

crypto/rand is another option.

I use the math/rand repeatability to be able to regenerate a picture made 
of random elements, where I modify the seed until I’m happy with the result 
but later I may need to re-render at different dimensions or with other 
parameters.

Matt

On Thursday, March 15, 2018 at 9:53:48 AM UTC-5, Michael Jones wrote:
>
> As it turns out, repeatability of "random" experiments is very important, 
> especially during development.
>
> On Wed, Mar 14, 2018 at 11:35 PM, Andrea Alessandrini  > wrote:
>
>>
>>
>> Il giorno mercoledì 14 marzo 2018 18:38:51 UTC+1, Burak Serdar ha scritto:
>>>
>>> It is explained here: 
>>>
>>> https://golang.org/pkg/math/rand/ 
>>>
>>>
>> oh, thanks a lot. 
>>
>> Now I can see that's a quite common doubt  :-) 
>>   
>>
>> https://stackoverflow.com/questions/45753397/why-does-golang-repeats-the-same-random-number
>>
>>
>>  
>>
>>> On Wed, Mar 14, 2018 at 11:26 AM, Andrea Alessandrini  
>>> wrote: 
>>> > I wrote this simple code 
>>> > 
>>> > package main 
>>> > import ( 
>>> >  "fmt" 
>>> >  "math/rand" 
>>> > ) 
>>> > func main() { 
>>> >  for i := 0; i < 6; i++ { 
>>> > fmt.Println("My favorite number is", rand.Intn(100)) 
>>> > fmt.Println("My favorite number is", rand.Int()) 
>>> >  } 
>>> > } 
>>> > 
>>> > 
>>> > and I run it in my pc or in a web application 
>>> > (https://tour.golang.org/basics/1 ) 
>>> > 
>>> > For each application I got the same result : 
>>> > always: 
>>> > 
>>> >> $ go run 00_random.go 
>>> >> My favorite number is 81 
>>> >> My favorite number is 8674665223082153551 
>>> >> My favorite number is 47 
>>> >> My favorite number is 4037200794235010051 
>>> >> My favorite number is 81 
>>> >> My favorite number is 6334824724549167320 
>>> >> My favorite number is 25 
>>> >> My favorite number is 1443635317331776148 
>>> >> My favorite number is 56 
>>> >> My favorite number is 2775422040480279449 
>>> >> My favorite number is 94 
>>> >> My favorite number is 7504504064263669287 
>>> > 
>>> > 
>>> > 
>>> > It seams i should reset the memory, but I don't know how... 
>>> > 
>>> > Andrea 
>>> > 
>>> > -- 
>>> > 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.
>>
>
>
>
> -- 
> Michael T. Jones
> michae...@gmail.com 
>

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

[go-nuts] Re: [ANN] parwork - a fork-join package for processing work in parallel written in go

[matthewjuran]

Hi Sotirios,

Why not something like this?

// Stops and returns if any error is encountered by a work function, 
otherwise returns nil.
// Processes work at the pace of runtime.NumCPU() parallelization.
func Process(callback func(interface{}), work ...func() (interface{}, error
)) error

Matt

On Wednesday, March 14, 2018 at 3:54:24 PM UTC-5, Sotirios Mantziaris wrote:
>
> Hi,
>
>
> i have created a package which uses the fork-join model to parallelize 
> work.
>
> Check out my blog 
> and
>  
> the Github repository.
>
>
> Any feedback is highly welcome.
>
>
> 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] Why should i use interface composistion

[matthewjuran]

Writing to be testable is good but ideally tests shouldn’t drive the app 
code. I’ll admit that I’ve written inconsistent database method patterns to 
enable testing but then never wrote tests.

In that case there’s a global DB type (type DB struct { *sql.DB }) with a 
global var of the type initialized at the start of main. The HTTP handlers 
call DB methods on the global var, then ideally all of those DB methods use 
the receiver instead of the global var. I’m not sure how I’d start now, but 
the idea is those methods could be tested with a different DB (I’m not 
familiar with any sql in-memory ones).

Can you describe your code and testing in more detail?

Thanks,
Matt

On Tuesday, March 13, 2018 at 12:39:40 PM UTC-5, Reinhard Luediger wrote:
>
> hi,
>
> first of all thanks for your reply. Indeed, the interface arose from the 
> necessity of testing. Have you expierience with a memory sql driver? Could 
> you recommend one?
>

-- 
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 should i use interface composistion

[matthewjuran]

Interfaces are not for grouping variable behavior, interfaces are for 
allowing generic code to apply to varying data structures.

Consider a struct of function fields for grouping variable behavior without 
a backing data structure.

If your interface type is not an input in the same package then you didn’t 
need an interface.

I’m not convinced these three types should be interfaces.

Matt

On Tuesday, March 13, 2018 at 1:06:23 AM UTC-5, Reinhard Luediger wrote:
>
> Dear all,
>
> as far as I know it is recommended to keep actual interfaces as small as 
> possible and to form bigger interfaces via interface composiston. 
> Would be great if the community could advise me what the real benefits are.
>
> Lets say i want to create an interface for the database backend like the 
> following example.
>
> //CleanupTimestamps is the interface which holds all methods related to 
> cleanupTimestamps
> type CleanupTimestamps interface {
>SaveCleanupTimeStamp(taskName string, timestamp time.Time) (err error)
>GetCleanupTimeStamp(taskName string) (timestamp *time.Time, err error)
> }
>
> //ClusterFlavors interface holds all methods related to clusterFlavor
> type ClusterFlavors interface {
>CreateClusterFlavor(Name string, tx StoreTransaction) (Flavor 
> datatypes.ClusterFlavorPersisted, err error)
>UpdateClusterFlavor(ID string, Name string, tx StoreTransaction) (err 
> error)
>MarkClusterFlavorDeleted(ID string, tx StoreTransaction) (err error)
>DeleteClusterFlavorPermanent(ID string, tx StoreTransaction) (err error)
>ReadClusterFlavor(ID string) (Flavor datatypes.ClusterFlavorPersisted, err 
> error)
>ListClusterFlavors(Includedeleted bool) (Flavors 
> []datatypes.ClusterFlavorPersisted, err error)
> }
>
> //Store is the interface to encapsulate the Storage  Backend
> type Store interface {
>MustBegin() (tx StoreTransaction)
>
>CleanupTimestamps
>ClusterFlavors
> }
>
>
> Why should I create it in that fashion if I ever use the Store interface 
> in my cod? Or what are the drawbacks if I put all methods needed directly 
> into the Store interface?
>
> kind regards
>
> Reinhard
>
>

-- 
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: Are you doing unit, module, and systems tests? If not, why not?

[matthewjuran]

I have less than ten years of experience doing this, but:

The rule is that if you don’t verify it then it’s going to break in 
deployment, 100% of the time.

In my experience you can get away without testing small changes with 
software if you’re very careful about verifying the change with manual 
testing. For larger applications it’s also possible to get away with it, 
but there will be all kinds of problems along the way.

Tests can give a false sense of security; if there’s a large body of tests 
for an application then passing them with a change can feel good enough, 
but those tests only ever cover a subset of everything that can go wrong. 
So you still have to do the manual verification. But the idea of automatic 
tests as part of the build process is excellent because a lot of mistakes 
can be caught that way.

I’m not in the camp of 100% unit test coverage because then we’re backing 
up against the “engineers working on the bike shed instead of the nuclear 
reactor” problem, and test coverage can start looking like being paid by 
lines of code written. What’s important is test methodology, which likely 
includes unit tests, but should also include other forms of wider testing 
(like just playing with the application, random clicking or inputs, 
verifying output with a script).

For my web application my favorite has been a load test script that acts 
like many concurrent clients inputting valid and random inputs. This test 
has found rare deadlocks, app logic problems, and other things that would 
have only appeared with many users and would have been hard to reproduce.

I've noticed the testing camp is split three ways: some people hate tests, 
> some people don't get them or struggle with them, and some people love 
> them. What are your thoughts? 


People should learn to love software tests because it multiplies their 
effectiveness as a software engineer.

I think the idea of checking for impossible conditions in Go code is a 
worthwhile effort too (via Steve Maguire's "Writing Solid Code"):

const debug = false
…
if debug {
if impossibleCondition {
panic(“impossible condition”)
}
}

Matt

On Tuesday, March 13, 2018 at 1:11:56 AM UTC-5, Mike Crilly wrote:
>
> I'm keen to understand if and how people are doing unit, module, and 
> system tests for their Go applications. I've noticed the testing camp is 
> split three ways: some people hate tests, some people don't get them or 
> struggle with them, and some people love them. What are your thoughts? 
>
>
> If you're somewhere in the middle, is it because you're unsure as to how 
> to actually write the tests, what tools to use, how to make it easier, and 
> so? What's stopping you from implementing them?
>
>
> All thoughts welcome.
>

-- 
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: constructors vs lazy initialization

[matthewjuran]

>
> I prefer the later when possible because it enables callers to use the 
> zero value of a type without explicit initialisation.


Two great standard library examples of this are sync.Mutex / sync.RWMutex 
and bytes.Buffer / strings.Builder.

Matt

On Saturday, March 3, 2018 at 9:20:11 PM UTC-6, Dave Cheney wrote:
>
> I prefer the later when possible because it enables callers to use the 
> zero value of a type without explicit initialisation.
>
> On Sunday, 4 March 2018 11:37:43 UTC+11, Anmol Sethi wrote:
>>
>> How do you guys choose between constructors and lazy initialization?
>>
>> For example.
>>
>> Struct constructors:
>>
>> type meow struct {
>> x http.Handler
>> }
>>
>> func newMeow() *meow {
>> return {
>> x: http.NewServeMux(),
>> }
>> }
>>
>> func (m *meow) do() {
>> // stuff
>> }
>>
>>
>> Lazy initialization:
>>
>> type meow struct {
>> x http.Handler
>> }
>>
>> func (m *meow) do() {
>> if m.x == nil {
>> m.x = http.NewServeMux()
>> }
>> // stuff
>> }
>>
>>

-- 
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: Flutter and golang

[matthewjuran]

For my web application I previously reached the conclusion that the best 
approach is to write independent clients with the platform programming and 
visual design language instead of trying something cross-platform.

I can see Flutter or QT being great for “we need this to work everywhere 
and can sacrifice quality”, but for cases where I really need the 
performance and look (which I don’t imagine shares a lot between platforms) 
is there argument against just having a native app calling a Go library for 
the HTTP client functionality?

Matt

On Saturday, March 10, 2018 at 2:28:19 PM UTC-6, Ged Wed wrote:
>
> I am starting to develop an app using flutter and golang.
>
> Flutter is the dumb GUI and everything else is written in golang.
>
> It is reasonably easy to compile your golang code using gomobile and then 
> bind to flutter using the Method Channel API that flutter provides.
>
> Is anyone interested in this ?
>
> Flutter now runs on all desktops and mobiles officially. The desktop 
> version was announced 2 weeks ago and already Linux and macOS works, with 
> Windows probably being a few weeks away from what I guesstimate.
>
> The cool thing about this is that you get a very well supported and high 
> performance GUI engine for Forms and 2D. 3D is still not provided by has 
> been stated by the team to be looked at later.
>
> Anyway I hope to spark some interest in this and I will be putting up some 
> demo code on my git hub repo and hope others are interested enough to also 
> give it a try and work through it.
>
>
> How to write a plug-in:
>
> https://flutter.io/platform-channels/
>
> Plugins already available :
>
> https://pub.dartlang.org/flutter/packages
>
> Printing.
> They have not yet officially committed to how cross platform out put to 
> PDF and XPS ( for windows ) will be supported.
> Under the covers Flutter is using the same engine that Google Chrome 
> browser uses; called Skia.
>
> Skia has an API for printing web pages and it uses pdfium under the hood.
> It seams logical that the Flutter team will also start using this method 
> to provide built in PDF output and even print spooling but from what I can 
> see it's not resolved yet.
>
> All other things like touch, keyboard, sound, gestures etc are all built 
> into Flutter because it's built into Skia.
>
> Would be great to hear if there is a strong interest in this and to 
> discuss .
>
>

-- 
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: [ANN] Get Programming with Go

[matthewjuran]

I may have been pushing my own agenda more than what the Go project is 
actually about with this:

Perhaps something like “Go is designed for programming modern computers and 
> computer systems in English” would be more accurate?


This 2012 talk does indicate that Go is about Google-style network 
application programming: https://talks.golang.org/2012/splash.article

Matt

On Wednesday, March 7, 2018 at 10:03:17 AM UTC-6, matthe...@gmail.com wrote:
>
> Go is designed for the modern data center, but its adoption isn’t 
>> restricted to the workplace. 
>
>
> While the garbage collector may point to this, and I’ve previously argued 
> about data centers stepping on other applications’ feet, my understanding 
> is the stated goal is systems programming. This term encompasses anything 
> designed as part of a larger system in my mind; OS drivers and components 
> have been mentioned, the compiler is written in Go, build and other scripts 
> are easy to write in Go, OS CLI tools are great in Go, you’ve mentioned 
> embedded programming, small web servers with database definitely work, and 
> of course data center applications and infrastructure are a major Go target 
> and consumer.
>
> Perhaps something like “Go is designed for programming modern computers 
> and computer systems in English” would be more accurate?
>
> I’ve only looked at the three free chapters, but one thing that stands out 
> to me is the amount of formatting on each page. Although I’m looking on a 
> computer and not at a book, it seems that all of the italics, bolds, 
> blocks, lines, references, pictures, and other formatting add noise. I do 
> think the graphics are creative, slicing the solar system is great.
>
> It’s been asked here about references for new programmers but I didn’t 
> have an answer besides “what do you want to know?”. Can you share your 
> competition here? I’ll mention “Get Programming with Go” in the future.
>
> Thanks,
> Matt
>
> On Wednesday, March 7, 2018 at 8:46:58 AM UTC-6, Nathan Youngman wrote:
>>
>> Learn about error handling and concurrent state in the latest release of 
>> Get Programming with Go, available from Manning Books.
>>
>> The first draft is complete. If you have any feedback, now’s the time to 
>> get it in, as we are currently editing the book before it goes to 
>> production.
>>
>> https://bit.ly/programminggo
>>
>>
>>

-- 
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: My views on Go and why it's better than Scripting

[matthewjuran]

My statement earlier is wrong:

The Go 1 compatibility approach may be worth mentioning: programs written 
> in 2009 will still work in 2019 with the state of the art compiler. 


Go 1 was actually 2012, not 2009. Also Go 2 may start at some point soon, 
so maybe "programs written in 2012 will still work through at least early 
2018 with the state of the art compiler" is closer to correct.

Matt

On Saturday, March 3, 2018 at 4:19:41 PM UTC-6, matthe...@gmail.com wrote:
>
> I like Go because it improves on C for engineers in almost every way and 
> avoids classes, and, at least today, if you have a problem then it will be 
> solved quickly by the people following the GitHub issue tracker and 
> contributing to the source code.
>
> Go avoids complexities such as generics (aka templates) usually available 
>> in other languages (e.g., C++).
>
>
> This may be a temporary state, a major Go 2 discussion is about adding 
> generics (https://github.com/golang/go/issues/15292).
>
> The Go 1 compatibility approach may be worth mentioning: programs written 
> in 2009 will still work in 2019 with the state of the art compiler. 
>
> Select, channels, goroutines, methods, interface, closures, function 
> types, and map may be worth mentioning.
>
> For me seeing a small (<100 lines of code) application more complex than 
> "Hello, world!" written in other languages then in idiomatic Go would help 
> drive the point.
>
> There is hence no need for constantly worrying about `by reference` or `by 
>> value`.
>
>
> This is actually a tough part of Go when deciding how to define methods 
> (by pointer or by value), but at least there’s no pointer arithmetic.
>
> Matt
>
> On Saturday, March 3, 2018 at 7:56:41 AM UTC-6, Alex Rice wrote:
>>
>> Hi, thanks for sharing. I am not convinced about the reasons stated why 
>> Go is better than the other languages you mentioned. I am just learning Go, 
>> but I have 20 years of experience as a professional developer using various 
>> languages. I think students, beginners and professionals should use Go 
>> because of it's developer-first attitude. Ergonomics, I've heard it said.
>>
>> * productivity
>> * enjoyment
>> * nice workflow and development tools
>> * unix philosophy of small chain-able tools
>>
>> The lissajous example in the the gopl.io [1] book is a great example. In 
>> ~50 lines of code, there is a generator of animated gifs of harmonic motion 
>> curves, which it serves up on http, or write to standard out. How many 
>> lines of code would the same thing be in C, or in Python? I suspect more 
>> LOC, and I suspect 3rd party libraries would be involved.
>>
>> 1. https://github.com/adonovan/gopl.io/blob/master/ch1/lissajous/main.go
>>
>> Cheers,
>> 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: Building Go

[matthewjuran]

While an old Go program will compile with new versions, new Go programs may 
not compile with old versions due to added standard library APIs.

Matt

On Thursday, March 8, 2018 at 10:32:35 AM UTC-6, Krzysztof Kwiatkowski 
wrote:
>
> Hi,
>
>
> I've quite newbe question, but I would like to double-check my 
> understanding before doing something stupid.
>
>
> I'm building a toolchain for which I need to compile go from sources (I 
> modify the sources). In order to compile Go I need some version of Go to be 
> installed on my system.
>
> Does it matter which version of go I use to compile? 
>
> It will matter for things like performance, but I'm concerned purely about 
> correctness of the build.
>
>
> My understanding is that it doesn't - as according to documentation here 
> https://golang.org/doc/install/source, it's OK to use any compiler 
> version to compile go from source. Is my understanding correct?
>
>
> Kris
>

-- 
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: [ANN] Get Programming with Go

[matthewjuran]

>
> I'm not sure if "in English" really describes Go. Languages like Ruby 
> purport to offer English-like syntax (see "Beautiful Code: Leading 
> Programmers Explain How They Think") through metaprogramming tricks. On the 
> other hand, Go strives for simplicity and, in my opinion, clarity -- even 
> at the cost of verbosity in some cases. Whereas Ruby "reads like an essay", 
> code written in Go "does what it says."


Well there’s the capitalization for export rule, the keywords and built-in 
identifiers are English, and all toolchain comments and API are in English. 
There's discussion about a transliteration tool and translation strategy 
here: https://groups.google.com/forum/#!topic/golang-dev/BJXwjd3VEfM

Thanks for the discount code.

Matt

On Wednesday, March 7, 2018 at 9:09:26 PM UTC-6, Nathan Youngman wrote:
>
> Hi Matthew,
>
> First of all, thanks for looking at the free chapters and providing 
> feedback.
>
> I think I should reword the paragraph about the data centre, because there 
> is what Go was initially announced as, and then there is the niche that it 
> now occupies -- the later being predominately network services that tend to 
> run in data centres (65% according to 
> https://blog.golang.org/survey2017-results).
>
> I'm not sure if "in English" really describes Go. Languages like Ruby 
> purport to offer English-like syntax (see "Beautiful Code: Leading 
> Programmers Explain How They Think") through metaprogramming tricks. On the 
> other hand, Go strives for simplicity and, in my opinion, clarity -- even 
> at the cost of verbosity in some cases. Whereas Ruby "reads like an essay", 
> code written in Go "does what it says."
>
> The book layout isn't final, as it's still in early access. I think it 
> will look much nicer after it goes through the production phase -- finger's 
> crossed. A fair amount of that is outside of my control as the author. Even 
> the book cover is out of my hands, though I can and have given the 
> publisher feedback.
>
> As far as competition, the only book that comes to mind as 
> beginner-oriented is Caleb Doxsey's "Introducing Go" published through 
> O'Reilly. There may be others that I'm not aware of. 
> http://shop.oreilly.com/product/0636920046516.do I'm not sure if either 
> Caleb's book or ours is suitable for the absolute beginner. Learning 
> something like Scratch may be advisable first, to get the concepts down.
>
> Nathan.
>
> P.S. If you decide to buy a copy or recommend it to others, the discount 
> code *39youngman* will give 39% off either the paper book or ebook. Also, 
> my affiliate link earns me a few bucks: https://bit.ly/programminggo
>
>
> On 7 March 2018 at 09:02,  wrote:
>
>> Go is designed for the modern data center, but its adoption isn’t 
>>> restricted to the workplace. 
>>
>>
>> While the garbage collector may point to this, and I’ve previously argued 
>> about data centers stepping on other applications’ feet, my understanding 
>> is the stated goal is systems programming. This term encompasses anything 
>> designed as part of a larger system in my mind; OS drivers and components 
>> have been mentioned, the compiler is written in Go, build and other scripts 
>> are easy to write in Go, OS CLI tools are great in Go, you’ve mentioned 
>> embedded programming, small web servers with database definitely work, and 
>> of course data center applications and infrastructure are a major Go target 
>> and consumer.
>>
>> Perhaps something like “Go is designed for programming modern computers 
>> and computer systems in English” would be more accurate?
>>
>> I’ve only looked at the three free chapters, but one thing that stands 
>> out to me is the amount of formatting on each page. Although I’m looking on 
>> a computer and not at a book, it seems that all of the italics, bolds, 
>> blocks, lines, references, pictures, and other formatting add noise. I do 
>> think the graphics are creative, slicing the solar system is great.
>>
>> It’s been asked here about references for new programmers but I didn’t 
>> have an answer besides “what do you want to know?”. Can you share your 
>> competition here? I’ll mention “Get Programming with Go” in the future.
>>
>> Thanks,
>> Matt
>>
>> On Wednesday, March 7, 2018 at 8:46:58 AM UTC-6, Nathan Youngman wrote:
>>>
>>> Learn about error handling and concurrent state in the latest release of 
>>> Get Programming with Go, available from Manning Books.
>>>
>>> The first draft is complete. If you have any feedback, now’s the time to 
>>> get it in, as we are currently editing the book before it goes to 
>>> production.
>>>
>>> https://bit.ly/programminggo
>>>
>>>
>>> -- 
>> 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/_-35shjZqUU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> 

[go-nuts] Re: [ANN] Get Programming with Go

[matthewjuran]

>
> Go is designed for the modern data center, but its adoption isn’t 
> restricted to the workplace. 


While the garbage collector may point to this, and I’ve previously argued 
about data centers stepping on other applications’ feet, my understanding 
is the stated goal is systems programming. This term encompasses anything 
designed as part of a larger system in my mind; OS drivers and components 
have been mentioned, the compiler is written in Go, build and other scripts 
are easy to write in Go, OS CLI tools are great in Go, you’ve mentioned 
embedded programming, small web servers with database definitely work, and 
of course data center applications and infrastructure are a major Go target 
and consumer.

Perhaps something like “Go is designed for programming modern computers and 
computer systems in English” would be more accurate?

I’ve only looked at the three free chapters, but one thing that stands out 
to me is the amount of formatting on each page. Although I’m looking on a 
computer and not at a book, it seems that all of the italics, bolds, 
blocks, lines, references, pictures, and other formatting add noise. I do 
think the graphics are creative, slicing the solar system is great.

It’s been asked here about references for new programmers but I didn’t have 
an answer besides “what do you want to know?”. Can you share your 
competition here? I’ll mention “Get Programming with Go” in the future.

Thanks,
Matt

On Wednesday, March 7, 2018 at 8:46:58 AM UTC-6, Nathan Youngman wrote:
>
> Learn about error handling and concurrent state in the latest release of 
> Get Programming with Go, available from Manning Books.
>
> The first draft is complete. If you have any feedback, now’s the time to 
> get it in, as we are currently editing the book before it goes to 
> production.
>
> https://bit.ly/programminggo
>
>
>

-- 
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: General question: complex search form and query params

[matthewjuran]

>
> Unless I'm misunderstanding something, that kind of string concatenation 
> looks dangerous to me.


This approach may be error prone so testing is important but I believe the 
database/sql placeholders avoid any SQL injection. Here the caller also has 
responsibility to validate the input (such as to avoid a person making 
moves for others). I wouldn't call it flexible in an instantly readable 
sense but it's not too bad to work with.

Matt

On Sunday, March 4, 2018 at 12:55:43 AM UTC-6, Benjamin Thomas wrote:
>
> Unless I'm misunderstanding something, that kind of string concatenation 
> looks dangerous to me.
>
> I'v been doing a bit of digging...
>
> Turns out there is a DSL that looks like what I'm looking for: the Lucene 
> query syntax 
> .
>
> Some variant of it is even specifically designed to be opened up to direct 
> user input it seems.
>
> However I don't really want to duplicate data to a search DB like 
> elasticsearch (or bleve), as it seems overkill for the size of the dataset, 
> and SQL will be perfectly fine for query performance.
>
> I also stumbled upon this interesting article: 
> http://www.recursion.org/query-parser/
>
> The author advocates building a custom parser, for domain flexibility, 
> performance and security, basically what I'm looking for it seems.
>
> Although this is ruby code, and the queried DB is elasticsearch, and not 
> an SQL database, the same concepts apply.
>
> I've looked around, but haven't found any library that would take a lucene 
> like query syntax as input, and generate some kind of SQL abstraction as 
> output.
>
>
>
> 2018-03-03 22:46 GMT+01:00 :
>
>> Mapping a subset DSL to SQL doesn’t sound too difficult since SQL already 
>> has those boolean expressions and such. The database/sql library uses 
>> context for cancellation, so queries that take too long could be cancelled 
>> by a timer goroutine.
>>
>> One thing for me that would be helped by a library is keeping track of 
>> the argument placeholders ($1 $2 $3) and their indexing in the slice input 
>> to database/sql for the variadic part. Adding FOR UPDATE sometimes is also 
>> kind of ugly.
>>
>> Here’s a case where I dynamically constructed a query: 
>> https://github.com/pciet/wichess/blob/master/game.go#L209
>>
>> Matt
>>
>> On Friday, March 2, 2018 at 12:38:23 PM UTC-6, Benjamin Thomas wrote:
>>>
>>> I believe correctly used database/sql (with the argument placeholders) 
 protects against SQL injection

>>>
>>> Yeah I badly explained this, an SQL builder solves security *AND* 
>>> flexibility for me. Standard database/sql placeholders are too painful when 
>>> the user params are too complex, and I can't just pass around SQL fragments.
>>>
>>> It sounds like you are reinventing SQL. Why do you need a DSL?

>>>
>>> Yes, in a way SQL would be awesome, but way too powerful (and too 
>>> verbose). You can potentially access data from other tables, update/delete 
>>> data, etc.
>>>
>>> And how could you pass along raw SQL securely?
>>>
>>> I guess restricting data access could solve some issues. But let's say 
>>> I'd like to give access to a regex filter for some columns, but not others 
>>> (for performance reasons). Not sure if this would be possible at all via db 
>>> policies.
>>>
>>> I guess I'm looking for a "dumbed down" query language.
>>>
>>> In other words, as a programmer I've always been frustrated by search 
>>> forms I've developed. As a user, same thing, I always find them too 
>>> restrictive.
>>>
>>> I feel access to a DSL could be interesting for a power user, rather 
>>> than trying to anticipate every combination of search params a user would 
>>> want to perform. 
>>>
>>> Look at github for example, their advanced search form is interesting, 
>>> and love how readable the url can be: 
>>> https://github.com/search?q=language:Go+stars:<100+forks:>500
>>>
>>> However every params seems to be ANDed, so let's say you'd like to 
>>> search golang repos with less than 100 stars OR forks greater than 500, you 
>>> can't do it.
>>>
>>> Also if you pass invalid input, you seem to get garbage 
>>> : /search?q=language:whatever+stars:<100, so I feel that overall the user 
>>> experience is not that great.
>>>
>>> You see my point?
>>>  
>>>
>>> Le vendredi 2 mars 2018 15:11:19 UTC+1, matthe...@gmail.com a écrit :

 To prevent SQL injection and for flexibility, I'm set on using an sql 
> builder library.


 I believe correctly used database/sql (with the argument placeholders) 
 protects against SQL injection.

 There’s a query builder for postgres with MIT license posted here a few 
 days ago: 
 https://groups.google.com/forum/#!topic/golang-nuts/Mtqvr1N1zAI

 Otherwise strings.Builder (or bytes.Buffer pre-1.10), + string 
 concatenation, or fmt.Sprintf can do it.

 ## First, create a solid CLI app. Then port it to the 

[go-nuts] Re: My views on Go and why it's better than Scripting

[matthewjuran]

I like Go because it improves on C for engineers in almost every way and 
avoids classes, and, at least today, if you have a problem then it will be 
solved quickly by the people following the GitHub issue tracker and 
contributing to the source code.

Go avoids complexities such as generics (aka templates) usually available 
> in other languages (e.g., C++).


This may be a temporary state, a major Go 2 discussion is about adding 
generics (https://github.com/golang/go/issues/15292).

The Go 1 compatibility approach may be worth mentioning: programs written 
in 2009 will still work in 2019 with the state of the art compiler. 

Select, channels, goroutines, methods, interface, closures, function types, 
and map may be worth mentioning.

For me seeing a small (<100 lines of code) application more complex than 
"Hello, world!" written in other languages then in idiomatic Go would help 
drive the point.

There is hence no need for constantly worrying about `by reference` or `by 
> value`.


This is actually a tough part of Go when deciding how to define methods (by 
pointer or by value), but at least there’s no pointer arithmetic.

Matt

On Saturday, March 3, 2018 at 7:56:41 AM UTC-6, Alex Rice wrote:
>
> Hi, thanks for sharing. I am not convinced about the reasons stated why Go 
> is better than the other languages you mentioned. I am just learning Go, 
> but I have 20 years of experience as a professional developer using various 
> languages. I think students, beginners and professionals should use Go 
> because of it's developer-first attitude. Ergonomics, I've heard it said.
>
> * productivity
> * enjoyment
> * nice workflow and development tools
> * unix philosophy of small chain-able tools
>
> The lissajous example in the the gopl.io [1] book is a great example. In 
> ~50 lines of code, there is a generator of animated gifs of harmonic motion 
> curves, which it serves up on http, or write to standard out. How many 
> lines of code would the same thing be in C, or in Python? I suspect more 
> LOC, and I suspect 3rd party libraries would be involved.
>
> 1. https://github.com/adonovan/gopl.io/blob/master/ch1/lissajous/main.go
>
> Cheers,
> 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: General question: complex search form and query params

[matthewjuran]

Mapping a subset DSL to SQL doesn’t sound too difficult since SQL already 
has those boolean expressions and such. The database/sql library uses 
context for cancellation, so queries that take too long could be cancelled 
by a timer goroutine.

One thing for me that would be helped by a library is keeping track of the 
argument placeholders ($1 $2 $3) and their indexing in the slice input to 
database/sql for the variadic part. Adding FOR UPDATE sometimes is also 
kind of ugly.

Here’s a case where I dynamically constructed a query: 
https://github.com/pciet/wichess/blob/master/game.go#L209

Matt

On Friday, March 2, 2018 at 12:38:23 PM UTC-6, Benjamin Thomas wrote:
>
> I believe correctly used database/sql (with the argument placeholders) 
>> protects against SQL injection
>>
>
> Yeah I badly explained this, an SQL builder solves security *AND* 
> flexibility for me. Standard database/sql placeholders are too painful when 
> the user params are too complex, and I can't just pass around SQL fragments.
>
> It sounds like you are reinventing SQL. Why do you need a DSL?
>>
>
> Yes, in a way SQL would be awesome, but way too powerful (and too 
> verbose). You can potentially access data from other tables, update/delete 
> data, etc.
>
> And how could you pass along raw SQL securely?
>
> I guess restricting data access could solve some issues. But let's say I'd 
> like to give access to a regex filter for some columns, but not others (for 
> performance reasons). Not sure if this would be possible at all via db 
> policies.
>
> I guess I'm looking for a "dumbed down" query language.
>
> In other words, as a programmer I've always been frustrated by search 
> forms I've developed. As a user, same thing, I always find them too 
> restrictive.
>
> I feel access to a DSL could be interesting for a power user, rather than 
> trying to anticipate every combination of search params a user would want 
> to perform. 
>
> Look at github for example, their advanced search form is interesting, and 
> love how readable the url can be: 
> https://github.com/search?q=language:Go+stars:<100+forks:>500
>
> However every params seems to be ANDed, so let's say you'd like to search 
> golang repos with less than 100 stars OR forks greater than 500, you can't 
> do it.
>
> Also if you pass invalid input, you seem to get garbage 
> : /search?q=language:whatever+stars:<100, so I feel that overall the user 
> experience is not that great.
>
> You see my point?
>  
>
> Le vendredi 2 mars 2018 15:11:19 UTC+1, matthe...@gmail.com a écrit :
>>
>> To prevent SQL injection and for flexibility, I'm set on using an sql 
>>> builder library.
>>
>>
>> I believe correctly used database/sql (with the argument placeholders) 
>> protects against SQL injection.
>>
>> There’s a query builder for postgres with MIT license posted here a few 
>> days ago: https://groups.google.com/forum/#!topic/golang-nuts/Mtqvr1N1zAI
>>
>> Otherwise strings.Builder (or bytes.Buffer pre-1.10), + string 
>> concatenation, or fmt.Sprintf can do it.
>>
>> ## First, create a solid CLI app. Then port it to the web via a JSON API, 
>>> that would simply consume the query string.
>>
>>
>> In Go this might be best done as a non-main package with a cmd folder 
>> that has a folder for the server and a folder for the CLI app.
>>
>> I'm thinking of implementing a lexer/parser for this, but first I'd like 
>>> to make sure I'm not going to reinvent the wheel :)
>>
>>
>> It sounds like you are reinventing SQL. Why do you need a DSL?
>>
>> Matt
>>
>> On Friday, March 2, 2018 at 7:45:19 AM UTC-6, Benjamin Thomas wrote:
>>>
>>> Hello gophers,
>>>
>>> Sorry if this is considered noise to some, as I have a question which is 
>>> not specifically go related.
>>>
>>> I have a personal project in which I'd like to use go though.
>>>
>>> Basically, I'd like to create a complex search form, returning data 
>>> backed by an SQL database.
>>>
>>> To prevent SQL injection and for flexibility, I'm set on using an sql 
>>> builder library.
>>>
>>> However I'm not sure how to go about querying the data itself, via query 
>>> params, without creating lots of boiler plate and duplication.
>>>
>>> I'm wondering if a solution similar to what I'm looking for exists, as 
>>> I've never stumbled upon one...
>>>  
>>> I'm submitting my thoughts below, and would greatly appreciate feedback 
>>> :)
>>>
>>> ===NOTES_START===
>>> # Idea for query params, for a search form.
>>>
>>> Upon UI changes, javascript would generate the appropriate final query 
>>> string
>>>
>>> A query string could be typed in by a power user, to handle cases not 
>>> covered by a simpler UI (via the url or text input)
>>>
>>> ## First, create a solid CLI app. Then port it to the web via a JSON 
>>> API, that would simply consume the query string.
>>>
>>> ```
>>> go run ./cmd/query/main.go QUERY_STRING
>>> ```
>>>
>>> ## Query string format would follow this principle
>>>
>>> PARAM_NAME : VALUE : OPERATOR
>>>
>>> ```
>>> # 

[go-nuts] Re: How to limit what the `go get` command is able to import

[matthewjuran]

How do you stop people from downloading and deploying arbitrary python or 
java libs?

I can see that more than a developer policy is needed since it takes a 
corrupt employee only one try to break the system before they’re caught, 
and if the employee actually just made a mistake then firing them would be 
worse than not allowing this at all.

In our production environment this isn't even an issue because we can can't 
> even reach out to the internet in builds/deploys because its limited to 
> only internal locations.


It could be if the developer checks the outside package into the vendor 
directory.

Our internal packaging teams biggest worry is that we don't want someone to 
> download something to their development laptop, compile the code into a 
> standalone binary, then deploy that out to our container platforms.


I think you’d have to trust anybody that has this power. Perhaps deployment 
can be limited to only the official build channel?

Matt

On Friday, March 2, 2018 at 9:29:13 AM UTC-6, Brendan O'Dwyer wrote:
>
> Yes(technically) our deploys are controlled via gitlab. 
>
> Our internal packaging teams biggest worry is that we don't want someone 
> to download something to their development laptop, compile the code into a 
> standalone binary, then deploy that out to our container platforms.
>
> In our production environment this isn't even an issue because we can 
> can't even reach out to the internet in builds/deploys because its limited 
> to only internal locations. Their concern is that in development people 
> could `go get` packages that are not approved, then deploy those. While 
> that is super cool and awesome in open source worlds, unfortunately I work 
> for a bank that really likes to restrict and limit things so that they are 
> as secure as can be.
>
> On Wednesday, February 21, 2018 at 4:18:54 PM UTC-6, matthe...@gmail.com 
> wrote:
>>
>> Are the builds and deployment controlled? The command “go list” can be 
>> used to simplify parsing the imports in each package, so a script could 
>> check that every import is either an allowed standard library package or 
>> one matching your internal URL.
>>
>> Matt
>>
>> On Wednesday, February 21, 2018 at 11:37:35 AM UTC-6, Brendan O'Dwyer 
>> wrote:
>>>
>>> My company wants to start using go more, and traditionally when we use 
>>> java and python, when we package them for the developer laptops we override 
>>> settings and configs for the installs to point to our internal Artifactory 
>>> so that we don't have developers using packages that haven't been ok'd for 
>>> use. I was wondering if there was anyway to do this or configure go to 
>>> limit what its allowed to import from the open internet with the `go get` 
>>> command?
>>>
>>

-- 
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: General question: complex search form and query params

[matthewjuran]

>
> To prevent SQL injection and for flexibility, I'm set on using an sql 
> builder library.


I believe correctly used database/sql (with the argument placeholders) 
protects against SQL injection.

There’s a query builder for postgres with MIT license posted here a few 
days ago: https://groups.google.com/forum/#!topic/golang-nuts/Mtqvr1N1zAI

Otherwise strings.Builder (or bytes.Buffer pre-1.10), + string 
concatenation, or fmt.Sprintf can do it.

## First, create a solid CLI app. Then port it to the web via a JSON API, 
> that would simply consume the query string.


In Go this might be best done as a non-main package with a cmd folder that 
has a folder for the server and a folder for the CLI app.

I'm thinking of implementing a lexer/parser for this, but first I'd like to 
> make sure I'm not going to reinvent the wheel :)


It sounds like you are reinventing SQL. Why do you need a DSL?

Matt

On Friday, March 2, 2018 at 7:45:19 AM UTC-6, Benjamin Thomas wrote:
>
> Hello gophers,
>
> Sorry if this is considered noise to some, as I have a question which is 
> not specifically go related.
>
> I have a personal project in which I'd like to use go though.
>
> Basically, I'd like to create a complex search form, returning data backed 
> by an SQL database.
>
> To prevent SQL injection and for flexibility, I'm set on using an sql 
> builder library.
>
> However I'm not sure how to go about querying the data itself, via query 
> params, without creating lots of boiler plate and duplication.
>
> I'm wondering if a solution similar to what I'm looking for exists, as 
> I've never stumbled upon one...
>  
> I'm submitting my thoughts below, and would greatly appreciate feedback :)
>
> ===NOTES_START===
> # Idea for query params, for a search form.
>
> Upon UI changes, javascript would generate the appropriate final query 
> string
>
> A query string could be typed in by a power user, to handle cases not 
> covered by a simpler UI (via the url or text input)
>
> ## First, create a solid CLI app. Then port it to the web via a JSON API, 
> that would simply consume the query string.
>
> ```
> go run ./cmd/query/main.go QUERY_STRING
> ```
>
> ## Query string format would follow this principle
>
> PARAM_NAME : VALUE : OPERATOR
>
> ```
> # Commands
> columns:posted_on,short_descr:eq
> columns:posted_on,short_descr:hide
> columns:posting_id,posted_on,short_descr:show
>
> limit:10:eq
> limit:10  # would default to `eq`?
>
> page:1
> page:2
> offset:20
>
> # Filtering
> euros:11.94 # would default to `eq`?
> euros:11.94:eq
> euros:100:lt
> euros:100:lte
>
> comment:FIXME # would default to `eq`?
> comment:FIXME:eq
> comment:NULL:eq
> comment:NULL:ne
> comment:%tickets%:like
> comment:%Tickets%:ilike
>
> payee:Amazon|Google:re # regex
> payee:AMAZON|Google:rei # regex, case insensitive
>
> ```
>
> ## Question: how would I chain commands? I cannot use & in urls.
>
> ### Maybe with a pipe char
>
> QUERY_STRING | QUERY_STRING | QUERY_STRING
>
> ### Or via AND, OR keywords
>
> ```
> qs=QUERY_STRING
>
> qs AND qs OR qs
> ```
>
> ### Boolean logic, force the use of parentheses?
>
> ```
> qs=QUERY_STRING
>
> (qs AND qs) OR (qs OR qs)
> ```
> ===NOTES_END===
>
> Basically, I guess I'm looking for some kind of DSL.
>
> I'm thinking of implementing a lexer/parser for this, but first I'd like 
> to make sure I'm not going to reinvent the wheel :)
>
> Thanks for your interest and input!
>

-- 
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: [ANN] Loukoum: a simple SQL Query Builder with reusable components

[matthewjuran]

Hi Thomas,

I’ve thought about writing something like this. My postgreSQL queries go 
through database/sql and github.com/lib/pq and are concatenated strings 
with + and constants in most cases, and sometimes with Sprintf to write an 
index naming a column. This approach is hard to read. I have this issue 
about that: https://github.com/pciet/wichess/issues/49. It looks like your 
team has a lot more experience with SQL than me.

One thought is that the SQL seems to differ between relational database 
implementations. I’ve argued that database/sql should be a helper library 
instead of a gateway library because of this. Perhaps 
github.com/ulule/loukoum could be a way to hide those database differences 
from query construction? The goal would be to make servers using SQL 
relational database independent.

Anyway, here’s a code review.

I haven’t seen a library that exposes the API this way, with one file 
importing the sub-packages. While this seems clean I’ve been arguing for 
more use of flat packages in cases like this. For example, “type Map = 
types.Map” would be unnecessary if there was no types package. The 
functions here also require knowledge of the sub-packages anyway since they 
return types from those packages.

I prefer package names with a hint to what they do. The meaning of 
loukoum.Pair(…) can’t be inferred. Something like sqlb.Pair(…) would be my 
choice.

“func ToColumns(values []interface{})” isn’t clear to me. From the 
implementation it can either be a slice with one element of []stmt.Column 
or []string, or a slice of stmt.Column or string. I’ve been suggesting 
adding a type for interface{} in cases like this that documents what the 
expected types are:

// A Column can be string or stmt.Column.
type Column interface{}

I’m only saying this because these are exported functions of 
github.com/ulule/loukoum/builder, if they were private functions then the 
code may be documentation enough.

To me this shows that something might be improved to avoid this need in the 
library code:

var _ Builder = Delete{}

Along with that, I’m not sure about the Builder interface. If the interface 
is not part of a function call in the same file or package I’m worried. 
I’ve previously suggested grouping behavior as a struct type of function 
fields instead of relying on a type hierarchy, or there may be other ways 
to do it, but an interface should have an obvious use locally. Maybe having 
the flat package would make this interface more clear.

Again, the “type Select struct { query stmt.Select }” seems like a symptom 
of package overuse.

In lexer:

l := Lexer{}
l.input = buffer

could instead be

l := Lexer{input: buffer}

In stmt I’m not sure what this means:

func (Between) expression() {}

Why

// and Limit, Offset, OrderBy, Prefix, Using, Values, Where
type Value struct { Value interface{} }

instead of

type Value interface{}

Generally I could see function types and closures being useful, I’m not 
seeing those anywhere.

This kind of thing is a lot of work to get right and has the overhead of 
copying anything assigned to an interface{}:

type Map map[interface{}]interface{}

Maybe there’s a better way?

Thanks for the MIT licensing.

Matt

On Tuesday, February 27, 2018 at 11:57:42 AM UTC-6, Thomas LE ROUX wrote:
>
> Hi,
>
> I'd like to announce a new open source project from Ulule: *Loukoum *
> (https://github.com/ulule/loukoum)
>
> *.*It's a simple query builder that will help you to generate complex 
> queries without SQL injection. 
> If you're not using an ORM, you should give it a try.
>
> At the moment, we only support *PostgreSQL. *
> But feel free to contribute and give your feedback :)
>
>
> Cheers,
> Thomas.
>

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