[go-nuts] Re: A modest format suggestion

[Leszek Kubik]

It wasn't mentioned here but I really like how C# IDE helps understanding 
function arguments. It's entirely true that arguments should have 
meaningful names but sometimes it's impossible. Standard C# function 
comments let you document arguments. The argument comment appears right 
when you need it, when you are at a point of providing a value for it. I 
haven't seen such thing in Go yet. You can provide additional info about 
the arguments inside function documentation but it's not standardised the 
way a common Go IDE would understand it. In practice I sometimes jump to 
the function definition to clarify the meaning of the argument but it could 
be more explicit.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/48e852da-0abf-4e0d-912b-e9de52b4958f%40googlegroups.com.

Re: [go-nuts] Timer.Reset() (again...)

[Leszek Kubik]

I have nothing to comment about timer.Reset() but your pseudo code made me 
wonder if there's an interval timer available in the library, and of course 
it is.

In the example you aim to do some work periodically, until another type of 
work succeeds. That's not a plain meaning of a timeout. In addition you may 
be interested in regular intervals not just "no sooner than x" so NewTicker 
sounds about right here. If occasionally the timeout preference may change, 
it's ok to start a new ticker.

timeout := <-timeoutConfigC
ticker := time.NewTicker(timeout)
defer ticker.Stop()
for {
select {
case timeout = <-timeoutConfigC:
ticker.Stop()
ticker = time.NewTicker(timeout) // if the user's new preference "just 
misses" this interval, oh well, next time then
case <-ticker.C:
handleTimeout() //periodic work 'a'
case work := <-workC:
if done := do(work); done {
return
}
}
}



On Wednesday, April 1, 2020 at 11:17:14 PM UTC+2, Neil Schellenberger wrote:
>
> Thank you very much for confirming that, Ian!
>
> FWIW the scenario is very roughly along the lines of a "best effort 
> re-configurable" timeout for a work loop:
>
> timeout := <-timeoutConfigC
> timer := time.NewTimer(timeout)
> defer timer.Stop()
> for {
>   select {
> case timeout = <-timeoutConfigC:
>   timer.Reset(timeout) // if the user's new preference "just misses" 
> this interval, oh well, next time then
> case <-timer.C:
>   handleTimeout()
>   timer.Reset(timeout)
> case work := <-workC:
>   if done := do(work); done {
> return
>   }
>   }
> }
>
> The actual use case is a protocol state machine with various user tunable 
> intervals.  It's fine if a new value doesn't get "applied" until the "next 
> time around".  
>
> Obviously there are plenty of other ways to handle this, but it got me 
> wondering if I understood "Timer.Reset()" properly or not.  And/or I may be 
> using an anti-pattern.  Do please let me know if I am :-)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/30d9914c-4321-4309-b50f-6aac6749fbd4%40googlegroups.com.

[go-nuts] Re: files stored in /home/$USER/.cache/go-build/

[Leszek Kubik]

https://golang.org/cmd/go/#hdr-Remove_object_files_and_cached_files

I wouldn't remove just some of them, that sounds like a bad idea in 
general. Remove all if you need to.

On Monday, March 30, 2020 at 6:34:17 AM UTC+2, lgo...@gmail.com wrote:
>
> What does Go use these files used for ? I've got loads of them...What 
> happens if I delete some or all ? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/49fb9bc2-e667-4f71-ad5f-5b17fbda8c90%40googlegroups.com.

[go-nuts] Re: Unmarshalling ordered nested dynamic xml

[Leszek Kubik]

I think that interface{} type would be useful in such case
var xml []interface{}

You can make convenience accessor functions like 
func Names() []Names {}




