[go-nuts] Is there a bug in path.Dir?

[18126523585]

In windows platform, path.Dir and path.Base can't get the correct result. 

The test code is like this:

func main() {
   filename := "F:\\Test\\conf\\rkc1"
   i := strings.LastIndex(filename, string(filepath.Separator))
   fmt.Println("dir1:", string(filename[:i+1]))
   fmt.Println("base1:", string(filename[i+1:]))

   fmt.Println("dir2:", path.Dir(filename))
   fmt.Println("base2:", path.Base(filename))
}



result is :
dir1: F:\Test\conf\
base1: rkc1
dir2: .
base2: F:\Test\conf\rkc1


The dir2 and base2 is not correct , look into the path.Dir, the code is 
hard code with "/", but not filepath.Separator. 

Can it be considered as a bug in golang lib?

-- 
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: Discussion on "Vendoring edge case, critical problem"

[Dave Cheney]

If you mean forking their dependencies and rewiring their import paths, that is 
a possibility. But it leaves consumers of those packages in the same position 
as the thread the OP referenced because the same code is now known by two 
distinct import paths breaking type equality. 

-- 
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] Using wss with Gorilla github.com/gorilla/websocket

[Shawn Milochik]

You will need a domain name for WSS/TLS.

The difference between WS and WSS is as simple as using ListenAndServeTLS
instead of ListenAndServe. You can even  have an 'if' statement to serve
either, so you can more easily test during development.

https://golang.org/pkg/net/http/#ListenAndServeTLS

-- 
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: Discussion on "Vendoring edge case, critical problem"

[Peter Kleiweg]

Libraries can vendor in the directory "internal"? 

-- 
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: Currying in Go

[Jesper Louis Andersen]

On Sat, Jun 18, 2016 at 5:32 AM, Tyler Compton  wrote:

> I don't pretend to be proficient in this realm of functional programming,
> but I would be very surprised if this is valuable in a language like Go
> that can and does hold state.


In functional languages, it is often used as a way to "configure" a
function. I.e., the function is defined as

let f conf x = ...

where 'f' is the function name, 'conf' a parameter of configuration and 'x'
the "real" argument to the function. Now, partial application such a (f c)
for some configuration 'c', yields another function which has been
configured, or specialized, to the particular use case.

Usually it allows you to define a generic function and then specialize it
in some context by "plugging in" a configuration. The configuration is
often a constant value which means the compiler will typically
constant-propagate that value into the closure. Many functional compilers
understand that closures with static data can be eliminated at compile time
by replacing them with a normal function. In other words, you have a
generic variant of your function, but when run it is specialized and
instantiated into an optimized variant.

You *can* get the same with a function such as 'f(conf, x)' but in this
case, the compiler usually has some more work to do before it can apply the
above transformation.



-- 
J.

-- 
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: Currying in Go

[Christoph Berger]

> this seems like an eyesore and maintenance concern. (...) it does cause 
me to hear code review sirens going off in the distance. 

Then why would you want to use currying in Go at all? What's the point of 
being able to write f(1)(2)(3) instead of f(1,2,3) *in a non-functional 
language?* Especially if the price you pay is code that is hard to read and 
difficult to maintain. 

As a Go proverb says, "Clear is better than 
clever".


On Friday, June 17, 2016 at 12:00:43 AM UTC+2, Zauberkraut wrote:
>
> Hello,
>
> Go enables the evaluation of functions using currying over function 
> literals. Every example I've found of this is rather shallow; a "deeper" 
> example I wrote implementing (x => (y => (z => x^2 + y^2 + z^2))) follows:
>
> func f(x int) func(int) func(int) int {
> return func(y int) func(int) int {
> return func(z int) int {
> return x*x + y*y + z*z
> }
> }
> }
>
> Go's limited type inference makes the explicit, cascading function types 
> necessary; this seems like an eyesore and maintenance concern. While I 
> don't really mind it, it does cause me to hear code review sirens going off 
> in the distance. Generally speaking, would an extended usage of this 
> paradigm be considered unidiomatic in Go? Obviously, the above example is 
> contrived and not the sort of use case in question. 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] Unmarshalling and tags

['Mihai B' via golang-nuts]

Hi there,

I have a struct that needs to be marshalled/unmarshalled using various 
serialization formats(xml, json, name/value). The tags start to represent a 
considerable effort[0] so I'm wondering if this is a common use case and if 
a change[1] to the encoding packages to specify the tag key/selectors would 
be a bad idea. Another option would be to use a standard tag key as default 
(e.g. "encoding") but I think it may violate  the Go1 backward 
compatibility.

Mihai.


[0]
type Payment struct {
ActionType paypal.ActionType `query:"actionType,omitempty" 
json:"actionType,omitempty"  xml:"actionType,omitempty"`
ReceiverList paypal.ReceiverList `query:"actionType,omitempty" 
json:"receiverList,omitempty"  xml:"receiverList,omitempty"`
}


[1] (dec *Decoder)SetTagKey(key string)

-- 
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: How to manage a web portal with multiple services without stopping and restarting everything at each release/fix?

[Simon Ritchie]

I think you will be hard put to match the performance of a PHP application on 
restart, and it may be faster in general.  I've always assumed that this is due 
in part to the fact that the app is embedded in the web server and in part to 
the essential simplicity of the framework - PHP doesn't do as much for you as 
an industrial-strength application server, but what it does do, it does very 
efficiently.  However, now that hardware is cheap and software development 
remains expensive, we can throw hardware at the performance issue and use 
frameworks that support rapid and relatively cheap development.  It's just a 
cost benefit equation - over some sensible lifetime, say five years, your app 
will cost X to develop and maintain, the equipment to run it will cost Y and 
then Z per year to supply electricity and air conditioning - you pay to heat up 
the computers, then you pay again to cool them down.  If your PHP app can run 
on less powerful equipment, the running costs will be lower.  However, in an 
app of any complexity, X will be the biggest cost, so that's the one to 
concentrate on.  Testing will be the lion's share of that cost, so you want a 
framework that supports effective testing.

The problem with PHP is the other side of the same coin - simplicity.  Other 
frameworks do more for you, and It's much cheaper to write a reliable, robust 
and scalable application using something like Go or Java.  Java is a very 
mature product, and so it's easy to find developers who know it.  Go is quite 
immature in comparison but it has all sorts of advantages such as native code 
generation and rapid garbage collection.

My guess is that you are looking at Go because you've reached the point where 
your PHP app is costing too much to maintain.  If I'm wrong that you are in 
this situation, I think a lot of other people are.  Five years ago I would have 
advised you to look at Java, but now we have Go as well.  Whichever you choose, 
it will not be as good as PHP in some respects and I predict that speed of 
redeployment will be one of them.

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

[go-nuts] WebAssembly as a target

['Mihai B' via golang-nuts]

I don't think we can expect anything before wasm supports GC (i.e. Phase 3 on 
wasm roadmap). Once GC is supported(not very soon) Go could be compiled through 
llgo[0]. One issue could be the binary size(.i.e due /reflect)

- Mihai
[0] https://llvm.org/svn/llvm-project/llgo/trunk/README.TXT

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