[go-nuts] Is it possible to launch a Meltdown or Spectre attack with Go code?

['Eric Johnson' via golang-nuts]

Anyone have any insight into whether it is possible to launch a Meltdown or 
Spectre attack using Go code?

Go's general practice of preventing access beyond slice limits, and its 
habit of zeroing memory makes me think triggering a Spectre or Meltdown 
attack with Go code is very unlikely.

On the other hand, maybe clever use of the unsafe package means it is 
possible?

Eric.

-- 
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] Very simple, Td array

[Tong Sun]

Oh, Sorry, I was copying from the line  tr.Td[*1*] -- there is an extra
comma, ",".
That should be it. I've double-checked many times, but I can't now, as I'm
home now.

On Thu, Jan 4, 2018 at 6:37 PM, Dave Cheney  wrote:

> >   fmt.Printf("%#v %#v\n", tr.Td, , tr.Td[0])
>
> This line will not compile, are you sure this is the code that is
> executing?
>
> --
> 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/heZfZ-OZOSc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@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] Very simple, Td array

[Dave Cheney]

>   fmt.Printf("%#v %#v\n", tr.Td, , tr.Td[0])

This line will not compile, are you sure this is the code that is executing?

-- 
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] A blog post series on serving big satellite imagery with Go

[Pablo Rozas Larraondo]

This new part of the series focuses on the use of fast compressors such as
Snappy to improve access speed to image data:

https://medium.com/@p.rozas.larraondo/divide-compress-and-conquer-building-an-earth-data-server-in-go-part-2-88670cafc167

IMO fast compressors will play a very important role in the design of high
performance systems - as a method to overcome RAM speed limitations on
CPUs. Feedback, comments and experiences from the community are highly
appreciated!

Pablo

On Thu, Dec 21, 2017 at 2:04 AM, Michael Jones 
wrote:

> Certainly as you say, individual user patterns are not generally
> predictable. Sometimes aggregate patterns can be. The "sea of tiles" is the
> natural design and works great in normal cases. It seems the way to teach
> it in any case.
>
> Where the filesystem issue comes in would be, for example, the nominal 1
> meter per pixel Google Earth, which in plate carrée or like form with
> 400x400 pixel tiles consists of 253,701,184 tiles at that one ground sample
> distance. That is a lot for "ls" and a lot for most file systems to enjoy
> quickly accessing in a single directory. A pyramidal reduced resolution
> dataset hierarchy will require 4/3rds of this in total, or 338,268,246
> tiles. Finer details, such as 50cm advanced satellite and 10cm aerial/drone
> images scale the portions covered by 4x to 100x. So in the limit one will
> find the edge of what any OS designer expects "sane" developers to expect.
> :-)
>
> On Wed, Dec 20, 2017 at 3:33 PM, Pablo Rozas Larraondo <
> p.rozas.larrao...@gmail.com> wrote:
>
>> Hi Michael,
>>
>> Thanks for your comments, I totally agree with them. File systems will
>> struggle with the explosion of files resulting from the tile operation. As
>> you point out, other formats, such as geoTIFF, HDF5 or NetCDF define the
>> tiling or chunking process internally at the file level.
>>
>> The reason for creating the tiles as individual files in the article was
>> because this is ultimately intended to be stored on the cloud as objects
>> (this will be covered in the 3rd article). As far as I know, cloud object
>> stores (ie AWS S3, Google Cloud Storage) do not have a limitation in the
>> number of objects stored in a bucket (If someone has more information about
>> this, please share). That is why I proposed to split the tiles as separate
>> files in the article.
>>
>> I also find the caching considerations quite amusing. It is a complex
>> matter and, in my experience, cache optimisations are quite dependent on
>> the user access patterns, which are normally hard to predict.
>>
>> Cheers,
>> Pablo
>>
>>
>>
>> On Wednesday, December 20, 2017 at 2:24:01 AM UTC+1, Michael Jones wrote:
>>>
>>> Thank you, Pablo. Very helpful to have this kind of step by step example
>>> for Go developers.
>>>
>>> I have some familiarity in this area and I'd say the practical issues in
>>> large-scale, high-throughput operation tend to relate to the native
>>> filesystem. Too many small files overwhelm them and can make directory
>>> lookups slow. Too many directory levels leads to slow filesystem traversal.
>>> Sometimes it can help to dice the big image into small independent tiles
>>> and store those tiles as a mosaic in one's own file type. This is the
>>> nature of TILED vs ROW storage in the TIFF format. The next level of tuning
>>> is about leverage the operating system's cache of data read from disk in a
>>> productive way. You can have our own cache in RAM, of course, but the OS
>>> likely has that same data cached. There are cases where memory mapping the
>>> small tile files does what you would want.
>>>
>>> There are also dynamic considerations. It may well be that a client
>>> accessing tile [i][j] will soon want one of the eight surrounding tiles.
>>> over time, it may be that a direction of browsing through tile-space can be
>>> established and this can encourage read-ahead, though the benefit is not
>>> always assured; maybe the accesses are structured and maybe they are not.
>>>
>>> Some high-throughput servers in the era of smart web clients (aka Google
>>> Maps / leaflet ./ etc.) refuse to build custom images and only supply tiles
>>> in response to a request--leaving tile assembly to the client.
>>>
>>> Just some thoughts. None of them would help make what you've done any
>>> clearer or more helpful to the reader.
>>>
>>> Best,
>>> Michael
>>>
>>>
>>> On Tue, Dec 19, 2017 at 3:37 PM, Pablo Rozas Larraondo <
>>> p.rozas@gmail.com> wrote:
>>>
 Thank you Thomas for the link to the vips library. I didn't know about
 it and now I want to read more about its design and internals.

 The objective of the article was to set a baseline using the Go image
 library and play with several factors to see how it affects performance. In
 this first article, I wasn't really trying to come up with the fastest
 possible image server but to point a few basic techniques that can improve
 access speed and reduce 

