[go-nuts] Re: [DSP] butterworth 4th order High-pass filter requests

[Brian Candler]

http://www.catb.org/~esr/faqs/smart-questions.html#homework

On Wednesday, 7 December 2022 at 18:09:31 UTC seokta...@gmail.com wrote:

> Hi guys,
>
> I've been diving into GOLANG less than 1 month.
> Now I am looking for the DSP filter for butterworth 4th order High-pass 
> filter for study.
>
> I just found 
> github.com/jfcg/butter
> but 'butter' package has 1st order and 2nd order filter kernal.
>
> Is there any 4th order for butterworth high-pass filter for GOLANG ?
>
> Thanks in advance, filter kernal desing is too difficult for the newbee 
> for GOLANG :-)
>
> Cheers!
>

-- 
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/cf12cf9c-2a7b-4f69-a037-88da83ca12e3n%40googlegroups.com.

[go-nuts] Re: Hide Golang Code from Exported package

[Marcello H]

if you produce an executable, nobody sees the actual Go code.
build it with:
go build -ldflags "-s -w"

or you could try to obfuscate it:
https://github.com/burrowers/garble

or you can make a self-extracting executable


Op woensdag 7 december 2022 om 19:09:31 UTC+1 schreef nsing...@gmail.com:

> Hi All,
> We are looking for a way to distribute a Golang Package. but We ant to 
> hide the Code which we have written. 
> We went Through Creating A DLL to distribute but it crashes at different 
> point while running. As we have distribute to Both linux and windows . And 
> i found that for linux we can use plugin. But the crash for windows dll  
> after importing the file is concerning for us and its happening at random 
> points in the code also "bad sweepgen in refill".  
> If there is any other way to distribute the code without showing the 
> source code please Tell
> Thanks
> Neeraj
>

-- 
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/572afb6e-9934-4bdc-ab75-bf1175415e07n%40googlegroups.com.

[go-nuts] Go 1.20 Release Candidate 1 is released

[announce]

Hello gophers,

We have just released go1.20rc1, a release candidate version of Go 1.20.
It is cut from release-branch.go1.20 at the revision tagged go1.20rc1.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://go.dev/issue/new

If you have Go installed already, an easy way to try go1.20rc1
is by using the go command:
$ go install golang.org/dl/go1.20rc1@latest
$ go1.20rc1 download

You can download binary and source distributions from the usual place:
https://go.dev/dl/#go1.20rc1

To find out what has changed in Go 1.20, read the draft release notes:
https://tip.golang.org/doc/go1.20

Cheers,
Michael and Jenny for the Go team

-- 
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/2PHDJ542TQGYlXw2r2Y4Ew%40geopod-ismtpd-1-4.

Re: [go-nuts] Re: Interfaces for nested types with common structure

['Daniel Lepage' via golang-nuts]

On Wed, Dec 7, 2022 at 4:39 AM Brian Candler  wrote:

> On Tuesday, 6 December 2022 at 21:05:48 UTC dple...@google.com wrote:
>
>> I am trying to figure out if there's a good way to build a helper that
>> can be used against different sets of nested types that have a common
>> structure.
>>
>> So, for example, say there are two libraries, `lib1` and `lib2` and both
>> define types Foo, Bar, and Baz with:
>>
>> type Foo struct { ... }
>> type Bar struct { ... }
>> func (b *Bar) GetFoo() *Foo { ... }
>> type Baz struct { ... }
>> func (b *Baz) GetBar() *Bar { ... }
>>
>> But `lib1` and `lib2` both define different additional methods on some of
>> these structs, so I can't just merge them into a single library.
>>
>
> It seems to me that lib1.{Foo,Bar,Baz} and lib2.{Foo,Bar,Baz} are
> completely different types.  They just happen to have similar names.
>
> Hence I ask, what's the commonality that you're trying to expose?  If it's
> that both lib1.Baz and lib2.Baz have a GetBar() method, then that sounds
> like an interface - except if one returns a lib1.Bar and the other returns
> a lib2.Bar, then they are not the same interface at all, so you're back to
> "these are completely different types".  Is there something common in Foo ?
>


