Re: [go-nuts] Selenium webdriver based testing in Go

I've had a lot of success with agouti, though I don't know enough about Selenium to be sure that it's what you're asking for. I used it to do browser testing of a rich internet application, with chrome driver. On Dec 31, 2017 14:56, "Tong Sun" wrote: > Hi, > > Anyone here ever looked into doing

[go-nuts] Re: [ANN] laitos v1.0 - your all-in-one personal web server suite + tools for using the Internet via telephone calls and SMS!

Happy new year Tong. I'm glad that the project has caught your attention. The unit test coverage as measured by standard go test runner is well above 80% overall. In May 2017 the project was 80% feature complete, and began to drive several of my own servers, and feedback was collected from othe

[go-nuts] Re: [ANN] You can now manipulate .ass/.ssa subtitles alongside .srt, .ttml, .vtt, .stl, etc. in GO

thanks! On Tuesday, December 19, 2017 at 2:43:02 AM UTC-5, Asticode wrote: > > Just to let you guys know I've added support for .ass/.ssa subtitles in > go-astisub. >

Re: [go-nuts] Re: private global un-used variable passing compile - is it intended or a bug?

A private global can be used in assembly. The compiler would not be able to detect that fact. I don't think that's a show-stopper (the compiler has a -complete flag, and the linker might do such detection), but it makes specifying when the toolchain should report an error more complicated. On

[go-nuts] Re: ANN: best in class serialization for Go, greenpack

noted. thanks! On Friday, December 22, 2017 at 11:05:36 PM UTC-5, Jason E. Aten wrote: > > The latest release of greenpack, version 5.0.5 at > https://github.com/glycerine/greenpack supports several new features. > > a) serialization of objects containing interfaces. As simple as having > your

[go-nuts] Re: [ANN] laitos v1.0 - your all-in-one personal web server suite + tools for using the Internet via telephone calls and SMS!

That's amazingly lot of features within a single project, so my first question that comes naturally is, How well it is tested? I saw production ready, Enterprise support available in the README, but can you explain a bit, why you think it is production ready? Not wanting to challenge you but

[go-nuts] Selenium webdriver based testing in Go

Hi, Anyone here ever looked into doing Selenium webdriver based testing in Go? If anyone has experiences before, I'd like to know your view of the whole thing. Things come to mind are, - Do you use Selenium IDE or write Selenium webdriver code directly? - Selenium IDE is very helpful, but see

Re: [go-nuts] Nil Channels and Case Evaluation

Nothing is known beforehand indeed. That does not mean it's not possible to expect a certain semantic for a certain syntax beforehand. On Sunday, December 31, 2017 at 9:36:37 PM UTC+3:30, leaf...@gmail.com wrote: > > > How putting one channel inside the parameters has not any effect on the > lo

Re: [go-nuts] Nil Channels and Case Evaluation

> How putting one channel inside the parameters has not any effect on the logic > of that select statement. True. My point is, whether a channel is nil or not is often not known to the coder, and this whether the first will be called or not is unknown. Pass the channel as a parameter emphasize

Re: [go-nuts] Nil Channels and Case Evaluation

I do not understand how that makes a difference. I expect a certain behavior (whatever it is) to rely on. The pattern of using multiple channels inside a goroutine loop is not something unknown in Go world. And each case may change the value of other channels. How putting one channel inside the

Re: [go-nuts] Nil Channels and Case Evaluation

The point is, you will not know whether the caller send a nil or not. dc0d於 2018年1月1日星期一 UTC+8上午1時27分29秒寫道： > > I do not see how it should make me panic. If it's nil, it will be ignored > and if it's not nil only then calling first() should cause a dead lock. > That's common sense. > > But since

Re: [go-nuts] Nil Channels and Case Evaluation

I do not see how it should make me panic. If it's nil, it will be ignored and if it's not nil only then calling first() should cause a dead lock. That's common sense. But since "it is working according to the spec", it seems I should live with this and move on. On Sunday, December 31, 2017 at

Re: [go-nuts] Nil Channels and Case Evaluation