[go-nuts] Very simple, Td array

[Tong Sun]

Sorry, it must be the end of the day and my mind is no longer working...

So I have a type

type Tr struct {
Td  []*Td`xml:"http://www.w3.org/1999/xhtml td,omitempty" 
json:"td,omitempty"`
XMLName xml.Name `xml:"http://www.w3.org/1999/xhtml tr,omitempty" 
json:"tr,omitempty"`
}

and 

fmt.Printf("%#v %#v\n", tr.Td, , tr.Td[*0*])

will output, 

[]*main.Td{(*main.Td)(0xc4200271d0), (*main.Td)(0xc420027220), 
(*main.Td)(0xc420027270)} {Colspan:"", Rowspan:"", Text:...}}

but why 

fmt.Printf("%#v %#v\n", tr.Td, , tr.Td[*1*])

will give error?:

panic: runtime error: index out of range



I.e., how to access the second (and third) Td? 

Please help, my mind is no longer working. Thx. 



-- 
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] Combine low traffic website

[Andrew]

This project looks good: 

https://github.com/Sketchground/aproxygo
https://groups.google.com/forum/#!topic/golang-nuts/7F4H4WC7DA4

-- 
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] Extending an existing type by embedding

[Dave Cheney]

On Friday, 5 January 2018 01:15:16 UTC+11, matthe...@gmail.com wrote:
>
> Tong, I’m glad this works for you.
>
> Dave, reading back I see that we’re giving conflicting advice on pointers 
> for MyTokenizer. While my view is that the dereferences are not necessary 
> here, perhaps you have other reasons to have a pointer in this case?
>

I was just guessing, I didn't fully understand the problem the OP was 
asking.
 

>
> Thanks,
> Matt
>
> On Wednesday, January 3, 2018 at 7:25:15 PM UTC-6, Tong Sun wrote:
>>
>> Thanks Matt -- I thought it wouldn't work, but having thinking it over, 
>> and over, now I finally make it working.
>>
>> Thanks a lot
>>
>> On Wed, Jan 3, 2018 at 9:46 AM,  wrote:
>>
>>> Ah, this kind of function signature may be better:
>>>
>>> func WalkBody(t *html.Tokenizer, w TokenVisitor) {
>>>
>>> Then you would use the regular *html.Tokenizer methods to do the walk 
>>> and pass each token to the TokenVisitor to be parsed for output depending 
>>> on which TokenVisitor was picked.
>>>
>>> Matt
>>>
>>> On Wednesday, January 3, 2018 at 8:30:14 AM UTC-6, Tong Sun wrote:



 On Wed, Jan 3, 2018 at 9:07 AM,  wrote:

>
>> Why do you need varying types if you are just using html.Tokenizer 
> methods? What is the difference between each type?
>


 The difference is the VisitToken(), using the same function of 
 `WalkBody()`, but achieving different results. 

 For example, the current output from 
 https://github.com/suntong/lang/blob/master/lang/Go/src/xml/htmlParserTokens2.go
  is 
 one way of abstracting the html structure, and I also planning to produce 
 text output that close to XML Outline View from Oxygen XML Editor, or 
 convert HTML to .md. 

 All of above involve walking the HTML the same way, but producing 
 results differently. 



 -- 
>>> 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/FRE_A6cNzW8/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] FOSDEM 2018 Go Devroom Schedule