Why not just have HelperFn1(lib1.Baz) and HelperFn2(lib2.Baz)?
>

My actual use case involves a code generator, where lib1 and lib2 (and
possibly dozens of additional libraries) are all outputs of the same
generator with slightly different arguments, generated by various different
teams and therefore entirely outside of my control.

The generator in question reads a schema file and outputs a library of Go
structs for all the data types defined by the schema. There are more than a
thousand such data types; they have getters and setters for their
attributes, and they're all nested in a giant tree, so e.g. code could call

root := {}
root.GetFoo().GetBar().GetBaz().GetQux().GetFleem().SetName("hello")

The problem is that various users of the code generator have their own
schemas, which are generally made by taking a common standard schema and
adding extra fields needed by whatever specific project the users are
working on. So for example one project might add a .GetSpoo() method to the
Foo type, while another adds GetAlias to Fleem, etc.

What I really want to do is be able to write a helper like:

package examplehelper

func SetFleemName(root ???, name string) {
root.GetFoo().GetBar().GetBaz().GetQux().GetFleem().SetName(name)
}

such that any project can have its own generated library and can call
`examplehelper.SetFleemName(root, "foo")` on a Root{} from their own
generated library, as long as the Root has GetFoo(), the Foo has GetBar(),
etc. down to the Fleem having a SetName(string).

This is technically possible with generics, but not practical, because it
requires writing e.g.:

x := lib1.Root{}
helper.SetFleemName[*lib1.Fleem, *lib1.Qux, *lib1.Baz, *lib1.Bar,
*lib1.Foo](x, "foo")

and in my real use case that list of type parameters would have more than a
thousand types in it.

Right now I'm experimenting with whether it's reasonable to use code
generation to solve this - a code generator could either just copy a helper
library and replace all the imports with a specific generated library, or
could build a generated-library-specific "bridge" library that defines a
bunch of

var SetFleemName = generichelper.SetFleemName[*lib1.Fleem, *lib1.Qux, ...]

But there's a lot of overhead to having everything go through a generator,
and it makes the code harder to read, harder to debug, and harder to use in
IDEs. I am hoping that there's some Golang feature I'm just not aware of
that would allow me to do this in the language itself, but I haven't been
able to find one so far.

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/CAAViQtgco5qCX%3DLrTcaJ0q2VnuixwYBk-KcCuyoO5XPPSMpufQ%40mail.gmail.com.

Re: [go-nuts] Re: Why not tuples?

['Thomas Bushnell BSG' via golang-nuts]

Use the json package to parse the incoming data. Transform it as you
please. Use the json package to format the output.

I'm not sure I see the problem.

On Sat, Dec 3, 2022, 10:47 PM Diogo Baeder  wrote:

> Hi there, sorry for weighting in so late in the game, but I just started
> again to learn Go and was thinking why the language still doesn't have a
> tuple type.
>
> Now, imagine this scenario: I have a web application which has to access a
> webservice that responds with JSON payloads; These payloads are a list of
> values, where each value is a smaller list like '[20220101, 1.234, "New
> York"]'. And these smaller lists follow the same type sequence: int64,
> float64, string. Suppose that I want to filter those values and send a
> response to the client, with the data structure unchanged (same format and
> types). Today, it doesn't seem to be possible to do that in Go, unless I do
> some dirty hack like decoding to '[]any' and then cast to the other types,
> and then hack again to put these values in the response to the client.
>
> I totally understand the reasoning for preferring the usage of structs for
> heterogeneous data (and I myself do prefer them, they're much more powerful
> in general), but there's real world data that's available like in the
> example above, and we just can't go on changing them at their sources. I
> might be mistaken (please let me know if it's the case), but it seems like
> Go is missing an opportunity to interoperate with what's a fundamental data
> structure in many other languages (Python, Rust etc). I'm having a lot of
> fun learning to use the language, and would be happy to see this feature
> being implemented at the core.
>
> (Maybe what I said above is total BS, I acknowledge that since I'm an
> almost complete ignorant in the language)
>
> Cheers!
>
> On Thursday, April 19, 2018 at 1:03:55 PM UTC-3 Louki Sumirniy wrote:
>
>> Multiple return values. They do kinda exist in a declarative form of
>> sorts, in the type signature, this sets the number and sequence and types
>> of return values. You could even make functions accept them as also input
>> values, I think, but I don't think it works exactly like this. I'm not a
>> fan of these things because of how you have to nominate variables or _ and
>> type inference will make these new variables, if you  := into whatever the
>> return was.
>>
>> I'm not sure what the correct word is for them. Untyped in the same way
>> that literals can be multiple types (especially integers) but singular in
>> their literal form.
>>
>>
>> On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
>>>
>>> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy 
>>> wrote:
>>>
>>> > Sorry for the self-promotion but it was relevant in that I was working
>>> on how to tidy up the readability of my code and needed multiple returns
>>> and simple untyped tuples were really not nearly as convenient as using a
>>> type struct.
>>>
>>> I have no idea what you mean by 'untyped tuples' because Go does not
>>> have tuples, or at least not as a well defined thing. I can only guess if
>>> you're trying to implement tuples in Go with an array, slice or a struct,
>>> ...? To add to my confusion, Go functions can have as many return values as
>>> one wishes just fine, ie. I obviously do not even understand what problem
>>> you're trying to solve. Sorry.
>>>
>>>
>>> --
>>>
>>> -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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8e728e0f-341d-4340-a868-aac028dfc443n%40googlegroups.com
> 
> .
>

-- 
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/CA%2BYjuxt_bR0wOxkiTp7pYNp-%3DiyzE_KTS-Rk1oRW1wpCv09CUA%40mail.gmail.com.

[go-nuts] [DSP] butterworth 4th order High-pass filter requests

[이석태]

Hi guys,

I've been diving into GOLANG less than 1 month.
Now I am looking for the DSP filter for butterworth 4th order High-pass 
filter for study.

I just found 
github.com/jfcg/butter
but 'butter' package has 1st order and 2nd order filter kernal.

Is there any 4th order for butterworth high-pass filter for GOLANG ?

Thanks in advance, filter kernal desing is too difficult for the newbee for 
GOLANG :-)

Cheers!

-- 
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/58eec99e-4e3b-4beb-967f-6d567a31527dn%40googlegroups.com.

[go-nuts] Hide Golang Code from Exported package

[neeraj singhi]

Hi All,
We are looking for a way to distribute a Golang Package. but We ant to hide 
the Code which we have written. 
We went Through Creating A DLL to distribute but it crashes at different 
point while running. As we have distribute to Both linux and windows . And 
i found that for linux we can use plugin. But the crash for windows dll  
after importing the file is concerning for us and its happening at random 
points in the code also "bad sweepgen in refill".  
If there is any other way to distribute the code without showing the source 
code please Tell
Thanks
Neeraj

-- 
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/0c0bcfc6-1789-4d62-8811-901768a44e88n%40googlegroups.com.

Re: [go-nuts] Golang 1.19+ preemption model on a preemptive linux kernel?

['drc...@google.com' via golang-nuts]

>From the POV of not-runtime-code, preemption can happen anywhere.  
Certainly with GOMAXPROCS > 1, there is OS preemption, and Go's default 
goroutine preemption is now potentially preemptive in most parts of 
non-runtime functions.
On Monday, December 5, 2022 at 7:12:54 PM UTC-5 ren...@ix.netcom.com wrote:

