[go-nuts] Re: Web development with Go
Of course, Brian. I meant the CA Certificates. Merson On Saturday, February 5, 2022 at 8:11:49 PM UTC+11 Brian Candler wrote: > On Saturday, 5 February 2022 at 00:05:18 UTC merson...@actmedical.com.au > wrote: > >> the same app >> rewritten in Go reduces the size by a huge amount as the only thing you >> need to include in a scratch base image is the binary plus >> some certificates. >> > > I wouldn't put certificates into a container image either, and definitely > not the related private keys. I'd store them as kubernetes Secrets and > provide them to the container that way. It reduces the exposure of the > private keys, and allows certificates to be replaced without rebuilding the > image - e.g. to deploy the same container in two different places. > -- 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/8e1a259f-3590-46d3-8db6-cba60fe86907n%40googlegroups.com.
[go-nuts] Re: Is Go good choice for porting graph based app?
Kamil, Are the JSON files using a set schema, or could they be any arbitrary schema? Not that the latter can't be handled by Go, but IMO Go excels at the former because of ability to statically type. -Mike On Sunday, February 6, 2022 at 6:15:25 AM UTC-5 kziem...@gmail.com wrote: > Thank you Sebastian Binet, I need to check more gonum project. > > You are right drv drv that Python is not true culprit here. Problem is > that it seems a bad written code. Maybe after a while I will change my mind > about it, but it looks bad right now. > > Here you have list of dependencies that came with this code. > attrs==21.2.0 > azure-functions==1.7.2 > certifi==2021.5.30 > charset-normalizer==2.0.4 > graphviz==0.18 > idna==3.2 > jmespath==0.10.0 > jsonschema==4.1.2 > Pillow==8.4.0 > pyrsistent==0.18.0 > raven==6.10.0 > requests==2.26.0 > svg.path==4.1 > urllib3==1.26.6 > > I have a bunch of problem with it. I normal use Python 3.6, because it is > standard Python on Ubuntu OS and I'm fine with that. But, jsonschema v. > 4.1.2 wasn't available on Python 3.6. After installing new version of > Python I now have a problem with Pillow. I still don't know what to do with > that, so they told me to switch to Windows. And I just begin with it. > > Best, > Kamil > > sobota, 5 lutego 2022 o 16:43:46 UTC+1 drv drv napisał(a): > >> I don't know the background of this Python code but *" It seems >> underdeveloped, buggy and running it first time is a pain, because of >> dependencies. "* is not a language problem. >> I cannot imagine any dependencies in this kind of program. >> JSON "equals" dictionaries in case of Python and it supports natively so >> it is quite fast and can be write very simple and elegant code. >> It is true that GO is faster (in this case I guess 2x on single core) but >> if you cannot take advance of goroutines (and multicore) use Python. >> >> On Thursday, 3 February 2022 at 23:26:14 UTC+1 kziem...@gmail.com wrote: >> >>> Hello, >>> >>> I was handed proof-of-concept app written in Python. It seems >>> underdeveloped, buggy and running it first time is a pain, because of >>> dependencies. Basically it need to read some graphs stored in JSON files >>> and manipulated them accordingly and write them to JSON files again. >>> >>> It seems that porting it now to more suitable language is worth a gain >>> at this stage and I wonder if Go is a good choice? I read and watch many >>> Ian Lance Taylor presentations about generics, so I know that only that >>> generic graph (tree) data structure is something that can be a pain, but >>> in this case it would be were small issue. It seems that we have only few >>> data types to be stored in graph, mostly strings and ints. >>> >>> I'm not true gopher, so I don't know if Go is proper choice for this >>> task. I don't believe that Python is any better, but maybe I should check >>> another language. >>> >>> Also, if someone know better thing to sore graphs than JSON, I would >>> appreciate it any suggestion. >>> >>> I don't write anymore about this app, since I don't know if company >>> allows for it. >>> >>> Best regards, >>> Kamil >>> >> -- 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/264afa9b-1acf-4695-b0b8-14dc25e3e254n%40googlegroups.com.
Re: [go-nuts] decoding DWARF data
Reader.SeekPC() is useful. Thanks. The problem was due to my misunderstanding of how inlined functions are represented in the DWARF data. I've solved it now. Thanks again. On Saturday, February 5, 2022 at 6:49:06 PM UTC Ian Lance Taylor wrote: > On Sat, Feb 5, 2022 at 1:45 AM stephen.t@gmail.com > wrote: > > > > I'm trying to decode the DWARF data in an ELF binary and I'm not sure > how to handle functions. > > > > I'm using the elf/dwarf package in the Go standard library and > successfully using it to identify compile units and source files and also > to find line entries for an executed address. > > > > What I can't see is how to relate a dwarf.LineEntry to a function (or > SubProgram as it is called in DWARF terminology). > > > > If the SubProgram TAG has both Low PC and High PC attributes then I can > see how it can be done. Where it gets tricky is if a SubProgram has been > inlined. > > > > What I don't fully understand is how InlinedSubPrograms relate to > SubPrograms. > > > > I realise that this isn't really a Go question but I'm hoping someone > has used the Go standard library in this way and understands how to solve > this problem. > > The DWARF line number information maps PC values to a file name and a > line number. It sounds like you want to map a PC value to a function, > and you want to consider inlining information. To do that use > https://pkg.go.dev/debug/dwarf#Reader.SeekPC to get an Entry and look > for the AttrName or AttrLinkageName attribute. Note that, as the > documentation says, SeekPC is not efficient if you need to look up a > bunch of PC values. For that you'll want to loop through the entries, > call the Ranges method, and build a lookup table. > > Hope this helps. > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d583eb22-0d1a-4e0f-a581-3dbc02673fa2n%40googlegroups.com.
Re: [go-nuts] Going thorough "Type parameters proposal" with Go 1.18 beta
Thank you so much, about explanation. This is the first time that I hear
about named type and unnamed type in Go.
Thank you even more for giving my another reason to learn Go Spec. I try it
before, but then I was lost in section about runes, so I go to learn UTF-8.
But soon enough I understand that to learn UTF-8 I need to go learn about
Unicode and I try to find time for it.
Best regards,
Kamil
niedziela, 6 lutego 2022 o 03:47:36 UTC+1 Ian Lance Taylor napisał(a):
> On Sat, Feb 5, 2022 at 4:27 PM Kamil Ziemian wrote:
> >
> > On the other hand this code compiled
> > > package main
> > >
> > > import "fmt"
> > >
> > > type Stringer interface {
> > > String() string
> > > }
> > >
> > > type StringableVector[T Stringer] []T
> > >
> > > type someFloat float64
> > >
> > > func (sF someFloat) String() string {
> > > return fmt.Sprintf("someFloat: %v", float64(sF))
> > > }
> > >
> > > func main() {
> > > var varStringer Stringer = someFloat(7)
> > > sliceSomeFloat := make([]someFloat, 3)
> > >
> > > var varStringableVector StringableVector[someFloat] = sliceSomeFloat
> > >
> > > fmt.Printf("varStringer type: %T\n", varStringer)
> > > fmt.Printf("sliceSomeFloat type: %T\n", sliceSomeFloat)
> > > fmt.Printf("varStringableVector type: %T\n", varStringableVector)
> > > }
> >
> > and produced result
> >
> > > stringerVar type: main.someFloat
> > > sliceScomeFloat type: []main.someFloat
> > > stringableVectorVar type: main.StringableVector[main.someFloat]
> >
> > Variable stringableVectorVar is not of interface type, because in such
> case its type printed by fmt.Printf should be []main.someFloat. So, it
> looks like to me as []main.someFloat is implicitly conversed to
> main.StringableVector[main.someFloat].
> >
> > Answer to my previous questions was that []stupidFloat/[]someFloat is
> not of type StringableVector[stupidFloat] so it doesn't have method
> String() string. But in my poor understanding of Go, this code shouldn't
> compile due to implicit conversion of two types.
> >
> > Can anyone explain to me, where am I wrong?
>
> You are not permitted to assign directly from one named type to
> another named type. But here you are assigning an unnamed type,
> []someFloat, to a named type, StringableVector[someFloat]. Assigning
> an unnamed type to a named type is permitted if the underlying type of
> the named is identical to the unnamed type, which in this case it is.
> The same is true in non-generic Go. The exact rules are at
> https://go.dev/ref/spec#Assignability.
>
> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/cd1e67f7-0b56-4223-92ae-04663625f70cn%40googlegroups.com.
[go-nuts] Re: Is Go good choice for porting graph based app?
Thank you Sebastian Binet, I need to check more gonum project. You are right drv drv that Python is not true culprit here. Problem is that it seems a bad written code. Maybe after a while I will change my mind about it, but it looks bad right now. Here you have list of dependencies that came with this code. attrs==21.2.0 azure-functions==1.7.2 certifi==2021.5.30 charset-normalizer==2.0.4 graphviz==0.18 idna==3.2 jmespath==0.10.0 jsonschema==4.1.2 Pillow==8.4.0 pyrsistent==0.18.0 raven==6.10.0 requests==2.26.0 svg.path==4.1 urllib3==1.26.6 I have a bunch of problem with it. I normal use Python 3.6, because it is standard Python on Ubuntu OS and I'm fine with that. But, jsonschema v. 4.1.2 wasn't available on Python 3.6. After installing new version of Python I now have a problem with Pillow. I still don't know what to do with that, so they told me to switch to Windows. And I just begin with it. Best, Kamil sobota, 5 lutego 2022 o 16:43:46 UTC+1 drv drv napisał(a): > I don't know the background of this Python code but *" It seems > underdeveloped, buggy and running it first time is a pain, because of > dependencies. "* is not a language problem. > I cannot imagine any dependencies in this kind of program. > JSON "equals" dictionaries in case of Python and it supports natively so > it is quite fast and can be write very simple and elegant code. > It is true that GO is faster (in this case I guess 2x on single core) but > if you cannot take advance of goroutines (and multicore) use Python. > > On Thursday, 3 February 2022 at 23:26:14 UTC+1 kziem...@gmail.com wrote: > >> Hello, >> >> I was handed proof-of-concept app written in Python. It seems >> underdeveloped, buggy and running it first time is a pain, because of >> dependencies. Basically it need to read some graphs stored in JSON files >> and manipulated them accordingly and write them to JSON files again. >> >> It seems that porting it now to more suitable language is worth a gain at >> this stage and I wonder if Go is a good choice? I read and watch many Ian >> Lance Taylor presentations about generics, so I know that only that generic >> graph (tree) data structure is something that can be a pain, but in this >> case it would be were small issue. It seems that we have only few data >> types to be stored in graph, mostly strings and ints. >> >> I'm not true gopher, so I don't know if Go is proper choice for this >> task. I don't believe that Python is any better, but maybe I should check >> another language. >> >> Also, if someone know better thing to sore graphs than JSON, I would >> appreciate it any suggestion. >> >> I don't write anymore about this app, since I don't know if company >> allows for it. >> >> Best regards, >> Kamil >> > -- 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/a4b87d2e-b72b-447f-8aa3-ad58479da573n%40googlegroups.com.