[Francesc Campoy Flores]

Hi gophers,

Good news, after our amazing reviewers evaluated *many* talk proposals 
we've come out with the following schedule 
 for the Go Devroom.


https://fosdem.org/2018/schedule/track/go/

To all those  whose talks were accepted, congratulations! For those whose 
talks were not, thanks again for your help and understanding!
You all rock, and with your collaboration this is going to be the best Go 
Devroom FOSDEM has ever seen!

All the talks will be recorded and released on YouTube shortly after the 
conference on February 3rd.
I hope to see many of you around!

Cheers,

Francesc 
VP of Developer Relations at source{d} 

-- 
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] Client and server stub not generated for grpc-go

[Amandeep Gautam]

I am trying to write a grpc server in go but am unable get the generated 
client and server stub in the file generated by plugin.
Here is the paste of the file generated: https://pastebin.com/kfi99MxK

>From what I have researched, it is because of faulty protobuf installation 
but I am not sure what is exactly wrong and how to debug the root cause.

Any help is appreciated.

-- 
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] Underlying arrays and their slices passed to functions

[Frank Davidson]

Thanks!!! Very helpful blog post!!

So, in proc, the slice header is copied, then an entirely new array is 
created - []byte{5,6,7,8} - and the slice header copy is set to point at 
that new array, and then discarded, whereas in proc 2, the slice header is 
not reset, and so still points to the original array?

On Thursday, January 4, 2018 at 1:23:33 PM UTC-5, Jan Mercl wrote:
>
> On Thu, Jan 4, 2018 at 7:08 PM Frank Davidson  > wrote:
>
> > I'm sure this has probably been answered before, but I have a question 
> about when a slice's underlying array is copied? In this code:
>
> In your code the underlying arrays are never copied when passed around.
>
>
>
> -- 
>
> -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.

Re: [go-nuts] Underlying arrays and their slices passed to functions

[Jan Mercl]

On Thu, Jan 4, 2018 at 7:08 PM Frank Davidson  wrote:

> I'm sure this has probably been answered before, but I have a question
about when a slice's underlying array is copied? In this code:

In your code the underlying arrays are never copied when passed around.



-- 

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

Re: [go-nuts] Underlying arrays and their slices passed to functions

[Ian Lance Taylor]

On Thu, Jan 4, 2018 at 10:08 AM, Frank Davidson  wrote:
>
> I'm sure this has probably been answered before, but I have a question about
> when a slice's underlying array is copied? In this code:
>
> https://play.golang.org/p/TnMFo-rYKzq
>
> package main
>
> import (
> "fmt"
> )
>
> func main() {
>
> out := []byte{1, 2, 3, 4}
> fmt.Println(out)
> proc(out)
> fmt.Println(out)
> proc2(out)
> fmt.Println(out)
>
> }
>
> func proc(p []byte) {
> p = []byte{5,6,7,8}
> }
>
> func proc2(p []byte) {
> p[0] = 5
> p[1] = 6
> p[2] = 7
> p[3] = 8
> }
>
>
> The output is:
>
> [1 2 3 4]
> [1 2 3 4]
>
> [5 6 7 8]
>
>
> I assume that in proc the slice's underlying array is being copied as well?
> Hence p is referring to a new array within the function and, thus, the
> underlying original array is not modified, even though it's capacity
> wouldn't have to change? But in proc2 there is no copy of the underlying
> array made, hence the original array is modified? What is the rule for when
> the underlying array is also copied and when it is not?

In the way that I use the word "copied", the underlying array of a
slice is never copied (except if you do it yourself, or via the copy
or append functions).

I recommend that you read https://golang.org/blog/slices.

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] retpolines in the go compiler?

[Ian Lance Taylor]