> I don’t think the analysis by alphadose in the issue you cite is correct. 
> Go added async pre-emption (via signals) and I believe it can preempt a Go 
> thread anywhere but in an internal critical section. Ian would know for 
> sure. It is certainly not only at a function call boundary because that 
> would cause the “infinite spin loop blocking GC” issue. Once a routine is 
> preempted any available routine could run on the same processor/OS thread.
>
> On Dec 5, 2022, at 5:20 PM, Andrew Athan  wrote:
>
> In brief then, in the presence of os threads running on a kernel that can 
> preempt threads, it is incorrect to assume that any two statements within a 
> goroutine will run atomically (both run, or not at all), irrespective of 
> the simplicity of those statements, or whether any function calls involved 
> are inlined, etc...
>
> On Monday, December 5, 2022 at 3:18:09 PM UTC-8 Andrew Athan wrote:
>
>> The statement I made is actually a bit stronger than the one you 
>> confirmed: Even if the goroutines are using atomic load/store, the 
>> preemtive nature of the os threads could easily interrupt one goroutine 
>> between an atomic load and its use of that value, giving another goroutine 
>> the opportunity to change the stored value at the atomic load location, 
>> potentially leading to a data race -- particularly when the loader is 
>> storing to a related but different location and/or without a CAS on the 
>> original loaded value.
>>
>> To answer your question, no ... within the go runtime, I DO NOT claim to 
>> have found instances of that kind of load/check/store as separate 
>> operations within a function such that those operations are assumed to run 
>> atomically.
>>
>> However, I've run into a couple of such instances in public repos. Thus, 
>> I wanted to confirm my thinking. For example, I initiated a discussion 
>> about same here:
>>
>> https://github.com/alphadose/haxmap/issues/26
>>
>> (I ran across haxmap while reviewing issues in the golang repo relative 
>> to sync.Map)
>>
>> On Monday, December 5, 2022 at 10:45:10 AM UTC-8 Ian Lance Taylor wrote:
>>
>>> On Mon, Dec 5, 2022 at 10:03 AM Andrew Athan  wrote: 
>>> > 
>>> > I'm having trouble finding definitive information about golang's 
>>> preemption model when running with GOMAXPROCS>1 on a multi-core Intel with 
>>> preemtive linux kernel. 
>>> > 
>>> > As I understand it, in such a scenario, two goroutines may be 
>>> scheduled by the go runtime onto two separate system threads on two 
>>> separate CPUs. 
>>> > 
>>> > Isn't it true then, that irrespective of whether the two goroutines 
>>> are scheduled onto separate CPUs, the OS may preemptively interrupt either 
>>> of those goroutines to let the other run? Also, that if they are indeed 
>>> scheduled onto separate CPUs, that the memory accesses made by those 
>>> goroutines are interleaved even if no individual goroutine is "preempted"?
>>>  
>>> > 
>>> > I'm asking because in reviewing the code of some "lock free" 
>>> concurrent data structures written in go, it appears the authors have made 
>>> certain assumptions about race conditions (e.g., the code of on goroutine 
>>> assumes that another goroutine won't perform a load/store between two 
>>> function calls the first goroutine makes to check a boolean and store a 
>>> value). 
>>> > 
>>> > Given that goroutines are mappes onto system threads, and that in a 
>>> preemptive kernel those threads may be preempted and/or irrespective of the 
>>> preemptive kernel issue may run on separate cores, no assumptions should be 
>>> made about the "atomicity" of multiple statements in a goroutine relative 
>>> to other goroutines. Right? 
>>> > 
>>> > Where can I get the most current and accurate information about this 
>>> topic? 
>>>
>>> I'm not aware of any detailed documentation of the issues you are 
>>> looking at. So the most current and accurate information is the 
>>> source code. Or this mailing list. 
>>>
>>> You are correct that non-atomic memory operations made by different 
>>> goroutines can be freely interleaved. If there is any code in the 
>>> runtime that assumes otherwise, that code is badly broken. If you can 
>>> point to the specific code that you are concerned about, perhaps we 
>>> can allay your concerns, or perhaps we can fix the bug. Thanks. 
>>>
>>> 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...@googlegroups.com.
>
> To view this discussion on the web visit 
> 

