Thank you for the clarification.
sorry to break the general rule, i'm new to golang-nuts
as to the question, i figured out i used wrong words, what i need in fact
is1. a hint to tell compiler that some object are safe to alloc on stack(in
case that we use it as interface so it escape from stack) 2
On Thu, May 27, 2021 at 9:27 PM cheng dong wrote:
> problem is compiler often don't known how programs organize objects, or,
> some memory pattern could not be known at compile time.
> and sometimes, delete point is very obvious in some programming models.
> finally i think developer should take
problem is compiler often don't known how programs organize objects, or,
some memory pattern could not be known at compile time.
and sometimes, delete point is very obvious in some programming models.
finally i think developer should take their risk taking some unsafe
operations by himself (lik
On Fri, May 28, 2021 at 12:56 PM cheng dong wrote:
> to avoid false delete object, we could add some checking code in
> markDelete just like what we do with raceenable.
> one complicate case is internal pointer, we could recursively mark delete
> or mark delete internal pointer by hand ?
>
This
I hope your proposal is never implemented. Manual memory management is the
cause of far too many bugs. And I say that as someone who started
programming in the mid 1970's (more than forty years ago). If you want
manual memory management there are plenty of languages which provide it.
As a data poi
to avoid false delete object, we could add some checking code in markDelete
just like what we do with raceenable.
one complicate case is internal pointer, we could recursively mark delete
or mark delete internal pointer by hand ?
On Friday, May 28, 2021 at 10:03:28 AM UTC+8 cheng dong wrote:
>
1. first case
```go
func do(x SomeInterface) {...}
func outer() {
var x = new(A)
do(x)
markDelete(x) // explicit delete x if we know x's lifetime end here
}
```
if we know in advance that x's lifetime will finish when outer end. can we
mark delete x. and the compiler can safely alloc x on
Hm interesting - so if you just panic(io.EOF) instead of return io.EOF,
then it works as expected. Must be the code is recovering the panic
somewhere. Thanks for the help
On Thursday, May 27, 2021 at 5:37:38 PM UTC-5 Ian Lance Taylor wrote:
> On Thu, May 27, 2021 at 3:33 PM Steven Penny wrote:
On Thu, May 27, 2021 at 3:33 PM Steven Penny wrote:
>
> Did you even look at my example? If EOF is not right, then what is? How do I
> do what Im trying to do?
https://play.golang.org/p/JlbEFvmsUum
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
Did you even look at my example? If EOF is not right, then what is? How do
I do what Im trying to do?
On Thursday, May 27, 2021 at 4:37:38 PM UTC-5 Ian Lance Taylor wrote:
> On Thu, May 27, 2021 at 2:25 PM Steven Penny wrote:
> >
> > Ian, that doesnt make sense. Then how will the scanner know t
On Thu, May 27, 2021 at 2:25 PM Steven Penny wrote:
>
> Ian, that doesnt make sense. Then how will the scanner know that the input is
> empty? EOF is the only graceful error I know for this case, its the only
> sentinel that I am aware of, to differentiate a "real error" from "input is
> empty"
On Thu, May 27, 2021 at 2:22 PM Terry Phelps wrote:
>
>
> My background. I've written a lot of C and Python (and other things), but am
> new to Go.
>
> I am getting results from fmt.Fprintf that I can't understand. Here's what
> I'm puzzled about:
>
> I wrote, in Go, a file hex-and-ASCII dumper
Ian, that doesnt make sense. Then how will the scanner know that the input
is empty? EOF is the only graceful error I know for this case, its the only
sentinel that I am aware of, to differentiate a "real error" from "input is
empty".
On Thursday, May 27, 2021 at 4:10:06 PM UTC-5 Ian Lance Tayl
My background. I've written a lot of C and Python (and other things), but
am new to Go.
I am getting results from fmt.Fprintf that I can't understand. Here's what
I'm puzzled about:
I wrote, in Go, a file hex-and-ASCII dumper of the kind everyone has seen.
(Like the Unix xxd command, for exa
On Thu, May 27, 2021 at 6:41 AM Steven Penny wrote:
>
> If I want to scan through a string, I can do this:
>
> ~~~go
> package main
>
> import (
>"fmt"
>"strings"
> )
>
> func main() {
>r := strings.NewReader("west north east")
>for {
> var s string
> _, e := fmt.Fscan(
Take this with a grain of salt, as I've never used PostCSS and had to look
up what it even was.
https://github.com/ysugimoto/gssp - this is Golang Style Sheet
Postprocessor which appears to be at least directed at the same task.
Of course, as PostCSS is a tool that applies to .css files, there
On Thu, May 27, 2021 at 9:48 AM sharath chandra
wrote:
>
> The issue with Golang to retrieve raw data from Json / string variable
>
> ```
> I have a Json sample message something similar with special characters
>
> func main() {
> msg := []byte(`{"key":"ABC\u001d\u263aDEF"}`)
> m := make
The issue with Golang to retrieve raw data from Json / string variable
```
I have a Json sample message something similar with special characters
func main() {
msg := []byte(`{"key":"ABC\u001d\u263aDEF"}`)
m := make(map[string]interface{})
json.Unmarshal(msg,&m)
ConvertToCs
If I want to scan through a string, I can do this:
~~~go
package main
import (
"fmt"
"strings"
)
func main() {
r := strings.NewReader("west north east")
for {
var s string
_, e := fmt.Fscan(r, &s)
fmt.Printf("%q %v\n", s, e)
if e != nil { break }
}
}
~~~
Thank you!
So it seems I misunderstood what append() does. I expected that all of the
slices I had created with append() would have just enough capacity, such that
every use of append() would allocate new memory and copy. It surprises me that
my code worked as well as it did.
J
> On May 26, 2
I would like to consider several alternatives. Pros and cons of each of
them. Thank you in advance)
--
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+u
21 matches
Mail list logo