On Thu, Jan 4, 2018 at 9:41 AM,   wrote:
>
> The last few days have seen some scary CPU security issues. One is Spectre,
> which takes advantage of branch prediction and cache timings to read memory
> that should be inaccessible.
>
> The main (only?) mitigation that I have seen is to use "retpolines" - a
> portmanteau of 'return trampoline' - instead of indirect jump instructions.
> The technique is described in detail in a blog post, and patches have been
> written for LLVM and Linux already. It replaces a single instruction with
> about seven and blocks branch prediction, so it is expected to have a
> significant performance impact, but the security is worth it in some
> contexts.
>
> Will the Go compiler be writing retpoline instructions instead of indirect
> jumps? I am particularly worried about the performance implications for code
> that calls lots of interface - will it use retpolines only under a
> configuration flag?

While I do not yet fully understand how this defense works, I want to
point out that the blog post you cite explicitly says "we do not need
to (strongly) worry for most binaries."  It goes on to say that the
primary concern is the host operating system, which at least at
present is not written in Go.

So at the moment I think that 1) we need do anything quickly; 2) there
is no reason to use retpolines for all programs, only those that
handle sensitive data, so if we do find it necessary to add this
feature to the Go compiler it will be optional; 3) it's at least
possible that hardware vendors will fix this in new processors before
we have to seriously worry about it for Go.

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] Underlying arrays and their slices passed to functions

[Frank Davidson]

I'm sure this has probably been answered before, but I have a question 
about when a slice's underlying array is copied? In this code:

https://play.golang.org/p/TnMFo-rYKzq

package main

import (
"fmt"
)

func main() {

out := []byte{1, 2, 3, 4}
fmt.Println(out)
proc(out)
fmt.Println(out)
proc2(out)
fmt.Println(out) 

}

func proc(p []byte) {
p = []byte{5,6,7,8}
}

func proc2(p []byte) {
p[0] = 5
p[1] = 6
p[2] = 7
p[3] = 8
}


The output is:

[1 2 3 4]
[1 2 3 4] 

[5 6 7 8] 


I assume that in proc the slice's underlying array is being copied as well? 
Hence p is referring to a new array within the function and, thus, the 
underlying original array is not modified, even though it's capacity 
wouldn't have to change? But in proc2 there is no copy of the underlying 
array made, hence the original array is modified? What is the rule for when 
the underlying array is also copied and when it is not?

-- 
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] retpolines in the go compiler?

[spenczar5]

The last few days have seen some scary CPU security issues. One is Spectre 
, which takes advantage of branch prediction 
and cache timings to read memory that should be inaccessible.

The main (only?) mitigation that I have seen is to use "retpolines" - a 
portmanteau of 'return trampoline' - instead of indirect jump instructions. 
The technique is described in detail in a blog post 
, and patches have been 
written for LLVM  and Linux 
 already. It replaces a single 
instruction with about seven and blocks branch prediction, so it is 
expected to have a significant performance impact, but the security is 
worth it in some contexts.

Will the Go compiler be writing retpoline instructions instead of indirect 
jumps? I am particularly worried about the performance implications for 
code that calls lots of interface - will it use retpolines only under a 
configuration flag?

-- 
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] Mixed type array in Go

[Tong Sun]

On Thursday, January 4, 2018 at 10:59:35 AM UTC-5, Tong Sun wrote:
>
> That's really *comprehensive*. Thanks a million Josh!
>
>
Hi Josh, FTA, 

I've archived your masterpiece as 
https://github.com/suntong/lang/blob/master/lang/Go/src/ds/MixedType.go
and
https://play.golang.org/p/lmmkTxVJht1

so that people can enjoy it right away.

Thanks again

-- 
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] Mixed type array in Go

[Tong Sun]

That's really *comprehensive*. Thanks a million Josh!

-- 
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] Mixed type array in Go

[Josh Humphries]

You would typically define the array type as an array of some interface
that is implemented by both purchase and coupon. You can then use a
type-switch or type-assertion to determine/assert the actual type at
runtime, on a per element basis.

If the two types do not share some interface (e.g. common methods), you
could define the array as []interface{}. But this also allows code to
accidentally add *any* kind of value to the array (not just a purchase or a
coupon). So it may be better to create a marker interface -- an unexported
interface with a no-op unexported marker method -- and make purchase and
coupon both implement that interface.


For example:

type checkoutObject interface {
  checkoutObject()
}

type Purchase struct {
// yadda yadda
}

func (p *Purchase) checkoutObject() {
// no-op marker method
}


type Coupon struct {
// yadda yadda
}

func (c *Coupon) checkoutObject() {
// no-op marker method
}

// assert that Purchase and Coupon implement checkoutObject
var _ checkObject = (*Purchase)(nil)
var _ checkObject = (*Coupon)(nil)


*// Now you can define your array like so:*
*var checkoutItems []checkoutObject*
*// The compiler will only let you add *Purchase and *Coupon*
*// values to the array.*

*// You can use the values at runtime like so:*
*for e := range checkoutItems {*
*switch e := e.(type) {*
*case *Purchase:*
*// handle purchase*
*case *Coupon:*
*// handle coupon*
*default:*
*panic(fmt.Sprintf("unsupported type: %T", e))*
*}*
*}*



*Josh Humphries*
jh...@bluegosling.com

On Thu, Jan 4, 2018 at 10:24 AM, Tong Sun  wrote:

> I need a data struct / solution that I can store mixed data-types into an
> array. How to architect that?
>
>
> Details -- Consider the checkout point at the cashier, the checkout
> process receives the following string of instructions
>
>1. purchase
>2. coupon
>3. purchase
>4. purchase
>
> I want to store all the above request data into an array, so I don't lost
> the sequence how they arrive, which in turn requests the array element to
> be either purchase or coupon.
>
>
> How to make it happen? 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.
>

-- 
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] Mixed type array in Go

[Tong Sun]

I need a data struct / solution that I can store mixed data-types into an 
array. How to architect that?


Details -- Consider the checkout point at the cashier, the checkout process 
receives the following string of instructions

   1. purchase
   2. coupon
   3. purchase
   4. purchase
   
I want to store all the above request data into an array, so I don't lost 
the sequence how they arrive, which in turn requests the array element to 
be either purchase or coupon.


How to make it happen? 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] ListenAndServ and channels

[Keith Brown]

I am trying to Serve a webpage while running a ticker in the background. I 
am trying to generate a random number, genRandom() , periodically and 
publish it on a channel so generic() can see the results. I have something 
like this https://play.golang.org/p/6d1xmqpUYY7 but I don't know how to get 
channel results to generic()? Do I need to make my mc channel a global? 

-- 
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] Extending an existing type by embedding

[matthewjuran]

Tong, I’m glad this works for you.

Dave, reading back I see that we’re giving conflicting advice on pointers 
for MyTokenizer. While my view is that the dereferences are not necessary 
here, perhaps you have other reasons to have a pointer in this case?

Thanks,
Matt

On Wednesday, January 3, 2018 at 7:25:15 PM UTC-6, Tong Sun wrote:
>
> Thanks Matt -- I thought it wouldn't work, but having thinking it over, 
> and over, now I finally make it working.
>
> Thanks a lot
>
> On Wed, Jan 3, 2018 at 9:46 AM,  wrote:
>
>> Ah, this kind of function signature may be better:
>>
>> func WalkBody(t *html.Tokenizer, w TokenVisitor) {
>>
>> Then you would use the regular *html.Tokenizer methods to do the walk and 
>> pass each token to the TokenVisitor to be parsed for output depending on 
>> which TokenVisitor was picked.
>>
>> Matt
>>
>> On Wednesday, January 3, 2018 at 8:30:14 AM UTC-6, Tong Sun wrote:
>>>
>>>
>>>
>>> On Wed, Jan 3, 2018 at 9:07 AM,  wrote:
>>>

> Why do you need varying types if you are just using html.Tokenizer 
 methods? What is the difference between each type?

>>>
>>>
>>> The difference is the VisitToken(), using the same function of 
>>> `WalkBody()`, but achieving different results. 
>>>
>>> For example, the current output from 
>>> https://github.com/suntong/lang/blob/master/lang/Go/src/xml/htmlParserTokens2.go
>>>  is 
>>> one way of abstracting the html structure, and I also planning to produce 
>>> text output that close to XML Outline View from Oxygen XML Editor, or 
>>> convert HTML to .md. 
>>>
>>> All of above involve walking the HTML the same way, but producing 
>>> results differently. 
>>>
>>>
>>>
>>> -- 
>> 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/FRE_A6cNzW8/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.