On Sunday, March 29, 2020 at 9:33:49 PM UTC+2, DrGo wrote:
>
> Hi,
> wondering how to unmarshall the xml below (also available here 
> https://play.golang.org/p/QtZwKmrn8HM) into a tree. The challenge is that 
> each element can nest  0 or more *ordered* child elements which can be of 
> different types (eg text, group, choose, macro etc). I tried unmarshalling 
> into a struct which embed the following type 
>
> type RenderingElement struct {
>  Names []Names `xml:"names"`
>  Date []Date `xml:"date"`
>  Label []Label `xml:"label"`
>  Text []Text `xml:"text"`
>  Number []Number `xml:"number"`
>  Choose []Choose `xml:"choose"`
>  Group []Group `xml:"group"`
> }
>
> This is simple but the problem is that if an element has children of 
> different types eg text and group I have no way of telling their order and 
> the order is important (essentially the xml codes for a formatting program).
>
> Any tips or example code on how to unmarshall this xml while retaining its 
> nested ordered structure?
>
> Thanks,
>
> const src = `
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>   hello 
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> `
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6897e30d-e293-45c0-b968-313a54d99e0c%40googlegroups.com.

Re: [go-nuts] Re: Slice reuse + GC

[Leszek Kubik]

Wait, by saying it would be nice to have the GC not trace elements between 
len and cap, you mean it would be nice to have GC recognize unreferenced 
elements of a slice between len and cap and free them (presumably if they 
are pointer or interface types)?

OK, I would say Go has quirks but I'm the type of an engineer who doesn't 
expect things to work as I like them but I dig how it actually works and 
live with that. In my opinion Go (or the Go tutorials) advertise slices too 
much, perhaps the problem is that there's no handy builtin list type with 
nice language sugar.

A fix for the situation of the topic could be implemented by the slice 
type. Imagine, if a slice value not only shared the pointer to the 
underlying buffer but also a list with references to all other slices 
holding on to the underlying buffer then such operation as s = s[x:y] could 
walk the list, find and free all unreferenced values in the underlying 
buffer (perhaps even assigning zero value to have consistent behavior 
regardless of []T or []*T). Such operation would be deterministic. Of 
course there could be an optimization in place, whenever the slice was 
derived from a named array, just keep some flag instead of the list of 
references to all other slices. I don't see how GC could achieve that in a 
consistent way since the GC may not even do the swipe between calls like s 
= s[:x]; s = s[:cap(x)]. Unfortunately I'm afraid that this would break 
some existing code (even if we also trim the cap property) thus keeping in 
mind the original notion of a slice as a window to some array makes sense 
to me.

As a side note, I think the append function has quirks too, so it's easy to 
make mistakes until you dig into it. The function signature shows it 
returns a new slice so it's easy to jump to conclusion that you can safely 
modify the new slice without affecting the original one, or on the other 
hand jump to conclusion that writes made to this slice would be seen in 
other slices. It all depends how you initially form the idea of what the 
slice type is.


On Friday, March 27, 2020 at 1:06:16 AM UTC+1, Keith Randall wrote:
>
> It's common practice to *write* to elements between the length and 
> capacity of a slice.  Usually, you use append to do that.
> It's bad practice to *read* elements between the length and capacity. 
> Which you can't do with a simple indexing op, of course. You would have to 
> reslice larger and then index.
> In that sense, it would be nice to have the GC not trace elements between 
> len and cap. They should be dead if you never read them, only write them. 
> It's hard to do in the GC, it requires a language change, etc. But it would 
> be nice.
>
>
> On Thursday, March 26, 2020 at 12:29:04 PM UTC-7 leszek...@gmail.com 
> wrote:
>
>>
>>
>>
>>> I disagree. I do that all the time. It's also how `append` was 
>>> implemented before it existed as a predeclared function. It's also, FWIW, 
>>> used in bytes.Buffer . I 
>>> agree that unless your API is very clear about it, you shouldn't really 
>>> access a slice past the length for one of your arguments. But there *are* 
>>> APIs where it's clear that's happening (e.g. anything having "append" in 
>>> it's doc-string) and there are use-cases where you control the slice for 
>>> its entire lifetime and where it can make code more readable.
>>>
>>
>>  I didn't even know that append wasn't there, but since we have it isn't 
>> it meant to be used in the first place?
>> Of course if we check the capacity, expanding past len is safe, like 
>> s[:cap(s)]. I would check the capacity only in case when I really don't 
>> want to end with a new slice buffer as a result of appending more than the 
>> available space.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4975efcd-4d31-4be0-9b34-03d125f096a9%40googlegroups.com.

Re: [go-nuts] Re: Slice reuse + GC

[Leszek Kubik]

> I disagree. I do that all the time. It's also how `append` was implemented 
> before it existed as a predeclared function. It's also, FWIW, used in 
> bytes.Buffer . I agree that 
> unless your API is very clear about it, you shouldn't really access a slice 
> past the length for one of your arguments. But there *are* APIs where it's 
> clear that's happening (e.g. anything having "append" in it's doc-string) 
> and there are use-cases where you control the slice for its entire lifetime 
> and where it can make code more readable.
>

 I didn't even know that append wasn't there, but since we have it isn't it 
meant to be used in the first place?
Of course if we check the capacity, expanding past len is safe, like 
s[:cap(s)]. I would check the capacity only in case when I really don't 
want to end with a new slice buffer as a result of appending more than the 
available space.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/26396fdd-543d-4af0-be95-154d36a505c1%40googlegroups.com.

Re: [go-nuts] Slice reuse + GC

[Leszek Kubik]

Actually *T was not a good example to make my point, as we can start 
debating about the GC walking the references and freeing the data pointed 
to. However when you have []T, and you refer to some continuous buffer of 
memory with some chunks [0:5] (gap) [50:100], etc there's not much benefit 
of "freeing" the elements in-between. Anyway, I assume slices are meant to 
be an abstract pointers to arrays and thus they should only change the 
visibility not the array


On Thursday, March 26, 2020 at 7:19:16 PM UTC+1, Leszek Kubik wrote:
>
> I let you consider an example:
>
> s := make([]*T, 100)
> s1, s2, s3 := s[:50], s[50:], s[:]
> ( x lines of code)
> s1 = s1[:5]
>
> Would you like the GC to free the elements past the last s1 slice len? 
> What if s2, s3 are still used somewhere...
>
>
> On Thursday, March 26, 2020 at 7:01:34 PM UTC+1, robfig wrote:
>>
>> I see, thank you.
>>
>> RE reducing the capacity, I want to distinguish freeing the memory (1) 
>> used for the slice and (2) referred to by the slice elements. I can easily 
>> see that freeing (1) is hard and not so beneficial, but I can't see why (2) 
>> would be difficult, and the benefit seems potentially much larger. In our 
>> case, each slice element has a handle to a sizable []byte, so that's why I 
>> was interested to know if they would remain live. 
>>
>> As an aside, (1) was addressed by Ian here:
>> https://groups.google.com/d/msg/golang-nuts/sVhjhiYLXNg/YNZ_H-JsBAAJ
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/57d4b27d-c650-492c-b931-aab0fbf39c68%40googlegroups.com.

Re: [go-nuts] Slice reuse + GC

[Leszek Kubik]

I let you consider an example:

s := make([]*T, 100)
s1, s2, s3 := s[:50], s[50:], s[:]
( x lines of code)
s1 = s1[:5]

Would you like the GC to free the elements past the last s1 slice len? What 
if s2, s3 are still used somewhere...


On Thursday, March 26, 2020 at 7:01:34 PM UTC+1, robfig wrote:
>
> I see, thank you.
>
> RE reducing the capacity, I want to distinguish freeing the memory (1) 
> used for the slice and (2) referred to by the slice elements. I can easily 
> see that freeing (1) is hard and not so beneficial, but I can't see why (2) 
> would be difficult, and the benefit seems potentially much larger. In our 
> case, each slice element has a handle to a sizable []byte, so that's why I 
> was interested to know if they would remain live. 
>
> As an aside, (1) was addressed by Ian here:
> https://groups.google.com/d/msg/golang-nuts/sVhjhiYLXNg/YNZ_H-JsBAAJ
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/179c7a55-80a6-497c-9a82-5e2c6db628af%40googlegroups.com.

[go-nuts] Re: Slice reuse + GC

[Leszek Kubik]

AFAIK it is allowed to re-slice past the len but it's rather not the way 
slices should be ever used. The word slice implies taking a portion from a 
bigger thing and that's always safe. When you append to the slice however, 
there's no new allocation if the underlying buffer still has place past the 
current slice len.

You missed the point about slices, I guess. Many slices can refer to the 
same internal buffer, giving you sort of window view of the data, thus as 
long as any slice still refer to the internal buffer GC won't collect it.


On Thursday, March 26, 2020 at 6:39:50 PM UTC+1, robfig wrote:
>
> Reducing a slice's length makes the elements unreachable, but the GC 
> appears to still treat them as live, based on this snippet:
> https://play.golang.org/p/SvsE-nXi-JA
>
> I would have expected the HeapInUse to go down in the second measurement. 
>
> Why is that? 
>
> I presume that the GC is traversing the slice's capacity rather than 
> length, but I'm not sure why this is necessary. Is there a way (without 
> using unsafe) to access slice elements past the length? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/27be27b0-5b55-4035-9953-072809fc7932%40googlegroups.com.