Re: [go-nuts] Re: Why not tuples?

[Diogo Baeder]

Thanks Brian, that's actually similar to what I'm already doing.

Cheers!

On Wednesday, December 7, 2022 at 8:16:53 AM UTC-3 Brian Candler wrote:

> On Tuesday, 6 December 2022 at 22:27:38 UTC dple...@google.com wrote:
>
>> It'd be great if, for example, you could tag an entire type like:
>>
>> type Row struct { `json:tuple`
>>   date int64
>>   score float64
>>   city string
>> }
>>
>> so that 
>>
>> var v []Row
>> json.Unmarshal(data, )
>>
>> would automatically parse the triples into usable structs (and 
>> json.Marshal would turn them back into lists).
>>
>
> You can wrap that pattern yourself though, and it's not too much work.
> https://go.dev/play/p/JtUxQUQdd92
>
>

-- 
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/0d101208-c021-4fb2-add4-ca498437e04fn%40googlegroups.com.

Re: [go-nuts] Re: Why not tuples?

[Brian Candler]

On Tuesday, 6 December 2022 at 22:27:38 UTC dple...@google.com wrote:

> It'd be great if, for example, you could tag an entire type like:
>
> type Row struct { `json:tuple`
>   date int64
>   score float64
>   city string
> }
>
> so that 
>
> var v []Row
> json.Unmarshal(data, )
>
> would automatically parse the triples into usable structs (and 
> json.Marshal would turn them back into lists).
>

You can wrap that pattern yourself though, and it's not too much work.
https://go.dev/play/p/JtUxQUQdd92

-- 
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/574cb836-c77f-44e5-841e-920b5b1bf48an%40googlegroups.com.

[go-nuts] Re: Interfaces for nested types with common structure

[Brian Candler]

On Tuesday, 6 December 2022 at 21:05:48 UTC dple...@google.com wrote:

> I am trying to figure out if there's a good way to build a helper that can 
> be used against different sets of nested types that have a common structure.
>
> So, for example, say there are two libraries, `lib1` and `lib2` and both 
> define types Foo, Bar, and Baz with:
>
> type Foo struct { ... }
> type Bar struct { ... }
> func (b *Bar) GetFoo() *Foo { ... }
> type Baz struct { ... }
> func (b *Baz) GetBar() *Bar { ... }
>
> But `lib1` and `lib2` both define different additional methods on some of 
> these structs, so I can't just merge them into a single library.
>

It seems to me that lib1.{Foo,Bar,Baz} and lib2.{Foo,Bar,Baz} are 
completely different types.  They just happen to have similar names.

Hence I ask, what's the commonality that you're trying to expose?  If it's 
that both lib1.Baz and lib2.Baz have a GetBar() method, then that sounds 
like an interface - except if one returns a lib1.Bar and the other returns 
a lib2.Bar, then they are not the same interface at all, so you're back to 
"these are completely different types".  Is there something common in Foo ?
 

>
> I would like to write a helper function `HelperFn(baz ??)` such that I can 
> call `HelperFn({})` and also `Helperfn({})`.
>
>
Why not just have HelperFn1(lib1.Baz) and HelperFn2(lib2.Baz)?

Perhaps there is some point in your code where a variable could hold either 
a lib1.Baz or a lib2.Baz.  If so, what's the type of that variable?  And 
what's the helper function going to do with the value that you're passing 
in, which could be of either type?

Whilst you can use generics in the way you've shown to call GetBar() and 
GetFoo(), you can't use generics for accessing struct members, so 
everything would have to be done via methods - even reading or setting 
elements of {lib1|lib2}.Foo.  I think at the bottom there has to be *some* 
common interface.

How important is static type checking in this application? You could always 
just write HelperFn(interface {}) which does type assertions on its 
parameter.  Admittedly this is ugly:
https://go.dev/play/p/14vs2Ce7P42

-- 
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/cb23ef8d-5db9-4a02-b5dd-96576640b364n%40googlegroups.com.