dc0d於 2017年12月31日星期日 UTC+8下午11時40分44秒寫道： > > Or the (not only) other option is check for nil channels before entering > the scope of select? > Change a little bit of your code. package main import ( "log" "time" ) func main() { f(nil) f(make(chan bool)) } func first() bool { select

Re: [go-nuts] Nil Channels and Case Evaluation

It would be much more odd, imho, for a select case to be chosen because a send can proceed, and for it then to block while generating the value to send. Simple politeness mandates that we have a value ready and evaluated when it becomes time to send it. //jb On 31 Dec 2017, at 16:41, dc0d mai

Re: [go-nuts] Nil Channels and Case Evaluation

On Sun, Dec 31, 2017 at 4:41 PM dc0d wrote: > Or the (not only) other option is check for nil channels before entering the scope of select? That would remove an equally important property that the RHS can se the channel to nil. tl;dr: The current design was thoroughly thought out. It's not perf

Re: [go-nuts] Nil Channels and Case Evaluation

Or the (not only) other option is check for nil channels before entering the scope of 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+unsubsc

Re: [go-nuts] Nil Channels and Case Evaluation

On Sun, Dec 31, 2017 at 2:47 PM dc0d wrote: > What is the expected output? Deadlock, ofc. What else one could expect if the goroutine trying to perform the initial phase the select statement is blocked forever and no other userland goroutine executes? The only other option would be for the sele

Re: [go-nuts] Nil Channels and Case Evaluation

A more complete code: package main import ( "log" "time" ) func main() { f() } func first() bool { select {} } func f() { // for demonstration purpose var rcvd chan bool = nil select { case rcvd <- first(): case <-time.After(time.Second): log.Println("timeout") } log.Println("d

Re: [go-nuts] Nil Channels and Case Evaluation

dc0d於 2017年12月31日星期日 UTC+8下午8時21分29秒寫道： > > Consider this: > > func first() bool { > select {} > } > > > And inside another function/goroutine: > > func f() { > var rcvd chan bool > select { > case rcvd <- first(): > } > } > > While rcvd is nil, this select statement (inside f) will block, f

Re: [go-nuts] Re: Nil Channels and Case Evaluation

On Sun, Dec 31, 2017 at 1:15 PM dc0d wrote: > Also the function first() may block on it's own. That's the very purpose of the select statement! 1. Determine which cases can proceed and which cannot. 2. Randomly select one case which can proceed and perform the communication, if there's any such

Re: [go-nuts] Nil Channels and Case Evaluation

Consider this: func first() bool { select {} } And inside another function/goroutine: func f() { var rcvd chan bool select { case rcvd <- first(): } } While rcvd is nil, this select statement (inside f) will block, forever. IMHO that's unexpected. -- You received this message because y

Re: [go-nuts] Re: Nil Channels and Case Evaluation

You really should see my code (again at playground: https://play.golang.org/p/znlLnuT7_lQ). You will see your common sense behavior is undesired. The select statement literally does nothing to check if a channel is nil or not and it is a coder's responsibilty to manage if first() is blockable or

Re: [go-nuts] Re: Nil Channels and Case Evaluation

Thanks leafbebop! Thanks Jan! I'm not convinced that, this might be a performance problem. Both actions happens anyway, so the total time would be the same. Also the function first() may block on it's own. So, the select statement might get blocked on a nil channel! That's bad! The only reaso

Re: [go-nuts] Re: Nil Channels and Case Evaluation

Jan Mercl於 2017年12月31日星期日 UTC+8下午8時05分07秒寫道： > > On Sun, Dec 31, 2017 at 12:48 PM dc0d > > wrote: > > > Indeed everything works according to the specs. That is what is being > questioned (the specs). > > Well, questioning the specification and expecting unspecified behavior > seems like two d

Re: [go-nuts] Nil Channels and Case Evaluation

This has almost nothing to do with case statements or switches. Switch cases are expressions, expressions have a defined evaluation process. That process includes short circuiting boolean logic. Channel sends on the other hand have no such short circuiting, whether used in a select case or not.

Re: [go-nuts] Re: Nil Channels and Case Evaluation

On Sun, Dec 31, 2017 at 12:48 PM dc0d wrote: > Indeed everything works according to the specs. That is what is being questioned (the specs). Well, questioning the specification and expecting unspecified behavior seems like two different things. > This behavior for case clause of select statemen

[go-nuts] Re: Nil Channels and Case Evaluation

I get your point now, but I would not say it is common sense. When using a channel, what matters is what to send to the data, not what the channel is. If `case` evaluation behaves different depending on whether chan is nil, it is a big surprise and may raise many bugs. It is a pattern in go tha

Re: [go-nuts] Re: Nil Channels and Case Evaluation

Indeed everything works according to the specs. That is what is being questioned (the specs). > > This behavior for case clause of select statements have different semantics than case clause of switch statement. While the latter gets evaluated lazily (short circuited), the former gets evaluate

Re: [go-nuts] Re: Nil Channels and Case Evaluation

On Sun, Dec 31, 2017 at 11:55 AM dc0d wrote: > Please read the first message in this thread. The first() function was expected to be ignored as in common sense, yet it gets evaluated. > > I am not wrong (or right), only making a point (maybe the point seems pointless) and I have read the specs. I

Re: [go-nuts] Re: private global un-used variable passing compile - is it intended or a bug?

On Sun, Dec 31, 2017 at 11:47 AM wrote: > But would it make more sense to throw an error in this case? Is there any missing points for an un-used private global variable? I think it's just heuristic. Unused local variable really is an error more often than an unused TLD one. -- -j -- You r

[go-nuts] Re: Nil Channels and Case Evaluation

Please read the first message in this thread. The first() function was *expected* to be ignored as in common sense, yet it gets evaluated. I am not wrong (or right), only making a point (maybe the point seems pointless) and I have read the specs. I am saying that this behavior was *unexpected*

[go-nuts] Re: private global un-used variable passing compile - is it intended or a bug?

Thank you for the insight. I didn't know that. But would it make more sense to throw an error in this case? Is there any missing points for an un-used private global variable? I feel like to file an issue on github but kind of unsure. Vasko Zdravevski於 2017年12月31日星期日 UTC+8上午1時26分59秒寫道： > > I thin

[go-nuts] Re: Nil Channels and Case Evaluation

I think you got it wrong. `select` is never about evaluating, but about blocking. It picks a case that is not blocked at the moment (or one of them, ramdomly) and a nil channel never block. It has nothing to do with any evaluation. dc0d於 2017年12月31日星期日 UTC+8下午6時27分41秒寫道： > > Indeed. But case cla

[go-nuts] Re: Nil Channels and Case Evaluation

Indeed. But case clauses of a select statement evaluate all expressions even if the channel is nil, in which case it is ignored and it was expected for other expressions to not get evaluated (which is not the case). -- You received this message because you are subscribed to the Google Groups "

[go-nuts] Re: Nil Channels and Case Evaluation

I think it is well described as "short-circuit evaluation". It is common in almost every popular programing languages (as far as I can tell). In short, it means in `true || A()` A is never called and in `false && B()` B is never called. It is the reason you can write something like ` if n > Than

[go-nuts] Re: Nil Channels and Case Evaluation

Thanks! Still it's the opposite of how a case works inside a switch statement. I understand these are different contexts but this difference is a bit of inconsistency and an unnecessary cognitive load (IMHO). func main() { switch { case false && first() == 1: case true: log.Println("first