[go-nuts] Re: Crud Example

[Leszek Kubik]

If you can see response from tomcat server in your browser then certainly 
your go example can't bind to that port, try other port. Secondly when you 
put the address in the browser bar you are going to execute http GET. 
Finally, in your example the template is only prepared but not applied in 
response to any request. You have to reply to the request, i.e. write to 
http.ResponseWriter.

Happy coding!


On Saturday, March 21, 2020 at 10:21:50 PM UTC+1, Krishma Shah wrote:
>
> I have tried crud example for insert query and in cmd i m getting 
> http://localhost:8080 but when i search this url on google chrome  i m 
> getting tomcat,So can u please help me out what changes are required.
> For your reference i have attached go file and template file
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b0d9a494-0607-4a0f-a6ed-e94b3a37dd95%40googlegroups.com.

Re: [go-nuts] go test -race hanging with Go1.14, only with -a flag

[Leszek Kubik]

I don’t know the -a flag and go help testflags doesn’t mention it.

I guess you turned off something in your tests

LK

On Tue, 10 Mar 2020 at 11:24, Dan Kortschak  wrote:

> I have a package that is dependent on bazil.org/fuse for testing via a
> sysfs simulation package github.com/ev3go/sisyphus.
>
> For historical reasons, the travis testing used the -a flag (since
> removed because of the issue described here).
>
> Since Go1.14, the standard runtime tests on travis passed, but the
> -race tests hang. This is replicable on my local hardware (requiring a
> reboot to continue working on the codebase since a fuse mount remains
> after the hang, preventing access to the code directory).
>
> Running tests on either bazil.org/fuse or the intermediate dependency
> the same way does not cause the hang. This suggests to me that I'm
> probably doing something wrong with a lock and I'm deadlocking the fuse
> system in the kernel.
>
> However, when I remove the -a flag from the go test -race invocation,
> the tests complete and there is no complaint about data races. Nor does
> the hang happen with Go versions prior to Go1.14.
>
> Can anyone suggest why -a has this effect? or what has changed between
> 1.13 and 1.14 that might cause this? (Bisecting would be painful since
> it requires a reboot between iterations).
>
> The repository in question is github.com/ev3go/ev3dev and the PR that
> illustrates the issue is https://github.com/ev3go/ev3dev/pull/90.
>
> thanks
> Dan
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/83d84b29ce1969f0ea2aab6ac7e69e3d52b6c499.camel%40kortschak.io
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKQXsUZiQ3HVRCw3kw8ijd_GuEWYo4Y1cvYEDKU-HZAtc9efyg%40mail.gmail.com.

[go-nuts] Re: I'm writing my website in golang but there is issue called 404 page not found

[leszek . kubik]

Hello,

It would be much clearer if you posted a complete sample of a Go code. 
Which framework are you using for the server? I guess it could be something 
with the server config, can it accept POST methods? Did you test the server 
first, independently of your frontend, by using curl or PostMan? It could 
be a problem with preflight request from the browser. 

The screenshot of the console is too small to read. 

/Leszek

On Sunday, March 8, 2020 at 4:19:20 PM UTC+1, Ali Hassan wrote:
>
> [image: goSnippet.JPG][image: firefox.JPG]
>
> [image: xhrSnippet.JPG]
> [image: htmlSnippnet.JPG]Browser Error 404   please help me resolve this 
> error. I think this is because of html page but when try this 
> /register.html then whole page display on my console. I will exchange my 
> data 
>
>
> [image: buttonSnippnet.JPG]
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7dc12419-8f9c-43ea-8acb-0f8109fcac8b%40googlegroups.com.