Re: [go-nuts] Memory operations hung in semacquire state, GC routine parked while holding semaphore?

['Alex Kristiansen' via golang-nuts]

Thanks for the response Michael.

> It looks like a Windows minidump (unsurprisingly) can't follow the 
relation. A regular goroutine stack trace dump that gets emitted on a 
forced exit or crash is able to show both sides of the system stack switch 
with a little bit of configuration.

Yeah, that was my understanding too. Again, not a windows expert, but my 
understanding is that there's no equivalent to the "send SIGABRT to get a 
stack dump" trick on windows? 

I didn't file a bug initially, as this version appears to be more than two 
minor releases behind, and I also wasn't completely sure if it was a bug or 
some weird AV/VM behavior. 

The entire stack trace is pretty huge, so I put it here: 
https://gist.github.com/fearful-symmetry/1e6546640f667731b3fe2a90f96b5680
On Wednesday, May 29, 2024 at 9:26:50 PM UTC-7 Michael Knyszek wrote:

> The example goroutine in the original post is parked waiting for some 
> other goroutine to finish up the GC cycle. Somewhere, a goroutine is 
> getting stuck trying to finish it up, which could possibly be a deadlock. 
> (I am especially suspicious of a deadlock bug because most threads are 
> stopped there.) It would be good to confirm whether application CPU time 
> drops to zero or plateaus to some very consistent number, which would 
> support the deadlock theory.
>
> On Wednesday, May 29, 2024 at 11:09:30 AM UTC-4 robert engels wrote:
>
> I am pretty sure runtime is supposed to crash the process if it slows the 
> allocators “too much” (I believe there are some config settings to control 
> this).
>
> The runtime never intentionally crashes a process due to rate or volume of 
> allocation. There is an optional memory limit, but it's soft in that the 
> runtime gives up trying to maintain the limit at some point; see below and 
> see https://go.dev/doc/gc-guide.
>
>
> If you have enough Go routines it may look like they are hung - you need 
> to track specific routines by their ID. The stack certainly looks like it 
> is trying to allocate memory for a slice - and it is being paused - because 
> it is waiting on the GC lock.
>
> Are you doing any native code? You could have heap corruption and that is 
> also why the GC thread is getting hung.
>
> If the GC thread makes progress albeit slowly - I would settle on my first 
> guess - memory leak...
>
> I suspect a memory leak is not at play here. In the case of a memory leak, 
> by default, your live heap may steadily increase, and the time between GC 
> cycles increases proportionally. The GC is designed such that the overall 
> impact should stay roughly constant as your heap grows by default. In this 
> case, memory leak should appear exactly as expected: a rise in memory use 
> over time.
>
> If GOMEMLIMIT is in use (which is non-default; you have to ask for it), 
> then a memory leak may result in progressively more frequent GC cycles. 
> However, the worst-case failure to make progress ("GC death spiral") should 
> be prevented in practice by the runtime already. It puts a hard limit on 
> the amount of CPU time that can be taken by the GC every CPU-second, 
> instead letting memory use increase. Don't get me wrong, it can still slow 
> down the application a good bit, and maybe under some circumstances it'll 
> still look like a hang. It is also possible there's a bug in the GC CPU 
> limiter or something.
>
> But, from what I've seen so far in this bug, I'm more convinced of a 
> deadlock bug than the application failing to make progress. Lots of 
> goroutines lining up on gcMarkDone just sounds too specific to me.
>
>
> On May 29, 2024, at 10:00 AM, 'Alex Kristiansen' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> That's an interesting idea, I probably wouldn't have thought of that on my 
> own. Is that expected behavior for memory pressure on Windows+golang? I 
> don't have much windows experience, so my assumption would be that the 
> Windows equivalent of the OOMKiller would kick in and just kill the 
> application. 
>
> On Tuesday, May 28, 2024 at 4:04:15 PM UTC-7 robert engels wrote:
>
> Feels like a memory leak to me. I would look for growing heap size in the 
> gc logs. I am guessing that the system is not completely hung - but rather 
> the runtime is having a hard time obtaining more memory, so it is slowing 
> the allocators to a rate that makes them appear hung.
>
> It may be that the process has consumed nearly all of the OS memory too - 
> so the OS is having a hard-time responding to malloc requests.
>
> i.e. The system is not making progress.
>
> On May 28, 2024, at 3:54 PM, 'Alex Kristiansen' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> This is an odd one. For reference, this is a customer mac

Re: [go-nuts] Memory operations hung in semacquire state, GC routine parked while holding semaphore?

['Alex Kristiansen' via golang-nuts]

That's an interesting idea, I probably wouldn't have thought of that on my 
own. Is that expected behavior for memory pressure on Windows+golang? I 
don't have much windows experience, so my assumption would be that the 
Windows equivalent of the OOMKiller would kick in and just kill the 
application. 

On Tuesday, May 28, 2024 at 4:04:15 PM UTC-7 robert engels wrote:

> Feels like a memory leak to me. I would look for growing heap size in the 
> gc logs. I am guessing that the system is not completely hung - but rather 
> the runtime is having a hard time obtaining more memory, so it is slowing 
> the allocators to a rate that makes them appear hung.
>
> It may be that the process has consumed nearly all of the OS memory too - 
> so the OS is having a hard-time responding to malloc requests.
>
> i.e. The system is not making progress.
>
> On May 28, 2024, at 3:54 PM, 'Alex Kristiansen' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> This is an odd one. For reference, this is a customer machine, Windows 
> server 2016, compiled with go1.20.11. The application just hangs after a 
> number of days; windows minidump reveals that most threads are doing this:
>
>   Goroutine 462 - User: unicode/utf16/utf16.go:106 unicode/utf16.Decode 
> (0xe6e391) [semacquire]
>  0  0x00e2d116 in runtime.gopark
>  at runtime/proc.go:382
>  1  0x00e3df5c in runtime.goparkunlock
>  at runtime/proc.go:387
>  2  0x00e3df5c in runtime.semacquire1
>  at runtime/sema.go:160
>  3  0x00e0ac2f in runtime.semacquire
>  at runtime/sema.go:111
>  4  0x00e0ac2f in runtime.gcMarkDone
>  at runtime/mgc.go:787
>  5  0x00128c10 in ???
>  at ?:-1
>  6  0x00dfe7da in runtime.deductAssistCredit
>  at runtime/malloc.go:1217
>  7  0x00dfdff0 in runtime.mallocgc
>  at runtime/malloc.go:932
>  8  0x00e3f972 in runtime.makeslice
>  at runtime/slice.go:103
>  9  0x00e6e391 in unicode/utf16.Decode
>  at unicode/utf16/utf16.go:106
> 10  0x00e72a7b in syscall.UTF16ToString
>  at syscall/syscall_windows.go:63
> 11  0x00eb7a67 in os.(*File).readdir
>  at os/dir_windows.go:43
> 12  0x00eb72c5 in os.(*File).Readdirnames
>  at os/dir.go:70
> 13  0x00fb623a in path/filepath.glob
>  at path/filepath/match.go:346
> 14  0x00fb5ea5 in path/filepath.globWithLimit
>  at path/filepath/match.go:273
> 15  0x031de255 in path/filepath.Glob
>  at path/filepath/match.go:243
>
> Multiple threads, all waiting on a semaphore inside mallocgc. The actual 
> reason we're waiting for memory changes, obviously (sometimes a string 
> method, or hashmap allocation, or logging call...). This behavior has 
> remained consistent across multiple hangs across a number of weeks. After a 
> bit of digging into the minidump, this (I think) is the thread that's 
> holding the semaphore(s), at least based on the line numbers:
>
>   Goroutine 37 - User: :0 ??? (0x7ffb0e056974) (thread 5628)
> 0  0x7ffb0e056974 in ???
> at ?:-1
> 1  0x00e5c5a0 in runtime.systemstack_switch
> at runtime/asm_amd64.s:463
> 2  0x00e0ade5 in runtime.gcMarkDone
> at runtime/mgc.go:855
> 3  0x00128c10 in ???
> at ?:-1
> 4  0x00e5e881 in runtime.goexit
> at runtime/asm_amd64.s:1598
>
> Note that the precise point in gcMarkDone can change. I have another 
> minidump showing a hang at a different point in the same method:
>
> Goroutine 19 - Go: :0 ??? (0x208351516f8) (thread 7164) [unknown wait 
> reason 30] 
> 0 0x7ffe66e66974 in ??? 
> at ?:-1 
> 1 0x00e9c5a0 in runtime.systemstack_switch 
> at runtime/asm_amd64.s:463 
> 2 0x00e4acff in runtime.gcMarkDone 
> at runtime/mgc.go:807 
> 3 0x00128c10 in ??? 
> at ?:-1 
> 4 0x00e9e881 in runtime.goexit 
> at runtime/asm_amd64.s:1598 
>
> The commonality between these treads appears to be the `stacktrace()` 
> method. 
>
> Does anyone have any ideas for how to further debug this? Has anyone seen 
> anything like this? I've never seen anything like this before, and I can't 
> really reproduce it, as the only behavior is "let the application sit and 
> run for a few days." The only vaguely similar issue I've found is this, 
> which ment

[go-nuts] Memory operations hung in semacquire state, GC routine parked while holding semaphore?

['Alex Kristiansen' via golang-nuts]

This is an odd one. For reference, this is a customer machine, Windows 
server 2016, compiled with go1.20.11. The application just hangs after a 
number of days; windows minidump reveals that most threads are doing this:

  Goroutine 462 - User: unicode/utf16/utf16.go:106 unicode/utf16.Decode 
(0xe6e391) [semacquire]
 0  0x00e2d116 in runtime.gopark
 at runtime/proc.go:382
 1  0x00e3df5c in runtime.goparkunlock
 at runtime/proc.go:387
 2  0x00e3df5c in runtime.semacquire1
 at runtime/sema.go:160
 3  0x00e0ac2f in runtime.semacquire
 at runtime/sema.go:111
 4  0x00e0ac2f in runtime.gcMarkDone
 at runtime/mgc.go:787
 5  0x00128c10 in ???
 at ?:-1
 6  0x00dfe7da in runtime.deductAssistCredit
 at runtime/malloc.go:1217
 7  0x00dfdff0 in runtime.mallocgc
 at runtime/malloc.go:932
 8  0x00e3f972 in runtime.makeslice
 at runtime/slice.go:103
 9  0x00e6e391 in unicode/utf16.Decode
 at unicode/utf16/utf16.go:106
10  0x00e72a7b in syscall.UTF16ToString
 at syscall/syscall_windows.go:63
11  0x00eb7a67 in os.(*File).readdir
 at os/dir_windows.go:43
12  0x00eb72c5 in os.(*File).Readdirnames
 at os/dir.go:70
13  0x00fb623a in path/filepath.glob
 at path/filepath/match.go:346
14  0x00fb5ea5 in path/filepath.globWithLimit
 at path/filepath/match.go:273
15  0x031de255 in path/filepath.Glob
 at path/filepath/match.go:243

Multiple threads, all waiting on a semaphore inside mallocgc. The actual 
reason we're waiting for memory changes, obviously (sometimes a string 
method, or hashmap allocation, or logging call...). This behavior has 
remained consistent across multiple hangs across a number of weeks. After a 
bit of digging into the minidump, this (I think) is the thread that's 
holding the semaphore(s), at least based on the line numbers:

  Goroutine 37 - User: :0 ??? (0x7ffb0e056974) (thread 5628)
0  0x7ffb0e056974 in ???
at ?:-1
1  0x00e5c5a0 in runtime.systemstack_switch
at runtime/asm_amd64.s:463
2  0x00e0ade5 in runtime.gcMarkDone
at runtime/mgc.go:855
3  0x00128c10 in ???
at ?:-1
4  0x00e5e881 in runtime.goexit
at runtime/asm_amd64.s:1598

Note that the precise point in gcMarkDone can change. I have another 
minidump showing a hang at a different point in the same method:

Goroutine 19 - Go: :0 ??? (0x208351516f8) (thread 7164) [unknown wait 
reason 30] 
0 0x7ffe66e66974 in ??? 
at ?:-1 
1 0x00e9c5a0 in runtime.systemstack_switch 
at runtime/asm_amd64.s:463 
2 0x00e4acff in runtime.gcMarkDone 
at runtime/mgc.go:807 
3 0x00128c10 in ??? 
at ?:-1 
4 0x00e9e881 in runtime.goexit 
at runtime/asm_amd64.s:1598 

The commonality between these treads appears to be the `stacktrace()` 
method. 

Does anyone have any ideas for how to further debug this? Has anyone seen 
anything like this? I've never seen anything like this before, and I can't 
really reproduce it, as the only behavior is "let the application sit and 
run for a few days." The only vaguely similar issue I've found is this, 
which mentions interference from AV software: 
https://github.com/golang/go/issues/52178. 


Right now I'm waiting for the results of a gctrace log, as well as setting 
GODEBUG=asyncpreemptoff=1, but other than that, I'm a bit out of ideas.  

-- 
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/9c78ef6f-0190-4981-ab1f-ed18ad2f1080n%40googlegroups.com.

Re: [go-nuts] Re: Design patterns in Go

[alex-coder]

Hi All,

in case someone is in interest of the subject I repost here what I have 
found in the internet some time ago.
>>I apologize for being so intrusive.
>>I will only provide links to educational resources, in case it would be 
interesting for anyone.
>>GitHub - AlexanderGrom/go-patterns: Design patterns in Golang 
 (in russian)
>>Go Patterns · GitBook (tmrts.com) 
>>GitHub - PacktPublishing/Go-Design-Patterns-for-Real-World-Projects: Go: 
Design Patterns for Real-World Projects, by Packt 

>>Patrones de Diseño en Go (designpatternsingo.com) 
 (in spanish)

But I would like to stress one thing.
Due to absence in GO dynamic dispatching some of the patterns must be 
implemented, say as they must be in GO. :-)

Thank you.

понедельник, 1 апреля 2024 г. в 19:20:17 UTC+3, Ionenet SA: 

> I think many of you are confusing things. Many GOF patterns are still the 
> basis of today's programming. For example, the way that React or Vue manage 
> states, whatever you are using Pinia or Redux, they are no more than the 
> Observer pattern combined with the Proxy. And they are now native in 
> vanilla JavaScript. The observer is at the basis of event driven 
> programming. The Model-View-Controller itself is another combination of GOF 
> patterns. All the lambda functionality is an application of the Strategy 
> pattern and there are plenty of examples in modern programming that they 
> are nothing more than patterns. All the Martin Fowler's patterns are 
> nothing more than a combination of GOF patterns. The entire functionality 
> of history and ctrl+z/ctrl+y functionality is nothing more than a 
> combination of State/Memento. So I disagree completely about the idea that 
> patterns are to overcome Java limitations. The fact that some modern 
> languages natively implement a pattern in the form of a construct (for 
> example lambda functions to implement strategy) does not make the patterns 
> useless, but rather illustrate their usefulness.
>
> So, while some patterns are useless today, while some others are natively 
> implemented in many languages, including PHP, knowing them is still very 
> useful to understand how things work and where they come from. Otherwise 
> you will get submerged by a myriad of fancy names (in Laravel's style) and 
> you have to figure out and finally learn the same wheel with a different 
> name and the incorrect way.
>
> Think about it.
>
> On Wednesday, March 19, 2014 at 2:15:02 PM UTC-4 DV wrote:
>
>> My interpretation of what was said above was more along the lines that 
>> some of the patterns in the gang-of-four book exist not because they're 
>> good patterns in themselves, but that they exist because the languages they 
>> were designed for have various shortcomings and a certain type rigidness 
>> that doesn't exist in Go, so why bother using them? 
>>
>> Some sort of AbstractFactoryOfFactoryFactories is always present in every 
>> non-trivial Java project I've ever seen, but almost nobody bothers with it 
>> in Go. If that pattern is difficult to implement in Go (it might be, I 
>> never tried) what does that tell us about Go? That Go is bad at 
>> implementing bad/unnecessary patterns? I can live with that, definitely. 
>> The more important question though is - why even bother with that "pattern" 
>> in Go? 
>>
>> I think we need to look at the problems, and try to solve them in Go, not 
>> look at a problem, take an existing Java solution and then translate it to 
>> Go. 
>>
>> 19/20 "patterns" I've seen about Go are about concurrency and how to use 
>> goroutines, channels, select, etc. to solve common concurrency problems, *in 
>> Go*. They're not abstract UML diagrams about problems that may not even 
>> exist in Go or other languages, which is what the GoF book is to me - 
>> answers to questions that nobody is asking. 
>>
>>
>> On Wednesday, March 19, 2014 11:16:43 AM UTC-6, Robert Johnstone wrote:
>>>
>>> I think that you misunderstood my point.  My point was that since 
>>> languages differ in their level of abstraction, the level of abstraction 
>>> for the design patters will also vary.  Judging the quality of a language 
>>> based on the level of abstraction of its design patterns is just as odd an 
>>> idea as judging the language based its level of abstraction directly.  
>>>
>>> Beyond the above, it's not clear why patterns should be said to raise 
>>> the level of abstraction in one case and lower it in another.
>>>
>>>
>>> On Wednesday, 19 March 2014 11:25:56 UTC-4, Péter Szilágyi wrote:

 Hi,

   Take care not to mix up design patterns and levels of abstractions. 
 Although we could argue that building function calls on top of assembly is 
 a "pattern", it is one that raises the level of abstraction. The design 
 patterns of GoF on the 

[go-nuts] logout/end session

[Alex Kiprono]

Using token and the log in request struct i.e (userId, sessionId, 
timestamp) i generated a login/auth for log in process by creating and 
merging the request payload to generate the signature thus comparing for 
varification so the user is active in the system how will i end the session 
using sessionId from the logout request struct i.e (userId, sessionId, 
timestamp) ?

-- 
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/a4a1f47f-fb77-4b0c-b76e-03f7f2b2b675n%40googlegroups.com.

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

['Alex Efros' via golang-nuts]

Hi!

One more thing to keep in mind for the proposal: sometimes we need to merge two 
contexts.
https://github.com/golang/go/issues/36503
https://github.com/golang/go/issues/57928

-- 
WBR, Alex.

-- 
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/ZdcSCsSUeoSe47GW%40powerman.home.arpa.

[go-nuts] Re: What is the idiomatic way to create dynamic clients for Firestore in Go

[Alex Breadman]

There is no clear way to specify a database

On Thursday, December 28, 2023 at 4:51:02 AM UTC Alex Breadman wrote:

> I want multi-tenancy but there is no clear documentation.
>
> Is it supported yet in the firebase/firestore packages yet?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b9f09c68-1ebd-47b7-be83-1f179e59e397n%40googlegroups.com.

[go-nuts] What is the idiomatic way to create dynamic clients for Firestore in Go

[Alex Breadman]

I want multi-tenancy but there is no clear documentation.

Is it supported yet in the firebase/firestore packages yet?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ff599a86-4292-4f2f-a910-631e0e7ca7c1n%40googlegroups.com.

[go-nuts] Re: Any option to substitute plug-in package ?

[alex-coder]

Hi all.

Of course, in case if anyone is in interest to write  plugins for Go.
I found another option for writing plugins by use Lua.
I haven't touched the example yet, but I'm giving out the link.
https://github.com/yuin/gopher-lua/

Thank you.

четверг, 3 августа 2023 г. в 15:47:26 UTC+3, alex-coder: 

> Hi All,
> Currently I walk through the next book about native go development and 
> find out that it is possible to use the plugin, 
> but with limitations, so it became interesting what alternatives there are.
>
> Thank you.
>
> четверг, 3 августа 2023 г. в 12:09:21 UTC+3, Christoph Berger: 
>
>> WebAssembly comes to mind - see, for example, https://wazero.io/
>>
>> A plugin would then be a .wasm binary that can be compiled in any 
>> language that supports WebAssembly as target.
>>
>> Disclaimer: I have not yet tried this approach.
>>
>> On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:
>>
>> Hi All !
>> Plug-in package is very interesting, but in case the development under 
>> windows it does not work,
>> So, any hint to use some option instead will be highly appreciated.
>>
>> Thank you.
>>
>>

-- 
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/5bce322e-df4a-46c4-8a3d-35b025e73a44n%40googlegroups.com.

[go-nuts] Re: Best IDE for GO ?

[alex-coder]

Hi All !

Considering that IBM's punch cards were bearing at least twice, I would 
vote for them. :-)

Of cource I do agree with them who wrote that to feel comfortable "under 
fingers" is great !

So, the tasks to code - they are different. 
Sometimes it is possible to keep all the details regards to the task in a 
head or several.
Sometimes it is nesessary to write say a hard copy of them(details) on a 
paper with a different size.

But in case the task from the area of the "poorly formalized". You spend 
paper quickly. :-)

The Luke Crook points to:
https://en.wikipedia.org/wiki/Application_lifecycle_management

I will simplify the task somewhat and take from ALM for example even less 
than SDLC, namely:
requirements, design, implementation, testing, deployment.

1. Requirements must be described somewhere.
2. Design artifacts should reflect requirements.
3. Design decisions refer to objects and messages that
implemented in the form of classes and operations.
4. Each operation must pass at least one test.
All tests must be passed successfully.
5. The application is assembled and installed there and 
the tests are successfully passed again.

Question: is there any IDE or plugin which one support that kind of 
dependencies in a graphical mode ?

Thank you.

вторник, 22 августа 2023 г. в 18:22:52 UTC+3, Mike Schinkel: 

> On Saturday, August 19, 2023 at 5:27:34 AM UTC-4 alex-coder wrote:
>
> What I'm looking for is the ability to manage dependencies not only in 
> code,
> but entirely in a project from requirements to deployment.
>
>
> I assume you mean a lot more than just Go package dependencies, as `go 
> mod` handles those nicely.
>
> Can you elaborate on the specific dependencies you are trying to manage?  
> In specific, vs generalities.
>
> -Mike  
>

-- 
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/db0e5232-9044-4fc1-8b13-a954b4b46d3fn%40googlegroups.com.

[go-nuts] Best IDE for GO ?

[alex-coder]

Hi All !
Gophers, there is at least 10 years as GO on a market, Good job !

I found a list of the best IDE and Plugins there:
https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins

As I remember Java came around 1995 and within 3-4 years several companies 
developed really great IDEs successful or less to develop commercial 
project 
on Java. Here is a list of but I may miss somewhat, sorry, 
it was relatively a long time ago:

Forte for Java ( Praga, Czech republic)
VisualCafe (Symantec)
VisuailAge (IBM)
JBuilder (Borland)
Together Control Center (TogetherSoft, Germany)
Eclipse, and set of commercial IDE on a base on: RSA,RSD,WID and so on (IBM)

appear later:

VS Code ( Microsoft)
IDEA (JetBrain)

What I'm looking for is the ability to manage dependencies not only in 
code, 
but entirely in a project from requirements to deployment.
The feature should be inbuild into IDE or at least it would be possible 
to write plugin to implement it.

It is quite possible that I'm missing somewhat here.
Gophers, may be there is another place where I should look for IDE for GO ?

Thank you.

-- 
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/61fefbf1-bb6d-4d90-b77b-a94c70582826n%40googlegroups.com.

[go-nuts] Re: Any option to substitute plug-in package ?

[alex-coder]

Hi All,
Currently I walk through the next book about native go development and find 
out that it is possible to use the plugin, 
but with limitations, so it became interesting what alternatives there are.

Thank you.

четверг, 3 августа 2023 г. в 12:09:21 UTC+3, Christoph Berger: 

> WebAssembly comes to mind - see, for example, https://wazero.io/
>
> A plugin would then be a .wasm binary that can be compiled in any language 
> that supports WebAssembly as target.
>
> Disclaimer: I have not yet tried this approach.
>
> On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:
>
> Hi All !
> Plug-in package is very interesting, but in case the development under 
> windows it does not work,
> So, any hint to use some option instead will be highly appreciated.
>
> Thank you.
>
>

-- 
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/5ad7ddd5-c6de-486a-be89-4b6daf008729n%40googlegroups.com.

[go-nuts] Re: Any option to substitute plug-in package ?

[alex-coder]

Hi All,

so, binary code plugin as a RPC - frankly, never thought about :-)

What is written in go spec is a 
>> dynamically discovering and loading *shared lib*
as I see it but community developed much further

Thank you.

среда, 2 августа 2023 г. в 15:03:38 UTC+3, TheDiveO: 

> It really depends on what you want to achieve...
>
>1. dynamically discovering *out-of-process* RPC plugins ... 
>Hashicorp's might be the most famous one.
>2. dynamically discovering and loading *shared lib *plugins ... this 
>needs some plumbing above the pure stdlib plugin functionality. 
> Personally, 
>I find the shared libs to be finicky and haven't yet done a real project 
>that needed this variant (but I wrote a go-plugger 
><https://github.com/thediveo/go-plugger> module as an example).
>3. statically binary-builtin plugins: this actually is what I tend to 
>use in several of my own projects, where there is no need for dynamically 
>extending but instead to easily maintain and use a fixed set of "plugins" 
>and that set of plugins tends to slowly grow. The plugin mechanism might 
>help organizing, such as my own go-plugger 
><https://github.com/thediveo/go-plugger> supporting type-safe plugin 
>APIs and ordering and iterating plugins at runtime. For instance, I use 
>this mechanism to simplify adding new types to factories, or to "decorate" 
>containers with additional labels, such as in Docker compose contexts, or 
>k8s contexts, or ...
>
>
> On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:
>
>> Hi All !
>> Plug-in package is very interesting, but in case the development under 
>> windows it does not work,
>> So, any hint to use some option instead will be highly appreciated.
>>
>> Thank you.
>>
>

-- 
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/ee812683-6265-45d0-9de5-711859094a8bn%40googlegroups.com.

[go-nuts] Any option to substitute plug-in package ?

[alex-coder]

Hi All !
Plug-in package is very interesting, but in case the development under 
windows it does not work,
So, any hint to use some option instead will be highly appreciated.

Thank you.

-- 
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/ad934244-7fe9-41b2-ad2a-e48b4460a287n%40googlegroups.com.

[go-nuts] Re: How to run extra routine for http server properly ?

[alex-coder]

Yes, the question is set too broadly, it is necessary to specify the 
context, 
thank you.

четверг, 6 июля 2023 г. в 02:33:18 UTC+3, ben...@gmail.com: 

> For simple things, you can fire up a goroutine to do the "something else" 
> after the request finishes. For example, I've used this before to kick off 
> sending an email to a customer in the background (you'll want to 
> handle/report errors somehow though):
>
> package main
>
> import (
> "fmt"
> "log"
> "net/http"
> "time"
> )
>
> func main() {
> http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
> fmt.Fprint(w, "sending email in the background")
> go sendEmail()
> // response is sent, but sendEmail goroutine continues
> })
> log.Print("listening on http://localhost:8080;)
> http.ListenAndServe(":8080", nil)
> }
>
> func sendEmail() {
> log.Printf("would send an email here")
> time.Sleep(time.Second)
> log.Printf("done sending email")
> }
>
> On Thursday, July 6, 2023 at 2:03:47 AM UTC+12 alex-coder wrote:
>
> Hi All !
>
> So, http server looks like is a request / response processing.
> But in case it is nesessary to do something else after the response has 
> been sent to the client, how to do it properly ?
> Is there any example to read ?
>
> Thank you.
>
>
>

-- 
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/e8d9e2db-7c10-4d14-aee7-3a1625f1c22an%40googlegroups.com.

[go-nuts] How to run extra routine for http server properly ?

[alex-coder]

Hi All !

So, http server looks like is a request / response processing.
But in case it is nesessary to do something else after the response has 
been sent to the client, how to do it properly ?
Is there any example to read ?

Thank you.


-- 
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/a2bb1c86-76ac-45bc-a096-99cf54b41aadn%40googlegroups.com.

[go-nuts] Re: tool for ast graph visualization

[alex-coder]

Thank you so much !

четверг, 15 июня 2023 г. в 13:28:52 UTC+3, Vraj Reshamdalal: 

> Hi alex-coder,
> To get ast for GO code in a json format you can try a web tool: 
> https://astexplorer.net/
> or
> https://github.com/asty-org/asty
>
> Thanks,
> Vraj
>
> On Thursday, June 15, 2023 at 9:31:54 AM UTC+5:30 alex-coder wrote:
>
>> Xa, context is the king on a field :-)
>>
>> You gave a good sample, and I would like to get ast for GO code in a json 
>> format for further processing.
>>
>>
>> четверг, 15 июня 2023 г. в 01:45:20 UTC+3, ben...@gmail.com: 
>>
>>> Hi Alex, could you please give a bit more context about what language or 
>>> kind of AST you're referring to, and what you mean by visualize? As Vraj 
>>> mentioned, Graphviz is good for the general case. If you just want to 
>>> "visualize" Go AST in a text format, you can use go/ast.Print: 
>>> https://pkg.go.dev/go/a...@go1.20.5#Print 
>>> <https://pkg.go.dev/go/ast@go1.20.5#Print>
>>>
>>> On Wednesday, June 14, 2023 at 9:14:37 AM UTC+12 alex-coder wrote:
>>>
>>>> Hi All !
>>>>
>>>> Could you please advice me a tool to visualize an ast graph.
>>>>
>>>> Thank you.
>>>>
>>>

-- 
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/a84edcb7-e69c-4c7a-bf50-481d01c549e3n%40googlegroups.com.

[go-nuts] Re: tool for ast graph visualization

[alex-coder]

Xa, context is the king on a field :-)

You gave a good sample, and I would like to get ast for GO code in a json 
format for further processing.


четверг, 15 июня 2023 г. в 01:45:20 UTC+3, ben...@gmail.com: 

> Hi Alex, could you please give a bit more context about what language or 
> kind of AST you're referring to, and what you mean by visualize? As Vraj 
> mentioned, Graphviz is good for the general case. If you just want to 
> "visualize" Go AST in a text format, you can use go/ast.Print: 
> https://pkg.go.dev/go/a...@go1.20.5#Print 
> <https://pkg.go.dev/go/ast@go1.20.5#Print>
>
> On Wednesday, June 14, 2023 at 9:14:37 AM UTC+12 alex-coder wrote:
>
>> Hi All !
>>
>> Could you please advice me a tool to visualize an ast graph.
>>
>> Thank you.
>>
>

-- 
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/26ca3c04-89dc-4225-80a5-d5ad5bd8219an%40googlegroups.com.

[go-nuts] tool for ast graph visualization

[alex-coder]

Hi All !

Could you please advice me a tool to visualize an ast graph.

Thank you.

-- 
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/a74735a2-ab83-4f6a-8974-138fd5433dden%40googlegroups.com.

[go-nuts] Hosting to deploy && run exe ?

[alex-coder]

Hi All !

Could you please advise me the simple  hosting to deploy && run a small exe 
assembled from go.

Thank you !

-- 
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/8ab9fc50-3671-4eb6-a5e6-2feef19fdb84n%40googlegroups.com.

[go-nuts] ast package design / improvement discussion. where to read ?

[alex-coder]

Hi All !

Is there any discussion, which one possible to read, especially with 
rationale ?
Very interesting to read about walk.go file and callback of the  custom 
code.

Thank you.

-- 
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/d0354fde-e21c-4803-a882-02c11027325en%40googlegroups.com.

Re: [go-nuts] Help to choose the right type of the key for a map.

[alex-coder]

Ian and Andy,
looks like the to string conversion works and even does not look ugly. :-)

Thank you so much.

пятница, 17 марта 2023 г. в 15:01:31 UTC+3, alex-coder: 

> Andy, thank you.
>
> In case there would be a choice between ugly and achievable, I must take 
> the last one:-)
>
> Another thing I have found it that it is impossible to use type as a 
> parameter when you call to a function.
> How to pass type to function argument in Go - Stack Overflow 
> <https://stackoverflow.com/questions/51097211/how-to-pass-type-to-function-argument-in-go>
>
> Thank you.
>
> пятница, 17 марта 2023 г. в 02:12:22 UTC+3, Andy Balholm: 
>
>> I would guess that in the case of AST nodes, you're likely more 
>> interested in the *identity* of the nodes than their *values*. In that 
>> case, you should use the pointers to the nodes as your map keys.
>>
>> If the *values* truly are what you care about, use the go/format package 
>> to convert the node back to source code, and use the resulting string as 
>> your map key.
>>
>> On Thursday, March 16, 2023 at 3:24:49 PM UTC-7 alex-coder wrote:
>>
>>> >> Sure, convert to a string and use that as a map key.
>>> :-) no, no, no. it looks very very ugly.
>>>
>>> четверг, 16 марта 2023 г. в 00:26:35 UTC+3, Ian Lance Taylor: 
>>>
>>>> On Wed, Mar 15, 2023 at 2:16 PM alex-coder  wrote: 
>>>> > 
>>>> > Ian, thank you. 
>>>> > but may be the is any workaround ? 
>>>> > Use as a key not directly but like a derived from those 
>>>> interface/structure types ? 
>>>> > Of course I may declare key like string and use switch + .(type) to 
>>>> mimic it. 
>>>>
>>>> Sure, convert to a string and use that as a map key. 
>>>>
>>>> By the way, I should say that although you can't use `ast.Field` as a 
>>>> map key type, you can use `*ast.Field`. Of course then two different 
>>>> Field values that happen to look exactly the same will get different 
>>>> map entries. So it kind of depends on what you want to do. 
>>>>
>>>> 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/1a6849b1-35ae-4d3d-bdd9-28d5b342bcb9n%40googlegroups.com.

Re: [go-nuts] Help to choose the right type of the key for a map.

[alex-coder]

Andy, thank you.

In case there would be a choice between ugly and achievable, I must take 
the last one:-)

Another thing I have found it that it is impossible to use type as a 
parameter when you call to a function.
How to pass type to function argument in Go - Stack Overflow 
<https://stackoverflow.com/questions/51097211/how-to-pass-type-to-function-argument-in-go>

Thank you.

пятница, 17 марта 2023 г. в 02:12:22 UTC+3, Andy Balholm: 

> I would guess that in the case of AST nodes, you're likely more interested 
> in the *identity* of the nodes than their *values*. In that case, you 
> should use the pointers to the nodes as your map keys.
>
> If the *values* truly are what you care about, use the go/format package 
> to convert the node back to source code, and use the resulting string as 
> your map key.
>
> On Thursday, March 16, 2023 at 3:24:49 PM UTC-7 alex-coder wrote:
>
>> >> Sure, convert to a string and use that as a map key.
>> :-) no, no, no. it looks very very ugly.
>>
>> четверг, 16 марта 2023 г. в 00:26:35 UTC+3, Ian Lance Taylor: 
>>
>>> On Wed, Mar 15, 2023 at 2:16 PM alex-coder  wrote: 
>>> > 
>>> > Ian, thank you. 
>>> > but may be the is any workaround ? 
>>> > Use as a key not directly but like a derived from those 
>>> interface/structure types ? 
>>> > Of course I may declare key like string and use switch + .(type) to 
>>> mimic it. 
>>>
>>> Sure, convert to a string and use that as a map key. 
>>>
>>> By the way, I should say that although you can't use `ast.Field` as a 
>>> map key type, you can use `*ast.Field`. Of course then two different 
>>> Field values that happen to look exactly the same will get different 
>>> map entries. So it kind of depends on what you want to do. 
>>>
>>> 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/b6ea9156-f4fd-4cf9-9a51-5942f5cbe715n%40googlegroups.com.

Re: [go-nuts] Help to choose the right type of the key for a map.

[alex-coder]

>> Sure, convert to a string and use that as a map key.
:-) no, no, no. it looks very very ugly.

четверг, 16 марта 2023 г. в 00:26:35 UTC+3, Ian Lance Taylor: 

> On Wed, Mar 15, 2023 at 2:16 PM alex-coder  wrote:
> >
> > Ian, thank you.
> > but may be the is any workaround ?
> > Use as a key not directly but like a derived from those 
> interface/structure types ?
> > Of course I may declare key like string and use switch + .(type) to 
> mimic it.
>
> Sure, convert to a string and use that as a map key.
>
> By the way, I should say that although you can't use `ast.Field` as a
> map key type, you can use `*ast.Field`. Of course then two different
> Field values that happen to look exactly the same will get different
> map entries. So it kind of depends on what you want to do.
>
> 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/f0556fc4-885a-4f13-a29e-1894983e5962n%40googlegroups.com.

Re: [go-nuts] Help to choose the right type of the key for a map.

[alex-coder]

Ian, thank you.
but may be the is any workaround ?
Use as a key not directly but like a derived from those interface/structure 
types ?
Of course I may declare key like string and use switch + .(type) to mimic 
it.

So, a little bit more.
there is a go standard package named ast. the docs about it you may find 
there:
ast package - go/ast - Go Packages <https://pkg.go.dev/go/ast>

there is an arrea where are declared a lot of types:
type ArrayType struct {}
type AssignStmt struct {}
type BadDecl struct {}
and so on and ending with 
type ValueSpec struct {}
in fact there are a lot of them there.
What do I whant is to use those types of interfaces or structures as a key 
to access to a value in a map.  
So, the question is: what type of a key for a map I must use ?

Thank you. 

среда, 15 марта 2023 г. в 23:55:03 UTC+3, Ian Lance Taylor: 

> On Wed, Mar 15, 2023 at 9:17 AM alex-coder  wrote:
> >
> > There is a package named ast, inside there are a lot of structures like:
> > ast.Comment, ast.Field, ast.Node and so on.
> > And I whould like to use types of those structure as a keys.
> > So, I could not figure out what type of the key I should use
> > in order to store in a map something under the key ?
>
> I don't really understand the question. But I do know that most of
> the types in the go/ast package can't be used as map keys, because
> they can't be compared for equality, because they have fields of slice
> type. You can't use a slice, or a struct with a field of slice type,
> as a map key.
>
> 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/dfc41f67-5d71-4f2a-a0bf-569c5a582aedn%40googlegroups.com.

[go-nuts] Re: Help to choose the right type of the key for a map.

[alex-coder]

the ast package it is possible to find there:
ast package - go/ast - Go Packages <https://pkg.go.dev/go/ast#pkg-types>

thank you.

среда, 15 марта 2023 г. в 19:16:59 UTC+3, alex-coder: 

> Hi All !
>
> There is a package named ast, inside there are a lot of structures like:
> ast.Comment, ast.Field, ast.Node and so on.
> And I whould like to use types of those structure as a keys.
> So, I could not figure out what type of the key I should use
> in order to store in a map something under the key ? 
>
> I'm in dubt here. Help !
>
> Thank you.
>

-- 
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/326c7d3d-8e89-4a57-812f-41145d4190afn%40googlegroups.com.

[go-nuts] Help to choose the right type of the key for a map.

[alex-coder]

Hi All !

There is a package named ast, inside there are a lot of structures like:
ast.Comment, ast.Field, ast.Node and so on.
And I whould like to use types of those structure as a keys.
So, I could not figure out what type of the key I should use
in order to store in a map something under the key ? 

I'm in dubt here. Help !

Thank you.

-- 
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/03797dfe-f742-4861-b979-dfce710db3a8n%40googlegroups.com.

Re: [go-nuts] How to encode/decode string to binary in golang

[Alex Howarth]

You might be looking for strconv.ParseUint()
https://pkg.go.dev/strconv#ParseUint

https://go.dev/play/p/qAO9LfLD41D

On Mon, 13 Mar 2023 at 07:24, Van Fury  wrote:

>
> Sorry I did not frame my question properly but what I would like to do is
> to
> encode concatenated s1 and s2 into raw binary and then decode the raw
> binary
> back to s1 and s2.
>
>
> On Friday, March 10, 2023 at 11:36:09 PM UTC+2 Alex Howarth wrote:
>
>> If s1 and s2 are a fixed length then you can just slice up the decoded
>> string based on the lengths. If they are of a variable length, you'll need
>> a separator in the input string to later split on when decoded (s3 := s1 +
>> ":" + s2 etc)?
>>
>> On Fri, 10 Mar 2023 at 10:33, Van Fury  wrote:
>>
>>> Hi,
>>>
>>> I have two hexadecimal string values and would like to concatenate the
>>> two strings and
>>>
>>>1. encode the result to binary
>>>2. decode the resulting binary back to hexadecimal string
>>>
>>> I did the following but I was finding it difficult to decode the result
>>> back. I ignore error check in this case.
>>>
>>> What i did so far:
>>>
>>> s1 := "1d28ed66824aa2593e1f2a4cf740343f"
>>>
>>> s2 := "dee2bd5dde763885944bc9d65419"
>>>
>>> s3 := s1 + s2
>>>
>>> s1s2Byte, _ := hex.DecodeString(s3)
>>>
>>> randAutnBin := fmt.Sprintf("%b", s1s2Byte)
>>>
>>> result:
>>>
>>> [11101 101000 11101101 1100110 1010 1001010 10100010 1011001 10
>>> 1 101010 1001100 0111 100 110100 11 1100 11100010
>>> 1001 1011101 1100 1110110 111000 1101 10010100 1001011 11001001
>>> 11010110 1010100 11001]
>>>
>>> I would like to decode the binary result back the hexadecimal string to
>>> get s1 and s2.
>>>
>>> Any help?
>>>
>>> Van
>>>
>>> --
>>>
>> 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
>>> https://groups.google.com/d/msgid/golang-nuts/ad3a981b-cf22-47cd-9fe6-8db83a097b42n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/ad3a981b-cf22-47cd-9fe6-8db83a097b42n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> 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/1f66ccdc-6c58-48f0-9017-9614220f88d9n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/1f66ccdc-6c58-48f0-9017-9614220f88d9n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAB-c0Pd6paTbb%2BOFXGFXfDPGdBXaeoWXUex73Q4GWn__36UVGw%40mail.gmail.com.

Re: [go-nuts] How to encode/decode string to binary in golang

[Alex Howarth]

If s1 and s2 are a fixed length then you can just slice up the decoded
string based on the lengths. If they are of a variable length, you'll need
a separator in the input string to later split on when decoded (s3 := s1 +
":" + s2 etc)?

On Fri, 10 Mar 2023 at 10:33, Van Fury  wrote:

> Hi,
>
> I have two hexadecimal string values and would like to concatenate the two
> strings and
>
>1. encode the result to binary
>2. decode the resulting binary back to hexadecimal string
>
> I did the following but I was finding it difficult to decode the result
> back. I ignore error check in this case.
>
> What i did so far:
>
> s1 := "1d28ed66824aa2593e1f2a4cf740343f"
>
> s2 := "dee2bd5dde763885944bc9d65419"
>
> s3 := s1 + s2
>
> s1s2Byte, _ := hex.DecodeString(s3)
>
> randAutnBin := fmt.Sprintf("%b", s1s2Byte)
>
> result:
>
> [11101 101000 11101101 1100110 1010 1001010 10100010 1011001 10
> 1 101010 1001100 0111 100 110100 11 1100 11100010
> 1001 1011101 1100 1110110 111000 1101 10010100 1001011 11001001
> 11010110 1010100 11001]
>
> I would like to decode the binary result back the hexadecimal string to
> get s1 and s2.
>
> Any help?
>
> Van
>
> --
> 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/ad3a981b-cf22-47cd-9fe6-8db83a097b42n%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/CAB-c0PcY4Gc2FQGqxjwA7tKYYACxio6KXFpyGkSMOHLmfaX7GQ%40mail.gmail.com.

[go-nuts] Re: etcd, how to stop it ?

[alex-coder]

Brian, I can't thank you enough !
Sorry, button "Community" ofcourse.

понедельник, 16 января 2023 г. в 11:41:51 UTC+3, Brian Candler: 

> The homepage for etcd is here: https://etcd.io/  and there is a button 
> labelled "Community".
>
> You may also find this page useful: 
> http://www.catb.org/~esr/faqs/smart-questions.html#intro
>
> On Sunday, 15 January 2023 at 18:30:09 UTC alex-coder wrote:
>
>> Hi All !
>>
>> I do understand that my question is not quite in the right arrea,
>> but frankly, I'm totally lost.
>> I'm not able to find the answer for the looks like very simple question.
>> How to run - yes there is a sample, but how to stop it ?
>>
>> Thank you.
>>
>

-- 
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/d59c05df-4c98-472d-83ae-9fd47020f52dn%40googlegroups.com.

[go-nuts] etcd, how to stop it ?

[alex-coder]

Hi All !

I do understand that my question is not quite in the right arrea,
but frankly, I'm totally lost.
I'm not able to find the answer for the looks like very simple question.
How to run - yes there is a sample, but how to stop it ?

Thank you.

-- 
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/74417268-f3a1-4951-a476-d2e7f335fe35n%40googlegroups.com.

Re: [go-nuts] Re: Design patterns. builder ?

[alex-coder]

Hi All !

In case some one is in interest of the builder patterm industrial 
implementation.
So, I have found that there are a very intresting use the package  named 
https://github.com/spf13/cobra.
The package should be considered In context of the builder pattern 
implementation for realizaton of the template pattern to implement 
command/fasade pattern.
And to say everything above a little bit simpler: package is used to build 
CLI.
Sorry, English is not native for me. :-)

Thank you.

суббота, 3 апреля 2021 г. в 14:13:39 UTC+3, alex-coder: 

> Hi, 
> thank you for  everyone!
>
> The main point here is: "generally isn't needed", but sometimes structure 
> does not come described properly in some kind of string representation. :-)
> the pair Func / funchandler - just excellent ! 
> But what about other GO-4 patterns, I mean "isn't needed in go" ?
> Where take a look at ?
>
> Thank you.
>
> On Thursday, April 1, 2021 at 4:29:14 PM UTC+3 ren...@ix.netcom.com wrote:
>
>> The Go protobufs impl uses the builder pattern. 
>>
>> On Apr 1, 2021, at 2:21 AM, Brian Candler  wrote:
>>
>> The builder pattern generally isn't needed in go, because go has 
>> flexible struct literals where you can omit any members you don't want. 
>>
>>
>> You can implement it if you like, but it just adds a layer of boilerplate:
>> https://gist.github.com/vaskoz/10073335
>>
>> Some people are drawn to functional options instead:
>> https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis
>>
>> https://www.calhoun.io/using-functional-options-instead-of-method-chaining-in-go/
>>
>> But if you look at the standard library as a source of inspiration and 
>> good practice, complex configuration is typically done via structs.  See 
>> for example http.Server <https://golang.org/pkg/net/http/#Server>
>>
>> -- 
>> 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 
>> https://groups.google.com/d/msgid/golang-nuts/39e38cd7-93ee-4084-89e4-a22bcd1baaa6n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/39e38cd7-93ee-4084-89e4-a22bcd1baaa6n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>>

-- 
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/88d9f62e-4a2f-4623-8f50-0fdbb33f58f9n%40googlegroups.com.

[go-nuts] Generics in gollvm

[Alex Markin]

Hello.

What is the status of generic programming (I mean the generics

added in go-1.18) in the gollvm project? Are there any plans to support it
or maybe someone already working on it?

-- 
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/CAAgqtbU47hv%3DD-xSr6fbsVxDPw75VvYVZMZN42E-9VXNiUJd2A%40mail.gmail.com.

Re: [go-nuts] what is the origin of Go's reference time system?

[Alex Besogonov]

It’s possible to use a different method name (“FormatNew”?) to avoid back 
compat issues. But yeah, it would be a bit ugly.

It might make sense to revisit this if Go ever grows i18n for datetimes.

> On Oct 26, 2022, at 23:44, Rob Pike  wrote:
> 
> Not without breaking compatibility.
> 
> -rob
> 
> 
> On Thu, Oct 27, 2022 at 5:15 PM Alex Besogonov  <mailto:alex.besogo...@gmail.com>> wrote:
>> Can we perhaps get a bit more unambiguous reference date for it?
>> 
>> On Wednesday, October 26, 2022 at 1:06:36 PM UTC-7 Rob 'Commander' Pike 
>> wrote:
>>> I believe it's unique. I thought of it one day while walking home. It is 
>>> inspired by the way Cobol picture clauses represent number formats. (That 
>>> said, I've never programmed in Cobol.)
>>> 
>>> -rob
>>> 
>>> 
>>> On Thu, Oct 27, 2022 at 4:51 AM Ayan George > wrote:
>>>> 
>>>> I'm really impressed by the simplicity of Go's time formatting and parsing 
>>>> mechanisms -- particularly when compared with strftim().
>>>> 
>>>> Does anyone know the origin or history of it?  Is there a precedent for 
>>>> using reference layouts that include string like 2006, January, etc.?
>>>> 
>>>> Do other languages provide something similar or is this completely unique 
>>>> to Go?
>>>> 
>>>> Can someone point me to or describe the history of Go's time formatting 
>>>> method?
>>>> 
>>>> -ayan
>>>> 
>>> 
>>>> -- 
>>>> 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 
>>>> https://groups.google.com/d/msgid/golang-nuts/baa45515-cde6-4c7c-a34c-54ddf7da807en%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/baa45515-cde6-4c7c-a34c-54ddf7da807en%40googlegroups.com?utm_medium=email_source=footer>.
>> 
>> 
>> -- 
>> 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 
>> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/c8f3bc05-3b30-45ad-9e7a-4c12481494d8n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/c8f3bc05-3b30-45ad-9e7a-4c12481494d8n%40googlegroups.com?utm_medium=email_source=footer>.

-- 
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/FD2CADB2-B8FF-4C76-A34F-0C71E2D51402%40gmail.com.

Re: [go-nuts] what is the origin of Go's reference time system?

[Alex Besogonov]

Can we perhaps get a bit more unambiguous reference date for it?

On Wednesday, October 26, 2022 at 1:06:36 PM UTC-7 Rob 'Commander' Pike 
wrote:

> I believe it's unique. I thought of it one day while walking home. It is 
> inspired by the way Cobol picture clauses represent number formats. (That 
> said, I've never programmed in Cobol.)
>
> -rob
>
>
> On Thu, Oct 27, 2022 at 4:51 AM Ayan George  wrote:
>
>>
>> I'm really impressed by the simplicity of Go's time formatting and 
>> parsing mechanisms -- particularly when compared with strftim().
>>
>> Does anyone know the origin or history of it?  Is there a precedent for 
>> using reference layouts that include string like 2006, January, etc.?
>>
>> Do other languages provide something similar or is this completely unique 
>> to Go?
>>
>> Can someone point me to or describe the history of Go's time formatting 
>> method?
>>
>> -ayan
>>
>> -- 
>> 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 
>> https://groups.google.com/d/msgid/golang-nuts/baa45515-cde6-4c7c-a34c-54ddf7da807en%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/c8f3bc05-3b30-45ad-9e7a-4c12481494d8n%40googlegroups.com.

Re: [go-nuts] gollvm build fails

[Alex Markin]

Thank you for your advice!

I compared the good and the bad build log and found out the lack of rule
zgoarchat all. So I mentioned the difference in makefiles and it turned out
that I used different revisions of gollvm. It is interesting that with gcc
this problem did not appear (but in both gcc and llvm cases I got the
linkage problem described below).

After that I got the next problem: cmake failed to set the
SIZEOF_STRUCT_EPOLL_EVENT and STRUCT_EPOLL_EVENT_FD_OFFSET. I do not know
what to do with it. So I just hardcoded them in the
cmake/modules/AutoGenGo.cmake (values 12 and 4 respectively). After that,
the cmake worked fine.

Then the build failed with other problem:

/home/alex/test/gollvm/build-debug/./bin/llvm-goc -o /home/alex/test/gollvm
/build-de
bug/tools/gollvm/gotools/go go_.o -I /home/alex/test/gollvm
/build-debug/tools/gollvm/libgo -L /home/alex/test/gollvm/build-debug/tools/
gollvm/libgo /home/ale
x/test/gollvm/build-debug/tools/gollvm/libgo/libgotool.a
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold:
error: cannot open crtn.o: Нет такого файла или каталога
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold:
warning: skipping incompatible /usr/lib/libm.so while searching for m
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold:
error: cannot find -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold:
warning: skipping incompatible /usr/lib/libc.so while searching for c
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold:
error: cannot find -lc
/usr/lib64/crt1.o:function _start: error: undefined reference to
'__libc_start_main'
/home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/runtime/go-main.c:59:
error: undefined reference to 'abort'
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libgcc.a(generic-morestack.o):function
__morestack_fail: error: undefined reference to 'writev'
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libgcc.a(generic-morestack.o):function
__morestack_fail: error: undefined reference to 'abort'
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libgcc.a(generic-morestack.o):function
__morestack_release_segments: error: undefined reference to 'syscall'
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libgcc.a(generic-morestack.o):function
__morestack_release_segments: error: undefined reference to 'free'
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libgcc.a(generic-morestack.o):function
__morestack_release_segments: error: undefined reference to 'free'
...

That was even more weird. And also that was almost like the issue 26405 (
https://github.com/golang/go/issues/26405). I do not know the good way to
solve it so I just hardcoded in the file driver/GnuTools.cpp the following
things:

cmdArgs
.push_back(args.MakeArgString(toolchain().getFilePath(/usr/lib64/crt1.o)));
cmdArgs.push_back(args.MakeArgString("/usr/lib64/crti.o"));
cmdArgs.push_back(args.MakeArgString("-L/usr/lib64/"));
cmdArgs.push_back(args.MakeArgString("/usr/lib64/crtn.o"));

After that my build finished successfully.

Again, thank you for your help.

вт, 25 окт. 2022 г. в 17:04, Than McIntosh :

> Weird. I am scratching my head.
>
> At this point if I was debugging it myself on your system I would rerun
> cmake passing it the "--trace-expand" flag (which will generate giant
> volumes of output), then look in the trace to see what is happening when
> the cmake rules in question fire. You should see something like
>
> ...
> /mybuildarea/llvm-project/llvm/tools/gollvm/libgo/CMakeLists.txt(232):
>  set(zgoarchdotgo ${libgo_binroot}/zgoarch.go )
> /mybuildarea/llvm-project/llvm/tools/gollvm/libgo/CMakeLists.txt(233):
>  set(zgoarchtmp ${libgo_binroot}/zgoarch.go.tmp )
> /mybuildarea/llvm-project/llvm/tools/gollvm/libgo/CMakeLists.txt(234):
>  mkzgoarch(${goarch} ${zgoarchtmp} ${libgo_scriptroot} )
> /mybuildarea/llvm-project/llvm/tools/gollvm/cmake/modules/AutoGenGo.cmake(75):
>  file(REMOVE ${outfile} )
> /mybuildarea/llvm-project/llvm/tools/gollvm/cmake/modules/AutoGenGo.cmake(76):
>  file(WRITE ${outfile} package goarch\n\n )
> /mybuildarea/llvm-project/llvm/tools/gollvm/cmake/modules/AutoGenGo.cmake(78):
>  file(APPEND ${outfile} const GOARCH = \"${goarch}\"\n\n )
> ...
>
> If these rules are not firing, then hopefully the trace output will have
> some suggestion as to why.
>
> Thanks, Than
>
>
>
>
> On Tue, Oct 25, 2022 at 3:29 AM Alex Markin  wrote:
>
>> > Do you have tools/gollvm/libgo/zgoarch.go.tmp in your build area? What
>> sort of content is in that file?
>>
>> No
>>
>> $ ninja -v -d explain tools/gollvm/libgo/zgoarch.go
>> ninja: error: unknown target 'tools/gollvm/libgo/zgoarch.go'
>>
>> $ gcc -dumpmachine
>> x86_64-pc-linux-gnu
>>
&

Re: [go-nuts] gollvm build fails

[Alex Markin]

> Do you have tools/gollvm/libgo/zgoarch.go.tmp in your build area? What
sort of content is in that file?

No

$ ninja -v -d explain tools/gollvm/libgo/zgoarch.go
ninja: error: unknown target 'tools/gollvm/libgo/zgoarch.go'

$ gcc -dumpmachine
x86_64-pc-linux-gnu

$ clang -dumpmachine
x86_64-pc-linux-gnu

I tried manually setting up different target triples (for example the same
as on a working machine) but
it did not help.


чт, 20 окт. 2022 г. в 15:48, Than McIntosh :

> >There is no zgoarch.go file in the build area. It seems that it was not
> created by the build system.
>
> I've oversimplified things a bit -- what cmake does is write
> out tools/gollvm/libgo/zgoarch.go.tmp, and then add a build rule
> for zgoarch.go that copies the *.tmp file to the *.go file if they are
> different.
>
> Do you have tools/gollvm/libgo/zgoarch.go.tmp in your build area? What
> sort of content is in that file? What happens when you do
>
>$ ninja -v -d explain tools/gollvm/libgo/zgoarch.go
>
> You should see something like
>
> ninja explain: output tools/gollvm/libgo/zgoarch.go doesn't exist
> [1/1] cd /x/llvm-project/build-relwithdbg/tools/gollvm/libgo &&
> /usr/bin/cmake -E copy_if_different
> /x/llvm-project/build-relwithdbg/tools/gollvm/libgo/zgoarch.go.tmp
> /x/llvm-project/build-relwithdbg/tools/gollvm/libgo/zgoarch.go
>
> Thanks, Than
>
>
>
>
> On Wed, Oct 19, 2022 at 5:42 PM Alex Markin  wrote:
>
>> There is no zgoarch.go file in the build area. It seems that it was not
>> created by the build system. I watched the logs and there were no lines to
>> create it. In the directory libgo I have only the following *go files:
>>
>> epoll.go  goroot.go  libcalls.go  syscall_arch.go  tmp-libcalls.go
>>
>> So I can't understand why the rule for zgoarch is not called. Probably
>> some env variable?
>>
>> ср, 19 окт. 2022 г. в 16:47, Than McIntosh :
>>
>>> Hi,
>>>
>>> Those constants are supposed to be defined in the generated file
>>> /tools/gollvm/libgo/zgoarch.go, which is written as out part of
>>> the gollvm build process, e.g. here
>>>
>>>
>>> https://go.googlesource.com/gollvm/+/253c122ed62d5e9a32a9806e83c47a389a6435bf/cmake/modules/AutoGenGo.cmake#63
>>>
>>> What does the zgoarch.go file look like in your build area?
>>>
>>> Thanks, Than
>>>
>>>
>>> On Wed, Oct 19, 2022 at 8:20 AM Alex Markin  wrote:
>>>
>>>> Hello.
>>>>
>>>> I'm trying to build gollvm on my gentoo system and get the following
>>>> error:
>>>>
>>>> FAILED: tools/gollvm/libgo/internal/.pic/goarch.o
>>>> /home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o
>>>>
>>>> cd /home/alex/test/gollvm/build-debug/tools/gollvm/libgo &&
>>>> /usr/bin/cmake -E make_directory ./internal/.pic &&
>>>> /home/alex/test/gollvm/build-debug/./bin/llvm
>>>> -goc -c -o
>>>> /home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o
>>>> -fPIC -fgo-pkgpath=internal/goarch -I . /home/alex/test/gollvm/llvm-p
>>>> roject/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go
>>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:15:35:
>>>> error: reference to undefined name '_ArchFamily'
>>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:18:19:
>>>> error: reference to undefined name '_BigEndian'
>>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:21:29:
>>>> error: reference to undefined name '_DefaultPhysPa
>>>> geSize'
>>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:25:19:
>>>> error: reference to undefined name '_PCQuantum'
>>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:28:20:
>>>> error: reference to undefined name '_Int64Align'
>>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:35:22:
>>>> error: reference to undefined name '_MinFrameSize'
>>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:39:20:
>>>> error: reference to undefined name '_StackAlign'
>>>>
>>>> What can be the reason of such error? On another ubuntu system
>>>> everything 

Re: [go-nuts] gollvm build fails

[Alex Markin]

There is no zgoarch.go file in the build area. It seems that it was not
created by the build system. I watched the logs and there were no lines to
create it. In the directory libgo I have only the following *go files:

epoll.go  goroot.go  libcalls.go  syscall_arch.go  tmp-libcalls.go

So I can't understand why the rule for zgoarch is not called. Probably some
env variable?

ср, 19 окт. 2022 г. в 16:47, Than McIntosh :

> Hi,
>
> Those constants are supposed to be defined in the generated file
> /tools/gollvm/libgo/zgoarch.go, which is written as out part of
> the gollvm build process, e.g. here
>
>
> https://go.googlesource.com/gollvm/+/253c122ed62d5e9a32a9806e83c47a389a6435bf/cmake/modules/AutoGenGo.cmake#63
>
> What does the zgoarch.go file look like in your build area?
>
> Thanks, Than
>
>
> On Wed, Oct 19, 2022 at 8:20 AM Alex Markin  wrote:
>
>> Hello.
>>
>> I'm trying to build gollvm on my gentoo system and get the following
>> error:
>>
>> FAILED: tools/gollvm/libgo/internal/.pic/goarch.o
>> /home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o
>>
>> cd /home/alex/test/gollvm/build-debug/tools/gollvm/libgo &&
>> /usr/bin/cmake -E make_directory ./internal/.pic &&
>> /home/alex/test/gollvm/build-debug/./bin/llvm
>> -goc -c -o
>> /home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o
>> -fPIC -fgo-pkgpath=internal/goarch -I . /home/alex/test/gollvm/llvm-p
>> roject/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go
>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:15:35:
>> error: reference to undefined name '_ArchFamily'
>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:18:19:
>> error: reference to undefined name '_BigEndian'
>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:21:29:
>> error: reference to undefined name '_DefaultPhysPa
>> geSize'
>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:25:19:
>> error: reference to undefined name '_PCQuantum'
>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:28:20:
>> error: reference to undefined name '_Int64Align'
>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:35:22:
>> error: reference to undefined name '_MinFrameSize'
>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:39:20:
>> error: reference to undefined name '_StackAlign'
>>
>> What can be the reason of such error? On another ubuntu system everything
>> goes correctly.
>>
>> The cmake line:
>>
>> cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER=clang++
>> -DCMAKE_C_COMPILER=clang -G Ninja ../llvm-project/llvm
>>
>> --
>> 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/9ad0d8dc-d118-45d2-984e-9cdf36ab4f28n%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/9ad0d8dc-d118-45d2-984e-9cdf36ab4f28n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAAgqtbV3Vd4jpYC13uQkMDv%2BZpDm%3DerQ%2BN9TBpUuFBmM2L8jfw%40mail.gmail.com.

[go-nuts] gollvm build fails

[Alex Markin]

Hello.

I'm trying to build gollvm on my gentoo system and get the following error:

FAILED: tools/gollvm/libgo/internal/.pic/goarch.o 
/home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o 
 
cd /home/alex/test/gollvm/build-debug/tools/gollvm/libgo && /usr/bin/cmake 
-E make_directory ./internal/.pic && 
/home/alex/test/gollvm/build-debug/./bin/llvm
-goc -c -o 
/home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o 
-fPIC -fgo-pkgpath=internal/goarch -I . /home/alex/test/gollvm/llvm-p
roject/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go
/home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:15:35:
 
error: reference to undefined name '_ArchFamily'
/home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:18:19:
 
error: reference to undefined name '_BigEndian'
/home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:21:29:
 
error: reference to undefined name '_DefaultPhysPa
geSize'
/home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:25:19:
 
error: reference to undefined name '_PCQuantum'
/home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:28:20:
 
error: reference to undefined name '_Int64Align'
/home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:35:22:
 
error: reference to undefined name '_MinFrameSize'
/home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:39:20:
 
error: reference to undefined name '_StackAlign'

What can be the reason of such error? On another ubuntu system everything 
goes correctly.

The cmake line:

cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER=clang++ 
-DCMAKE_C_COMPILER=clang -G Ninja ../llvm-project/llvm

-- 
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/9ad0d8dc-d118-45d2-984e-9cdf36ab4f28n%40googlegroups.com.

Re: [go-nuts] How to call sort.Search in a loop

[K. Alex Mills]

Ah, my last post had a small mistake. A small modification to upper should
be all you need. The function should use >= instead of >. See below.

upper := sort.Search(len(haystack), func(i int) bool {
return haystack[i].name >= needle.name
})

On Tue, Oct 11, 2022, 7:38 AM K. Alex Mills  wrote:

> sort.Search runs binary search. It's only guaranteed to work when you
> provide it with a function which is monotonic -- true at index i implies
> true at all indices greater than i.
>
> Your loop style search does not provide a monotonic function, whereas your
> "upper" function is monotonic. However, since "lower" is also not monotonic
> I'd question whether the first approach would continue to work on larger
> arrays. When testing binary search algorithms, it's important to use arrays
> of many varying sizes, since the edge cases often don't appear on smaller
> length lists.
>
> In any case, on a sorted list, "upper" should be the only function you
> need to determine whether the needle can be found in the list. sort.Search
> guarantees that the index it returns is the first index where the monotonic
> function changes its value. If the needle you're looking for is in the
> haystack, the value at that index will be the needle itself.
>
> On Tue, Oct 11, 2022, 7:22 AM 'ljh' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> Hi community,
>>
>> I used sort.Search on a sorted slice in below code started at Line 36,
>> and it worked.
>>
>> I also tried to call sort.Search in a loop, started at Line 53. It does
>> not seem to work. How can I correct the loop version?
>>
>> Thanks
>>
>> ---
>>
>> package main
>>
>> import (
>> "log"
>> "sort"
>> )
>>
>> type T struct {
>> name string
>> }
>>
>> func main() {
>> log.SetFlags(log.LstdFlags | log.Llongfile)
>>
>> haystack := []T{
>> // {name: "apple",  },
>> {name: "compote", }, //dup
>> {name: "orange", },
>> {name: "compote", }, //dup
>> }
>>
>> sort.Slice(haystack, func(i, j int) bool {
>> if haystack[i].name < haystack[j].name {
>> return true
>> } else {
>> return false
>> }
>> })
>>
>> for _, t := range haystack {
>> log.Println("sorted", t)
>> }
>>
>> needle := T{name: "compote"}
>>
>> // Style 1: ok, lower upper bounds style // Line 36
>> /*
>> lower := sort.Search(len(haystack), func(i int) bool {
>> return haystack[i].name == needle.name
>> })
>>
>> upper := sort.Search(len(haystack), func(i int) bool {
>> return haystack[i].name > needle.name
>> })
>>
>> if lower != len(haystack) {
>> for i := lower; i != upper; i++ {
>> log.Println("found", i, haystack[i])
>> }
>> }
>> */
>>
>> // Style 2: error, loop style // Line 53
>> for index := 0; index < len(haystack); index++ {
>> ret := sort.Search(len(haystack[index:]), func(i int) bool {
>> return haystack[index:][i].name == needle.name })
>>
>> log.Println(index, ret)
>>
>> if ret < len(haystack) {
>> index += ret
>> log.Println("found", index, haystack[index])
>> }
>> }
>> }
>>
>> --
>> 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/tencent_659665C8263F2DF81643C2B86412244F3105%40qq.com
>> <https://groups.google.com/d/msgid/golang-nuts/tencent_659665C8263F2DF81643C2B86412244F3105%40qq.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CALJzkY9O5F_trJAhp8i8jSdVOb7wf%2Brz06JEHu8GXoQuVPQkVQ%40mail.gmail.com.

Re: [go-nuts] How to call sort.Search in a loop

[K. Alex Mills]

sort.Search runs binary search. It's only guaranteed to work when you
provide it with a function which is monotonic -- true at index i implies
true at all indices greater than i.

Your loop style search does not provide a monotonic function, whereas your
"upper" function is monotonic. However, since "lower" is also not monotonic
I'd question whether the first approach would continue to work on larger
arrays. When testing binary search algorithms, it's important to use arrays
of many varying sizes, since the edge cases often don't appear on smaller
length lists.

In any case, on a sorted list, "upper" should be the only function you need
to determine whether the needle can be found in the list. sort.Search
guarantees that the index it returns is the first index where the monotonic
function changes its value. If the needle you're looking for is in the
haystack, the value at that index will be the needle itself.

On Tue, Oct 11, 2022, 7:22 AM 'ljh' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hi community,
>
> I used sort.Search on a sorted slice in below code started at Line 36, and
> it worked.
>
> I also tried to call sort.Search in a loop, started at Line 53. It does
> not seem to work. How can I correct the loop version?
>
> Thanks
>
> ---
>
> package main
>
> import (
> "log"
> "sort"
> )
>
> type T struct {
> name string
> }
>
> func main() {
> log.SetFlags(log.LstdFlags | log.Llongfile)
>
> haystack := []T{
> // {name: "apple",  },
> {name: "compote", }, //dup
> {name: "orange", },
> {name: "compote", }, //dup
> }
>
> sort.Slice(haystack, func(i, j int) bool {
> if haystack[i].name < haystack[j].name {
> return true
> } else {
> return false
> }
> })
>
> for _, t := range haystack {
> log.Println("sorted", t)
> }
>
> needle := T{name: "compote"}
>
> // Style 1: ok, lower upper bounds style // Line 36
> /*
> lower := sort.Search(len(haystack), func(i int) bool {
> return haystack[i].name == needle.name
> })
>
> upper := sort.Search(len(haystack), func(i int) bool {
> return haystack[i].name > needle.name
> })
>
> if lower != len(haystack) {
> for i := lower; i != upper; i++ {
> log.Println("found", i, haystack[i])
> }
> }
> */
>
> // Style 2: error, loop style // Line 53
> for index := 0; index < len(haystack); index++ {
> ret := sort.Search(len(haystack[index:]), func(i int) bool {
> return haystack[index:][i].name == needle.name })
>
> log.Println(index, ret)
>
> if ret < len(haystack) {
> index += ret
> log.Println("found", index, haystack[index])
> }
> }
> }
>
> --
> 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/tencent_659665C8263F2DF81643C2B86412244F3105%40qq.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/CALJzkY_JSC9pGUTuaXdzf1Wayq8%2BQUjpq2dT%3DqsQKhCcy1Sbgg%40mail.gmail.com.

[go-nuts] Re: go program import ?

[alex-coder]

Hi,

I have found data necessary to me there:
go/build.Default.GOROOT in case someone is in interest.

Thank you.

четверг, 29 сентября 2022 г. в 20:59:50 UTC+3, alex-coder: 

> Hi All,
>
> How I could detect programmatically that import in a go code
> belongs to a go distribution ?
>
> thank you very much for the answer.
>

-- 
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/2cef1dbd-a226-43d1-8be3-b6b899e64881n%40googlegroups.com.

[go-nuts] go program import ?

[alex-coder]

Hi All,

How I could detect programmatically that import in a go code
belongs to a go distribution ?

thank you very much for the answer.

-- 
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/b4255c88-acda-41cd-8bf1-fcb08506f11dn%40googlegroups.com.

Re: [go-nuts] Is there a better way to write this?

[K. Alex Mills]

The only alternatives that I see would each introduce an extra call to Add,
like the below. I'm not sure if this is much less "clunky", but it at least
avoids the reassignment to s.

func collectStringsetMap(m map[string]*stringset.Set, key string, value
...string) *stringset.Set {
  if s, ok := m[key]; ok {
s.Add(value...)
return s
  }
  newset := stringset.New()
  m[key] = 
  newset.Add(value...)
  return 
}

> Why can't I just use &(stringset.New()) ?

I'm unsure, but it might have something to do with Go being explicit and
the language designers wanting to make the stack allocation and transfer to
the heap explicit... or it might make Go's escape analysis feasible.

That said, you wouldn't have to worry about it if the library authors chose
to return a pointer, but in that case the caller would be forced to accept
a heap allocation on every stringset.New(). Returning a value has its
merits here.

On Tue, Sep 13, 2022, 4:44 PM 'Aaron Spangler' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I seem to be regularly working with maps of stringsets and I have
> found myself writing the same pattern over and over and I ended up
> having my own utility function.  More importantly the syntax seems
> clunky when a key doesn't exist in the map.  Is there a better way (go
> idiomatically way) to write this?
>
> import  "google3/third_party/golang/stringset/stringset"
>
> var urlMap = make(map[string]*stringset.Set)
>
> func collectStringsetMap(m map[string]*stringset.Set, key string,
> value ...string) *stringset.Set {
>   s, ok := m[key]
>   if !ok {
> newset := stringset.New()  // Why can't I just use &(stringset.New()) ?
> s = 
> m[key] = s
>   }
>   s.Add(value...)
>   return s
> }
>
> If there is a way to clean up the code, let me know.
>
> Also why can map's just take a default function to construct items
> that are not yet present?
> Something like:
>
> var urlMap = make(map[string]*stringset.Set, ...func =
> defaultStringsetConstructor...)
>
> func defaultStringsetConstructor(key string) *stringset.Set {
>   n := stringset.New()
>   return 
> }
>
> Or perhaps some trickery in the map lookup?
>
>  s, ok := m[key, defaultStringsetConstructor]
>
> At the end of the day you want the map to save any new items that were
> not already in the map, but I don't see any less clunky ways of doing
> this.  (What am I missing?)
>
> --
> 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/CAHP%2Bjq5zX69g5S88_G03CZyHMoC_xGPXxqZfbc%3DKg0FRi8%3DMgQ%40mail.gmail.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/CALJzkY-EobrWZ2wTjDOv7eobD0zEGsagd0wGUpV_HDdqgOwvyg%40mail.gmail.com.

[go-nuts] Detachable context.Context?

[Alex Besogonov]

Hi!

Let me give you some context. context.Context in Go serves two main 
purposes:
1. Cancellation and timeout support.
2. A carrier of values, as a de-facto replacement for thread-local 
variables.

I have a problem with the first item. Cancellation and timeouts 
automatically propagate to child contexts, which is usually a good thing. 
However, sometimes it would be nice to be able to create child contexts 
that share only values but not the timeout/cancellation.

Typically it's needed if the code wants to start a background goroutine to 
do some work. E.g. in pseudocode:

func StartConnection(ctx context.Context, addr string) (err error) {
  conn, err = net.DialWithContext(ctx, addr)
  if err != nil { return err; }
  go heartbeatFunc(ctx, conn);
...
}

Right now it's not possible to do that cleanly. The only way is to create a 
brand new context and copy all the needed values. Which requires the code 
to know which values might be needed.

Is there an interest in proposal to add this functionality? It can look 
like another method: `context.Detached(ctx context.Context)` that simply 
does not add it to the parent cancellation tree.

-- 
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/26f54d88-e475-413e-84f0-9076f5aaba28n%40googlegroups.com.

[go-nuts] Re: Java to Go converter - 2

[alex-coder]

Hi, sorry for delay.
Despite my great interest in this task, I can not spend a lot of time on 
the project. But you're right, everything I've posted on go-nuts shows that 
conversion is very possible and in the same context that you're 
considering, if I understand you correctly of course . So far it looks like 
this:
syntactic analysis,
semantic analysis,
then there is code generation on Go from AST.
Regards,

четверг, 18 августа 2022 г. в 21:58:03 UTC+3, Oliveira Jose Carlos de - 
ICTS BSA: 

> Hi, I´m looking foward to find a Tool able to convert any Java Source code 
> Project to a GoLang Project. I know that are Programming languages created 
> for different propposal. Java is OOL and  goLang is different. So 
> convertion is possible, but I think is very complex.  For me is much more 
> easy look on Java Source code logic and write your own code in GoLang.  I 
> think
>
> I did it in the past, and writting code in a new language make de new code 
> more maintenable.
>
> Em domingo, 22 de maio de 2022 às 03:49:42 UTC-3, alex-coder escreveu:
>
>> So, channels.
>> Converter can now convert Java classes to Go channels where possible. The 
>> previous example contains a Drop class that matches the conversion 
>> criteria, as shown in the Go example code below. Accordingly, if the 
>> converter "does not find" a class suitable for conversion, Java 
>> multithreading will be converted to Go code without using the translation 
>> into channels.
>> *Java code:*
>> package com.builder.start.here;
>>
>> import java.util.Random;
>>
>> public class RunMe {
>> public static void main(String[] args) {
>> Drop drop = new Drop();
>> (new Thread(new Producer(drop))).start();
>> (new Thread(new Consumer(drop))).start();
>> }
>> }
>> class Drop {
>> // Message sent from producer
>> // to consumer.
>> private String message;
>> // True if consumer should wait
>> // for producer to send message,
>> // false if producer should wait for
>> // consumer to retrieve message.
>> private boolean empty = true;
>>
>> public synchronized String take() {
>> // Wait until message is
>> // available.
>> while (empty) {
>> try {
>> wait();
>> } catch (InterruptedException e) {}
>> }
>> // Toggle status.
>> empty = true;
>> // Notify producer that
>> // status has changed.
>> notifyAll();
>> return message;
>> }
>>
>> public synchronized void put(String message) {
>> // Wait until message has
>> // been retrieved.
>> while (!empty) {
>> try { 
>> wait();
>> } catch (InterruptedException e) {}
>> }
>> // Toggle status.
>> empty = false;
>> // Store message.
>> this.message = message;
>> // Notify consumer that status
>> // has changed.
>> notifyAll();
>> }
>> }
>> class Consumer implements Runnable {
>> private Drop drop;
>>
>> public Consumer(Drop drop) {
>> this.drop = drop;
>> }
>>
>> public void run() {
>> Random random = new Random();
>> for (
>>String message = drop.take(); 
>>! message.equals("DONE"); 
>>message = drop.take()) {
>> System.out.format(
>>"MESSAGE RECEIVED: %s%n", message);
>>  try {
>> Thread.sleep(random.nextInt(5000));
>>} catch (InterruptedException e) {}
>> }
>> }
>> }
>> class Producer implements Runnable {
>> private Drop drop;
>>
>> public Producer(Drop drop) {
>> this.drop = drop;
>> }
>>
>> public void run() {
>> String importantInfo[] = {
>> "Mares eat oats",
>> "Does eat oats",
>> "Little lambs eat ivy",
>> "A kid will eat ivy too"
>> };
>> Random random = new Random();
>>
>> for (int i = 0; i < importantInfo.length; i++) {
>> drop.put(importantInfo[i]);
>> try {
>> Thread.sleep(random.nextInt(5000));
>> } catch (InterruptedException e) {}
>>   

[go-nuts] github.com/splunk/pipelines hits v1.0.0

[K. Alex Mills]

Hi Gophers!

The API has solidified, so I've just released github.com/splunk/pipelines
at v1.0.0. This library provides a lightweight way to manage concurrency
separately from your business logic by breaking a concurrent task down into
stages in a pipeline, connected by nothing more than plain old channels.

*Features:*
* Pipeline stages based on common functional programming primitives.
* Integrated with termination signals from the context package.
* Scale out individual pipeline stages without disrupting business logic.
* Introduce queues by buffering channels mid-stream.
* Split and combine pipeline stages as pairs.
* Handle fatal and non-fatal errors from any pipeline stage.
* Sinks for draining the result of a pipeline computation.

Some future enhancements are planned. Please leave any suggestions or
issues in the issue tracker.

Thanks

K. Alex Mills

-- 
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/CALJzkY8nuC3v_%3DzV3xhZ_18EXqvv9wPfvDfFZWg%3DQu0krpzqQA%40mail.gmail.com.

Re: [go-nuts] Re: Why declaring multiple variable at once for same type feature exists in Golang?

[K. Alex Mills]

Yes. Declaring i and j on the same line is certainly cleaner. We should all
do it like that.

Am I missing something?

On Thu, Aug 18, 2022, 9:25 PM Yasser Sinjab  wrote:

> Thanks, I don't object it personally, but I had a debate about "grouping
> variables is considered a clean code".
>
> Let's say you have the following code:
>
> var x, y, z string
> var i int
>
> And a new change came as:
>
> var j int
> var x, y, z string
> var i int
>
> For me this is not clean. Group them is cleaner like :
>
> var i, j int
>
>
> That's of course with the exception that variables should be as close to
> the logic it is initialized for.
> On Thursday, August 18, 2022 at 7:38:54 PM UTC+3 Brian Candler wrote:
>
>> There's also a lot of good background about the language design choices
>> in the FAQ:
>> https://go.dev/doc/faq
>>
>> Go derives much of its syntax from C, and the FAQ describes some of the
>> differences from C.  But note that even C allows you to do the same:
>>
>> int a, b, c;
>> char *x, *y, *z;
>>
>> On Thursday, 18 August 2022 at 17:35:21 UTC+1 Brian Candler wrote:
>>
>>> What exactly is it about that expression that you don't think seems
>>> right?
>>>
>>> It's a shortcut for:
>>>
>>> var x string
>>> var y string
>>> var z string
>>>
>>> I think that saving typing is a good feature.
>>>
>>> Or do you object to the feature of being able to declare variables at
>>> all?
>>>
>>> On Thursday, 18 August 2022 at 13:52:56 UTC+1 ysi...@gmail.com wrote:
>>>
 Hi,

 I'm just wondering why this feature is in Golang: such as

 var x, y, z string

 Thanks,
 Yasser

>>> --
> 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/ec5c344a-3a67-49d1-9da7-ec3633cfb903n%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/CALJzkY-2yzKs_j1cfrm_tzurw5Axpkn6ZG93rSbm5PPsj5UgPA%40mail.gmail.com.

Re: [go-nuts] gofmt 1.19 reformats comments in a way which breaks go-swagger

[K. Alex Mills]

I would hesitate to call this a bug in gofmt. Go released new godoc
features as part of Go 1.19, along with reformatting of comments. Those
features were entirely intentional.

The decision made in the go-swagger project to place its comments alongside
godoc comment blocks was a risky one in case of upstream changes like this
one.

That said, maybe a no-reformat directive is in order.

On Wed, Aug 17, 2022, 7:35 PM crod...@gmail.com  wrote:

> Hi,
>
> I have a codebase which uses go-swagger
>  to parse comments in Go files
> and generate swagger documentation.
>
> I recently upgraded to Go 1.19, and found that gofmt’s behavior formats
> comments in a way which breaks go-swagger.
>
> For example this code:
>
> package somepackage
> import (
> "encoding/json"
> "fmt"
> "io"
> "net/http"
> "strconv"
> "time"
>
> )
> // SomeFunc do something swagger:operation POST /api/v1/somefunc 
> someFunc Do something ---// x-codeSamples:// - lang: 'curl'//   
> source: |//   curl -u "${LOGIN}:${PASSWORD}" -d '{"key": "value"}' -X 
> POST   "https://{host}/api/v1/somefunc"//   curl -u 
> "${LOGIN}:${PASSWORD}" -d '{"key2": "value2"}' -X POST   
> "https://{host}/api/v1/somefunc"// responses://  '200'://description: 
> "Some func"//examples://  application/json://  key: "value"// 
>  '400'://$ref: "#/responses/ErrorResponse"//  '503'://$ref: 
> "#/responses/ErrorResponse"func SomeFunct(rw http.ResponseWriter, req 
> *http.Request) {
> /// do something
> }
>
> Gets reformatted as:
>
> package somepackage
>
> import (
> "encoding/json"
> "fmt"
> "io"
> "net/http"
> "strconv"
> "time"
> )
>
> // SomeFunc do something
> //
> // swagger:operation POST /api/v1/somefunc someFunc
> //
> // # Do something
> //
> // ---
> // x-codeSamples:
> //   - lang: 'curl'
> // source: |
> // curl -u "${LOGIN}:${PASSWORD}" -d '{"key": "value"}' -X POST   
> "https://{host}/api/v1/somefunc;
> // curl -u "${LOGIN}:${PASSWORD}" -d '{"key2": "value2"}' -X POST   
> "https://{host}/api/v1/somefunc;
> //
> // responses:
> //
> //'200':
> //  description: "Some func"
> //  examples:
> //application/json:
> //key: "value"
> //'400':
> //  $ref: "#/responses/ErrorResponse"
> //'503':
> //  $ref: "#/responses/ErrorResponse"
> func SomeFunct(rw http.ResponseWriter, req *http.Request) {
> /// do something
> }
>
> Specifically the lines under source: |
> get re-indented in such a way
> that the YAML is invalid, and go-swagger fails to process this file.
>
> This issue has been raised in the go-swagger community:
> https://github.com/go-swagger/go-swagger/issues/2759
>
> but I don’t think this can be worked around in go-swagger, since
> go-swagger parses the .go files after they have been formatted by gofmt
> and written to disk.
>
> Can anyone suggest a possible workaround, or a bugfix to gofmt?
> Thanks.
>
> —
> Craig
> ​
>
> --
> 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/d6abf372-4cb1-4070-8a62-d4c6c6ba6bcen%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/CALJzkY8xo3yw5rVHSCAtst6Jr8KtGZj9%2Bdrohib1DWBCo_bHWg%40mail.gmail.com.

Re: [go-nuts] Application Monitoring

[K. Alex Mills]

Monitoring and observability are best practices regardless of what language
you use. We use a combination of Prometheus / Grafana and metrics exported
by runtime/metrics. We also include custom metrics tailored to our
application's use-case.

Prometheus is not a standard Linux tool, but it is open source,
production-ready, language-agnostic, and widely used.


On Mon, Aug 15, 2022, 8:01 AM Rich  wrote:

> My company relies heavily on Java., Java apps we run require Introscope or
> Glowroot to monitor them and many outages have been solved using those
> tools.  If we were to write our apps in Go -- would we need an application
> monitoring tool, or would standard Linux tools suffice?
>
> Thanks-- Rich
>
> --
> 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/f65a5920-3dde-495b-bc87-0e14f2512e86n%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/CALJzkY_4OOsxcFkK6Ta5F_DVXt20fpK8PM4UJNwW33_B1i5nAw%40mail.gmail.com.

Re: [go-nuts] Pipelining with Go and Generics

[K. Alex Mills]

I don't think you're missing anything. AFAICT, you're right, a generic
Stream [T] interface with generic methods hanging off a struct cannot be
supported by the current generics implementation because of the restriction
on generic methods. I tried to do similar things by implementing interfaces
for common monads when the generics beta was released and could not make it
work.

But it's not clear to me that you need to have an explicit Stream[T] type
in order to have a generic streams package. As an alternative, the
pipelines package I've introduced here takes the position that "Stream[T]"
in Go is spelled "chan T". ;-)

What does instead is provide generic top-level functions which can start
and manage individual stages of the pipeline, leaving the particulars of
stitching the inputs and outputs of each stage to the caller. This approach
might not meet your definition of "chaining", but it gets the job done.


On Thu, Aug 11, 2022, 8:51 PM robert engels  wrote:

> I don’t think the chaining of the stream operations can work.
>
> AFAICT you cannot have optional type parameters, and you cannot add type
> parameters to methods, so a method like Map() on a stream instance can’t be
> written - because the stream is of type T, and the Map() produces a stream
> of type R.
>
> psuedo code:
>
> type Stream[T any] interface {
> ...
> Map[R any](func (T) R) Stream[R] // syntax not supported
>     ...
> }
>
> What am I missing?
>
> On Aug 11, 2022, at 5:18 PM, K. Alex Mills  wrote:
>
> Ah, my apologies, I was wrong. Panicking in the midst of a func passed to
> one of these pipeline stages most certainly *will not* shut down the
> entire pipeline and cannot be recovered like I had suggested. Sorry about
> that.
>
> Sincerely,
>
> K. Alex Mills
>
>
> On Thu, Aug 11, 2022 at 4:56 PM K. Alex Mills 
> wrote:
>
>> See the example added in this PR
>> <https://github.com/splunk/go-genlib/pull/24/files#diff-be22e454f59be60b572bf51007825f39f863a2b8e5dacfb32efeab4d1177d2f9R680>
>>  for one way to do error handling with this library without involving
>> panic/recover.
>>
>> One possible drawback to this approach is that it doesn't provide a way
>> to return an error directly from a `func` which has been passed to a
>> pipeline stage. I considered that, but it would seem to involve yet another
>> pair of variants for each proto stage: e.g. Map, MapCtx, MapCtxErr, and
>> MapErr, with the following signatures:
>>
>> func Map  [S, T any](ctx context.Context, in <-chan S, f func(S) T,
>>  opts ...Option) <-chan T
>> func MapCtx   [S, T any](ctx context.Context, in <-chan S, f
>> func(context.Context, S) T,  opts ...Option) <-chan T
>> func MapErr   [S, T any](ctx context.Context, in <-chan S, f func(S) (T,
>> error),  opts ...Option) <-chan T
>> func MapCtxErr[S, T any](ctx context.Context, in <-chan S, f
>> func(context.Context, S) (T, error), opts ...Option) <-chan T
>>
>> ...this proliferation of variants of essentially "the same" function is
>> making me reconsider some of my life choices. Asking each stage to capture
>> and interact with the ErrorSink yields a smaller API surface area. That
>> said, the Err variants would allow the library to do things like store
>> the ErrorSink in the context and use it if it's present.
>>
>> I'm not sure that's worth the complexity, and it feels very much like
>> "magic", where it seems Go "should" be explicit, but I can be convinced
>> otherwise.
>>
>> All that said, if you *really* want to panic and you don't mind the
>> pipeline shutting down whenever you do, I don't think there's anything
>> stopping you from doing so with this library. Just use recover at the top
>> of the func that spins up the pipeline and use context.WithCancel to shut
>> the rest of the pipeline down in that case. Let me know if that's unclear
>> and I'll do my best to provide an example.
>>
>> Sincerely,
>>
>> K. Alex Mills
>>
>>
>> On Thu, Aug 11, 2022 at 4:18 PM Robert Engels 
>> wrote:
>>
>>> Every modern language with generics or similar has a streams package so
>>> there’s no need to call out Java.
>>>
>>> Like I said, you can chain by passing and checking the errors within the
>>> streamcontext.
>>>
>>> On Aug 11, 2022, at 3:59 PM, Jan Mercl <0xj...@gmail.com> wrote:
>>>
>>> 
>>>
>>>
>>> On Thu, Aug 11, 2022, 22:37 Robert Engels  wrote:
>>>
>>>> I don’t think that

Re: [go-nuts] Pipelining with Go and Generics

[K. Alex Mills]

Ah, my apologies, I was wrong. Panicking in the midst of a func passed to
one of these pipeline stages most certainly *will not* shut down the entire
pipeline and cannot be recovered like I had suggested. Sorry about that.

Sincerely,

K. Alex Mills


On Thu, Aug 11, 2022 at 4:56 PM K. Alex Mills 
wrote:

> See the example added in this PR
> <https://github.com/splunk/go-genlib/pull/24/files#diff-be22e454f59be60b572bf51007825f39f863a2b8e5dacfb32efeab4d1177d2f9R680>
> for one way to do error handling with this library without involving
> panic/recover.
>
> One possible drawback to this approach is that it doesn't provide a way to
> return an error directly from a `func` which has been passed to a pipeline
> stage. I considered that, but it would seem to involve yet another pair of
> variants for each proto stage: e.g. Map, MapCtx, MapCtxErr, and MapErr,
> with the following signatures:
>
> func Map  [S, T any](ctx context.Context, in <-chan S, f func(S) T,
>opts ...Option) <-chan T
> func MapCtx   [S, T any](ctx context.Context, in <-chan S, f
> func(context.Context, S) T,  opts ...Option) <-chan T
> func MapErr   [S, T any](ctx context.Context, in <-chan S, f func(S) (T,
> error),  opts ...Option) <-chan T
> func MapCtxErr[S, T any](ctx context.Context, in <-chan S, f
> func(context.Context, S) (T, error), opts ...Option) <-chan T
>
> ...this proliferation of variants of essentially "the same" function is
> making me reconsider some of my life choices. Asking each stage to capture
> and interact with the ErrorSink yields a smaller API surface area. That
> said, the Err variants would allow the library to do things like store
> the ErrorSink in the context and use it if it's present.
>
> I'm not sure that's worth the complexity, and it feels very much like
> "magic", where it seems Go "should" be explicit, but I can be convinced
> otherwise.
>
> All that said, if you *really* want to panic and you don't mind the
> pipeline shutting down whenever you do, I don't think there's anything
> stopping you from doing so with this library. Just use recover at the top
> of the func that spins up the pipeline and use context.WithCancel to shut
> the rest of the pipeline down in that case. Let me know if that's unclear
> and I'll do my best to provide an example.
>
> Sincerely,
>
> K. Alex Mills
>
>
> On Thu, Aug 11, 2022 at 4:18 PM Robert Engels 
> wrote:
>
>> Every modern language with generics or similar has a streams package so
>> there’s no need to call out Java.
>>
>> Like I said, you can chain by passing and checking the errors within the
>> streamcontext.
>>
>> On Aug 11, 2022, at 3:59 PM, Jan Mercl <0xj...@gmail.com> wrote:
>>
>> 
>>
>>
>> On Thu, Aug 11, 2022, 22:37 Robert Engels  wrote:
>>
>>> I don’t think that is relevant. It is very difficult to do chaining with
>>> Go’s error model.
>>>
>>
>> I don't think "Go's error model" is a thing. The language specification
>> does not mention it and I'm not aware of any official Go documentation that
>> should be considered the "Go's error model".
>>
>> Go has the predefined error interface with a single method. That's all.
>> The rest is at most a convention. No need to make a  ceremony of it.
>>
>> Wrt "it's very difficult...". Of course it's difficult to do idioms from
>> other languages in Go when those idioms Go intentionally does not support.
>> So the claim is sort of a tautology, isn't it?
>>
>> Once again, having different preferences is okay. Generalizing personal
>> preferences as Go fault is IMO not okay.
>>
>> Maybe you can fill a proposal at the Go issue tracker to add all/some/any
>> Java/etc idioms to Go and let's see how it works.
>>
>> You can pass a shared context to every node and store the error in the
>>> context and protect against concurrent access. It’s doable but not easy.
>>>
>>> Map/reduce and most functional patterns are easily represented using
>>> chains.
>>>
>>> But like I said, I would use panic/recover in the framework to make it
>>> easier.
>>>
>>>
>>>
>>> On Aug 11, 2022, at 3:27 PM, Jan Mercl <0xj...@gmail.com> wrote:
>>>
>>> 
>>>
>>>
>>> On Thu, Aug 11, 2022, 21:36 Robert Engels  wrote:
>>>
>>>> I’d say it certainly highlights a problem with Go’s error model.
>>>> Exceptions would fit nicely here - instead it seems you needed to ignore
&g

Re: [go-nuts] Pipelining with Go and Generics

[K. Alex Mills]

See the example added in this PR
<https://github.com/splunk/go-genlib/pull/24/files#diff-be22e454f59be60b572bf51007825f39f863a2b8e5dacfb32efeab4d1177d2f9R680>
for one way to do error handling with this library without involving
panic/recover.

One possible drawback to this approach is that it doesn't provide a way to
return an error directly from a `func` which has been passed to a pipeline
stage. I considered that, but it would seem to involve yet another pair of
variants for each proto stage: e.g. Map, MapCtx, MapCtxErr, and MapErr,
with the following signatures:

func Map  [S, T any](ctx context.Context, in <-chan S, f func(S) T,
   opts ...Option) <-chan T
func MapCtx   [S, T any](ctx context.Context, in <-chan S, f
func(context.Context, S) T,  opts ...Option) <-chan T
func MapErr   [S, T any](ctx context.Context, in <-chan S, f func(S) (T,
error),  opts ...Option) <-chan T
func MapCtxErr[S, T any](ctx context.Context, in <-chan S, f
func(context.Context, S) (T, error), opts ...Option) <-chan T

...this proliferation of variants of essentially "the same" function is
making me reconsider some of my life choices. Asking each stage to capture
and interact with the ErrorSink yields a smaller API surface area. That
said, the Err variants would allow the library to do things like store the
ErrorSink in the context and use it if it's present.

I'm not sure that's worth the complexity, and it feels very much like
"magic", where it seems Go "should" be explicit, but I can be convinced
otherwise.

All that said, if you *really* want to panic and you don't mind the
pipeline shutting down whenever you do, I don't think there's anything
stopping you from doing so with this library. Just use recover at the top
of the func that spins up the pipeline and use context.WithCancel to shut
the rest of the pipeline down in that case. Let me know if that's unclear
and I'll do my best to provide an example.

Sincerely,

K. Alex Mills


On Thu, Aug 11, 2022 at 4:18 PM Robert Engels  wrote:

> Every modern language with generics or similar has a streams package so
> there’s no need to call out Java.
>
> Like I said, you can chain by passing and checking the errors within the
> streamcontext.
>
> On Aug 11, 2022, at 3:59 PM, Jan Mercl <0xj...@gmail.com> wrote:
>
> 
>
>
> On Thu, Aug 11, 2022, 22:37 Robert Engels  wrote:
>
>> I don’t think that is relevant. It is very difficult to do chaining with
>> Go’s error model.
>>
>
> I don't think "Go's error model" is a thing. The language specification
> does not mention it and I'm not aware of any official Go documentation that
> should be considered the "Go's error model".
>
> Go has the predefined error interface with a single method. That's all.
> The rest is at most a convention. No need to make a  ceremony of it.
>
> Wrt "it's very difficult...". Of course it's difficult to do idioms from
> other languages in Go when those idioms Go intentionally does not support.
> So the claim is sort of a tautology, isn't it?
>
> Once again, having different preferences is okay. Generalizing personal
> preferences as Go fault is IMO not okay.
>
> Maybe you can fill a proposal at the Go issue tracker to add all/some/any
> Java/etc idioms to Go and let's see how it works.
>
> You can pass a shared context to every node and store the error in the
>> context and protect against concurrent access. It’s doable but not easy.
>>
>> Map/reduce and most functional patterns are easily represented using
>> chains.
>>
>> But like I said, I would use panic/recover in the framework to make it
>> easier.
>>
>>
>>
>> On Aug 11, 2022, at 3:27 PM, Jan Mercl <0xj...@gmail.com> wrote:
>>
>> 
>>
>>
>> On Thu, Aug 11, 2022, 21:36 Robert Engels  wrote:
>>
>>> I’d say it certainly highlights a problem with Go’s error model.
>>> Exceptions would fit nicely here - instead it seems you needed to ignore
>>> all error handling - because chaining is impossible with error returns.
>>>
>>
>> It's okay if someone prefers the way Java does things, but the best thing
>> about Go is IMHO that it is not Java. And I still hope it stays away from
>> becoming Java as long as possible.
>>
>>
>>> A streams api with panic/recover is needed.
>>>
>>> On Aug 11, 2022, at 12:55 PM, K. Alex Mills 
>>> wrote:
>>>
>>> 
>>> Hello Gophers,
>>>
>>> I recently had an opportunity to try out Go generics on a small
>>> pipelines package
>>> <https://pkg.go.dev/github.com/splunk/go-genlib/pipeli

Re: [go-nuts] Pipelining with Go and Generics

[K. Alex Mills]

Thanks so much for taking a look, and good catch! Error handling is
definitely a missing piece in the library at the moment. I'm not sure
panic/recover is the direction I'd take it, but I do think it could be made
to work.

When using this library, the way we're handling errors is by hanging the
entire pipeline system off a struct which provides access to an error chan.
Every pipeline stage shares the same context, which a separate goroutine
cancels if any error is seen on the error channel.

I've considered including error handling based either around this idea or
an errgroup, but haven't had time to write it up. Might do so soon.

On Thu, Aug 11, 2022, 2:36 PM Robert Engels  wrote:

> I’d say it certainly highlights a problem with Go’s error model.
> Exceptions would fit nicely here - instead it seems you needed to ignore
> all error handling - because chaining is impossible with error returns.
>
> A streams api with panic/recover is needed.
>
> On Aug 11, 2022, at 12:55 PM, K. Alex Mills 
> wrote:
>
> 
> Hello Gophers,
>
> I recently had an opportunity to try out Go generics on a small pipelines
> package <https://pkg.go.dev/github.com/splunk/go-genlib/pipelines>, along
> with some of my coworkers.
>
> The overall goal of this package is to provide helpers for separating
> concurrency from the core logic of the computation. The result was intended
> for I/O bound computations, and so it's likely inappropriate for managing
> short-lived goroutines. It takes a functional programming approach,
> providing helpers with familiar names seen in other APIs like Map, FlatMap,
> OptionMap, etc. One feature which I am particularly happy with is that
> concurrency concerns like worker pool size and channel buffers are
> configurable with minimal disruption to the rest of the code.
>
> Take a look at the library
> <https://pkg.go.dev/github.com/splunk/go-genlib/pipelines> and its
> accompanying blog post <https://kalexmills.com/journal/pipelines/>. I'm
> open to any of your thoughts, suggestions, and issue reports.
>
> Sincerely,
>
> K. Alex Mills
>
> --
> 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/CALJzkY_zASs-YOukv6ciSO45b93jz39DmjAWA915kfBuwimkgQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CALJzkY_zASs-YOukv6ciSO45b93jz39DmjAWA915kfBuwimkgQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/CALJzkY_FmOoSSFAhosUsJ1aQv6b25oo9t%3D5%3DZb5rqe0mBWp1Mw%40mail.gmail.com.

[go-nuts] Pipelining with Go and Generics

[K. Alex Mills]

Hello Gophers,

I recently had an opportunity to try out Go generics on a small pipelines
package <https://pkg.go.dev/github.com/splunk/go-genlib/pipelines>, along
with some of my coworkers.

The overall goal of this package is to provide helpers for separating
concurrency from the core logic of the computation. The result was intended
for I/O bound computations, and so it's likely inappropriate for managing
short-lived goroutines. It takes a functional programming approach,
providing helpers with familiar names seen in other APIs like Map, FlatMap,
OptionMap, etc. One feature which I am particularly happy with is that
concurrency concerns like worker pool size and channel buffers are
configurable with minimal disruption to the rest of the code.

Take a look at the library
<https://pkg.go.dev/github.com/splunk/go-genlib/pipelines> and its
accompanying blog post <https://kalexmills.com/journal/pipelines/>. I'm
open to any of your thoughts, suggestions, and issue reports.

Sincerely,

K. Alex Mills

-- 
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/CALJzkY_zASs-YOukv6ciSO45b93jz39DmjAWA915kfBuwimkgQ%40mail.gmail.com.

[go-nuts] Is this algorithm viable? its faster than AES256 upto 50KB

[Alex Breadman]

package mod

import (
"testing"
)

func TestEncrypt(t *testing.T) {
password := []byte("*RTFUGIHOD")
data := []byte("This encryption algorithm is faster than aes256 up to 40kb 
but how secure is it?")
for x, _ := range data {
p := (password[x%len(password)])
data[x] = data[x] + byte(p)
}
println(string(data))
for x, _ := range data {
p := (password[x%len(password)])
data[x] = data[x] - byte(p)
}
println(string(data))
}

Surely it is only as strong as the password?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1c8a67cb-d7da-4c41-a8c5-92727d24e773n%40googlegroups.com.

[go-nuts] Re: How do you make a ReadCloser?

[Alex Shi]

Note. For ioutil#NopCloser, as of Go 1.16, this function simply calls 
io.NopCloser. 

On Friday, July 1, 2022 at 1:09:15 PM UTC+8 Ansuraj Khadanga wrote:

> Thats great! Thanks for sharing.
>
> req.Body = ioutil.NopCloser(bytes.NewReader([]byte("foo")))
>
> works!
>
> On Wednesday, 27 June 2018 at 22:21:52 UTC+5:30 keens...@gmail.com wrote:
>
>> This worked perfectly, thanks!
>>
>>
>> On Tuesday, December 1, 2015 at 5:29:27 AM UTC-8, Borja Berastegui wrote:
>>>
>>> req.Body = ioutil.NopCloser(bytes.NewReader([]byte("foo")))
>>>
>>>

-- 
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/50a81a4a-39b7-4d67-ab5e-8ef6fae626c9n%40googlegroups.com.

[go-nuts] Re: Java to Go converter - 2

[alex-coder]

time.Duration(rand.Intn(n)) }
type Thread struct {
Runnable
}
func (t *Thread) run(wg *sync.WaitGroup) {
t.Runnable.run(wg)
}
type Runnable interface {
run(wg *sync.WaitGroup)
}

You can run code there:
Go Playground <https://go.dev/play/p/-y6f_rOa4EX>

Now I'll take a break, I need to deal with the advices that I received.
Thank you to all very much.
среда, 18 мая 2022 г. в 13:43:07 UTC+3, alex-coder: 

> Henry,
> thank you, it is quite possible that you are right, at least I should 
> check it out.
> Thank you again.
>
> среда, 18 мая 2022 г. в 07:39:49 UTC+3, Henry: 
>
>> Kudos to you. Java to Go is a lot of work. Java is a more complex 
>> language. It has more features and more possibilities for expressing the 
>> same model/algorithm. You need to identify all these possibilities, parse, 
>> and convert them to Go. I could be wrong about this, but it may be easier 
>> to convert Java bytecode to Go.   
>>
>> On Tuesday, May 17, 2022 at 9:49:09 PM UTC+7 alex-coder wrote:
>>
>>> In Go, multithreading is one of the main features, respectively, the 
>>> ability to convert Java code using multithreading into Go code 
>>> automatically, which uses channels, is very important.
>>> I found a suitable example of ProducerConsumerExample from Oracle 
>>> there:Oracle 
>>> sample 
>>> <https://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html>,
>>>  
>>> where the Drop class is a candidate for conversion to Go using channels.
>>> But, now I give an intermediate result without channels.
>>> Also, I read the opinion that the conversion of Java code where 
>>> annotations are used in runtime is impossible. It is necessary to 
>>> investigate the problem and try to understand if it is possible to solve it 
>>> somehow. Before transferring a project from the status of "possibility of 
>>> achievement" to the status of "prototype", it is necessary to see what can 
>>> be done with these problems in relation to annotations.
>>> *Java code:*
>>> package com.builder.start.here;
>>>
>>> import java.util.Random;
>>>
>>> public class RunMeDrop {
>>>
>>> public static void main(String[] args) {
>>> Drop drop = new Drop();
>>> (new Thread(new Producer(drop))).start();
>>> (new Thread(new Consumer(drop))).start();
>>> }
>>> }
>>> class Drop {
>>> // Message sent from producer
>>> // to consumer.
>>> private String message;
>>> // True if consumer should wait
>>> // for producer to send message,
>>> // false if producer should wait for
>>> // consumer to retrieve message.
>>> private boolean empty = true;
>>>
>>> public synchronized String take() {
>>> // Wait until message is
>>> // available.
>>> while (empty) {
>>> try {
>>> wait();
>>> } catch (InterruptedException e) {}
>>> }
>>> // Toggle status.
>>> empty = true;
>>> // Notify producer that
>>> // status has changed.
>>> notifyAll();
>>> return message;
>>> }
>>>
>>> public synchronized void put(String message) {
>>> // Wait until message has
>>> // been retrieved.
>>> while (!empty) {
>>> try { 
>>> wait();
>>> } catch (InterruptedException e) {}
>>> }
>>> // Toggle status.
>>> empty = false;
>>> // Store message.
>>> this.message = message;
>>> // Notify consumer that status
>>> // has changed.
>>> notifyAll();
>>> }
>>> }
>>> class Consumer implements Runnable {
>>> private Drop drop;
>>>
>>> public Consumer(Drop drop) {
>>> this.drop = drop;
>>> }
>>>
>>> public void run() {
>>> Random random = new Random();
>>> for (
>>>String message = drop.take(); 
>>>! message.equals("DONE"); 
>>>message = drop.take()) {
>>> System.out.format(
>>>"MESSAGE RECEIVED: %s%n", message);
>>>  try {
>>> Thread

[go-nuts] Re: Java to Go converter - 2

[alex-coder]

Henry,
thank you, it is quite possible that you are right, at least I should check 
it out.
Thank you again.

среда, 18 мая 2022 г. в 07:39:49 UTC+3, Henry: 

> Kudos to you. Java to Go is a lot of work. Java is a more complex 
> language. It has more features and more possibilities for expressing the 
> same model/algorithm. You need to identify all these possibilities, parse, 
> and convert them to Go. I could be wrong about this, but it may be easier 
> to convert Java bytecode to Go.   
>
> On Tuesday, May 17, 2022 at 9:49:09 PM UTC+7 alex-coder wrote:
>
>> In Go, multithreading is one of the main features, respectively, the 
>> ability to convert Java code using multithreading into Go code 
>> automatically, which uses channels, is very important.
>> I found a suitable example of ProducerConsumerExample from Oracle 
>> there:Oracle 
>> sample 
>> <https://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html>,
>>  
>> where the Drop class is a candidate for conversion to Go using channels.
>> But, now I give an intermediate result without channels.
>> Also, I read the opinion that the conversion of Java code where 
>> annotations are used in runtime is impossible. It is necessary to 
>> investigate the problem and try to understand if it is possible to solve it 
>> somehow. Before transferring a project from the status of "possibility of 
>> achievement" to the status of "prototype", it is necessary to see what can 
>> be done with these problems in relation to annotations.
>> *Java code:*
>> package com.builder.start.here;
>>
>> import java.util.Random;
>>
>> public class RunMeDrop {
>>
>> public static void main(String[] args) {
>> Drop drop = new Drop();
>> (new Thread(new Producer(drop))).start();
>> (new Thread(new Consumer(drop))).start();
>> }
>> }
>> class Drop {
>> // Message sent from producer
>> // to consumer.
>> private String message;
>> // True if consumer should wait
>> // for producer to send message,
>> // false if producer should wait for
>> // consumer to retrieve message.
>> private boolean empty = true;
>>
>> public synchronized String take() {
>> // Wait until message is
>> // available.
>> while (empty) {
>> try {
>> wait();
>> } catch (InterruptedException e) {}
>> }
>> // Toggle status.
>> empty = true;
>> // Notify producer that
>> // status has changed.
>> notifyAll();
>> return message;
>> }
>>
>> public synchronized void put(String message) {
>> // Wait until message has
>> // been retrieved.
>> while (!empty) {
>> try { 
>> wait();
>> } catch (InterruptedException e) {}
>> }
>> // Toggle status.
>> empty = false;
>> // Store message.
>> this.message = message;
>> // Notify consumer that status
>> // has changed.
>> notifyAll();
>> }
>> }
>> class Consumer implements Runnable {
>> private Drop drop;
>>
>> public Consumer(Drop drop) {
>> this.drop = drop;
>> }
>>
>> public void run() {
>> Random random = new Random();
>> for (
>>String message = drop.take(); 
>>! message.equals("DONE"); 
>>message = drop.take()) {
>> System.out.format(
>>"MESSAGE RECEIVED: %s%n", message);
>>  try {
>> Thread.sleep(random.nextInt(5000));
>>} catch (InterruptedException e) {}
>> }
>> }
>> }
>> class Producer implements Runnable {
>> private Drop drop;
>>
>> public Producer(Drop drop) {
>> this.drop = drop;
>> }
>>
>> public void run() {
>> String importantInfo[] = {
>> "Mares eat oats",
>> "Does eat oats",
>> "Little lambs eat ivy",
>> "A kid will eat ivy too"
>> };
>> Random random = new Random();
>>
>> for (int i = 0; i < importantInfo.length; i++) {
>> drop.put(importantInfo[i]);
>> try {
>>

[go-nuts] Re: Java to Go converter - 2

[alex-coder]

) {
defer wg.Done()

var random *Random = NewRandom()
for message := consumer.drop.take(); 
 message != "DONE"; 
 message = consumer.drop.take() {
fmt.Printf("MESSAGE RECEIVED: %s\n", message)
time.Sleep(random.nextInt(5000))
}
}

type Producer struct {
drop *Drop
}

func NewProducer(drop *Drop) *Producer {
var producer Producer = Producer{drop}
return 
}
func (producer *Producer) run(wg *sync.WaitGroup) {
defer wg.Done()

var importantInfo [4]string = [4]string{
"Mares eat oats",
"Does eat oats",
"Little lambs eat ivy",
"A kid will eat ivy too",
}

var random *Random = NewRandom()
for i := 0; i < len(importantInfo); i++ {
producer.drop.put([i])
time.Sleep(random.nextInt(5000))
}
s := "DONE"
producer.drop.put()
}

type Random struct{}

func NewRandom() *Random {
var random Random = Random{}
return 
}

func (r *Random) nextInt(n int) time.Duration { 
return time.Duration(rand.Intn(n)) 
}

type Thread struct {
Runnable
}

func (t *Thread) run(wg *sync.WaitGroup) {
t.Runnable.run(wg)
}

type Runnable interface {
run(wg *sync.WaitGroup)
}
The Go Playground, you can run code there:
Go Playground. <https://go.dev/play/p/o7tXt8p2m_3>

Thank you to all very much.

четверг, 28 апреля 2022 г. в 19:08:51 UTC+3, alex-coder: 

> So, multithreading.
> I found a simple example from Oracle with the wonderful name "Bad Threads" 
> there:
>
> https://docs.oracle.com/javase/tutorial/essential/concurrency/QandE/questions.html
>  
> , simplified it even more, called the example a new simple name One and 
> extend a Converter to translate the code to Golang.
> There is no similar processing for InterruptedException in go, so the 
> Converter does not translate the processing of this interrupt in any way. 
> If anyone has a relatively small example in Java, please share it.
> *Java code:*
> package run.me;
> public class One {
>   String msg;
>   public static void main(  String[] args) throws InterruptedException {
> One one=new One();
> one.msg="Initial message";
> System.out.println("main:before start:" + one.msg + " second part of");
> new Second(one).start();
> one.msg="after go start";
> Thread.sleep(2000);
> System.out.println("main:about to end:" + one.msg);
>   }
> }
> class Second extends Thread {
>   One one;
>   public Second(  One one){
> this.one=one;
>   }
>   public void run(){
> try {
>   sleep(1000);
> } catch (InterruptedException e) {
> }
> System.out.println("run:after sleep:" + one.msg);
> one.msg="try to change msg";
>   }
> }
> *Converter выдал:*
> package main
>
> import (
> "fmt"
> "os"
> "time"
> )
>
> type One struct {
> msg *string
> }
>
> func NewOne() *One {
> var one One = One{}
> return 
> }
> func main() {
> var args []string = os.Args
> var o_dummy *One = NewOne()
> o_dummy.One_main()
> }
>
> /** generated method **/
> func (one_one *One) One_main(args *[]string) {
> var one *One = NewOne()
> s := "Initial message"
> one.msg = 
> fmt.Println("main:before start:" + *one.msg + " second part of")
> go NewSecond(one).run()
> s_s := "after go start"
> one.msg = _s
> time.Sleep(2000)
> fmt.Println("main:about to end:" + *one.msg)
> }
>
> type Second struct {
> one *One
> }
>
> func NewSecond(one *One) *Second {
> var second Second = Second{one}
> return 
> }
> func (second *Second) run() {
> time.Sleep(1000)
> fmt.Println("run:after sleep:" + *second.one.msg)
> s_s_s := "try to change msg"
> second.one.msg = _s_s
> }
>
> The next example will probably be about channel's.
> If anyone has an interesting example, write me, I'll think about how to 
> solve it. I just can't promise that it will be quickly. :-)
>
> Thank you to all !
>
> четверг, 7 апреля 2022 г. в 18:52:25 UTC+3, alex-coder: 
>
>> Thanks for the comments about generating code to handle exceptions. . 
>> Here it is a new version.
>> package main
>>
>> import (
>> "fmt"
>> "os"
>> )
>>
>> type CatchException struct{}
>>
>> func main() {
>>
>> var args []string = os.Args
>>
>> var ce CatchException = CatchException{}
>

[go-nuts] Re: Java to Go converter - 2

[alex-coder]

So, multithreading.
I found a simple example from Oracle with the wonderful name "Bad Threads" 
there:
https://docs.oracle.com/javase/tutorial/essential/concurrency/QandE/questions.html
 
, simplified it even more, called the example a new simple name One and 
extend a Converter to translate the code to Golang.
There is no similar processing for InterruptedException in go, so the 
Converter does not translate the processing of this interrupt in any way. 
If anyone has a relatively small example in Java, please share it.
*Java code:*
package run.me;
public class One {
  String msg;
  public static void main(  String[] args) throws InterruptedException {
One one=new One();
one.msg="Initial message";
System.out.println("main:before start:" + one.msg + " second part of");
new Second(one).start();
one.msg="after go start";
Thread.sleep(2000);
System.out.println("main:about to end:" + one.msg);
  }
}
class Second extends Thread {
  One one;
  public Second(  One one){
this.one=one;
  }
  public void run(){
try {
  sleep(1000);
} catch (InterruptedException e) {
}
System.out.println("run:after sleep:" + one.msg);
one.msg="try to change msg";
  }
}
*Converter выдал:*
package main

import (
"fmt"
"os"
"time"
)

type One struct {
msg *string
}

func NewOne() *One {
var one One = One{}
return 
}
func main() {
var args []string = os.Args
var o_dummy *One = NewOne()
o_dummy.One_main()
}

/** generated method **/
func (one_one *One) One_main(args *[]string) {
var one *One = NewOne()
s := "Initial message"
one.msg = 
fmt.Println("main:before start:" + *one.msg + " second part of")
go NewSecond(one).run()
s_s := "after go start"
one.msg = _s
time.Sleep(2000)
fmt.Println("main:about to end:" + *one.msg)
}

type Second struct {
one *One
}

func NewSecond(one *One) *Second {
var second Second = Second{one}
return 
}
func (second *Second) run() {
time.Sleep(1000)
fmt.Println("run:after sleep:" + *second.one.msg)
s_s_s := "try to change msg"
second.one.msg = _s_s
}

The next example will probably be about channel's.
If anyone has an interesting example, write me, I'll think about how to 
solve it. I just can't promise that it will be quickly. :-)

Thank you to all !

четверг, 7 апреля 2022 г. в 18:52:25 UTC+3, alex-coder: 

> Thanks for the comments about generating code to handle exceptions. . Here 
> it is a new version.
> package main
>
> import (
> "fmt"
> "os"
> )
>
> type CatchException struct{}
>
> func main() {
>
> var args []string = os.Args
>
> var ce CatchException = CatchException{}
> ce.CatchException_main(args)
> }
>
> /** generated method **/
> func (catchException *CatchException) CatchException_main(args []string) {
> defer func() {
> if err := recover(); err != nil {
> exc := err.(Exception)
> switch exc.msg {
>
> case "Exception":
> fmt.Println("yes, I caught it")
> default:
> fmt.Println("No, something is not right")
> }
> }
> fmt.Println("finally processing")
> }()
>
> ({}).runme()
> }
>
> type ThrowException struct{}
>
> func (throwException *ThrowException) runme() {
> panic(Exception{"Exception"})
> }
>
> type Exception struct {
> msg string
> }
>
> понедельник, 4 апреля 2022 г. в 14:12:37 UTC+3, alex-coder: 
>
>>
>>
>>
>>
>> *Another use case for automatically translating codewritten in Java to 
>> Golang is Exception Handling.The next example is likely to be about 
>> multithreading.Example in Java:*
>> package com.builder.start.here;
>>
>> public class CatchException {
>>
>> public static void main(String[] args) {
>> try {
>> new ThrowException().runme();
>> } catch (Exception e) {
>> System.out.println("yes, I caught it");
>> } finally {
>> System.out.println("finally processing");
>> }
>>
>> }
>>
>> }
>>
>> class ThrowException{
>> public void runme() throws Exception{
>> throw new Exception();
>> }
>> }
>>
>> *Converter gave out:*
>>
>> package main
>>
>> import (
>> "fmt"
>> "os"
>> )
>>
>> type CatchExcept

[go-nuts] Re: Java to Go converter - 2

[alex-coder]

Thanks for the comments about generating code to handle exceptions. . Here 
it is a new version.
package main

import (
"fmt"
"os"
)

type CatchException struct{}

func main() {

var args []string = os.Args

var ce CatchException = CatchException{}
ce.CatchException_main(args)
}

/** generated method **/
func (catchException *CatchException) CatchException_main(args []string) {
defer func() {
if err := recover(); err != nil {
exc := err.(Exception)
switch exc.msg {
case "Exception":
fmt.Println("yes, I caught it")
default:
fmt.Println("No, something is not right")
}
}
fmt.Println("finally processing")
}()

({}).runme()
}

type ThrowException struct{}

func (throwException *ThrowException) runme() {
panic(Exception{"Exception"})
}

type Exception struct {
msg string
}

понедельник, 4 апреля 2022 г. в 14:12:37 UTC+3, alex-coder: 

>
>
>
>
> *Another use case for automatically translating codewritten in Java to 
> Golang is Exception Handling.The next example is likely to be about 
> multithreading.Example in Java:*
> package com.builder.start.here;
>
> public class CatchException {
>
> public static void main(String[] args) {
> try {
> new ThrowException().runme();
> } catch (Exception e) {
> System.out.println("yes, I caught it");
> } finally {
> System.out.println("finally processing");
> }
>
> }
>
> }
>
> class ThrowException{
> public void runme() throws Exception{
> throw new Exception();
> }
> }
>
> *Converter gave out:*
>
> package main
>
> import (
> "fmt"
> "os"
> )
>
> type CatchException struct{}
>
>
> func main() {
>
> var args []string = os.Args
>
> var ce CatchException = CatchException{}
> ce.CatchException_main(args)
> }
>
> /** generated method **/
> func (catchException *CatchException) CatchException_main(args []string) {
> defer func() {
> if err := recover(); err != nil {
> str := err.(string)
> switch str {
> case "Exception":
> fmt.Println("yes, I caught it")
> default:
> fmt.Println("No, something is not right")
> }
> }
> fmt.Println("finally processing")
> }()
>
> ({}).runme()
> }
>
> type ThrowException struct{}
>
> func (throwException *ThrowException) runme() {
> panic("Exception")
> }
> воскресенье, 27 марта 2022 г. в 15:11:48 UTC+3, alex-coder: 
>
>> After several months of switching from Java to Golang, it seemed to me 
>> that
>> it would be interesting to make the translation of Java code into Golang 
>> automatically.
>> The text below shows what has been done so far.
>>
>> The work is not a prototype, but rather indicates the possibility of 
>> achieving a result.
>> Therefore, I deliberately simplify the development context of the 
>> Converter where it was 
>> possible. 
>>
>> At first it seemed important to me that between Java and Go there is a 
>> difference 
>> between the implementation of the Dynamic Dispatching, more precisely, 
>> there is no 
>> Dynamic Dispatching in Go. The applied solution in the current 
>> implementation 
>> looks not only ugly but even violates the several very important rules of 
>> the OO design, 
>> I'm not kidding here. But this option looks like that it will be working. 
>>
>> Onward I will provide the 4 code samples in Java, followed by the 
>> automatically 
>> generated Golang code and comments as needed. 
>>
>> *1. Of course, I started with the most popular program: "Hello World".*
>>
>> package main;
>>
>> public class HelloWorld {
>>   public static void main(  String[] args){
>> System.out.println("Hello World");
>>   }
>> }
>>
>> *Converter gave out:*
>>
>> package main
>>
>> import (
>> "fmt"
>> "os"
>> )
>>
>> type HelloWorld struct{}
>>
>> func main() {
>>
>> var args []string = os.Args
>>
>> var hw HelloWorld = HelloWorld{}
>> hw.HelloWorld_main(args)
>> }
>>
>> /** generated method **/
>> func (helloWorld *HelloWorld) HelloWo

[go-nuts] Re: Java to Go converter - 2

[alex-coder]

*Another use case for automatically translating codewritten in Java to 
Golang is Exception Handling.The next example is likely to be about 
multithreading.Example in Java:*
package com.builder.start.here;

public class CatchException {

public static void main(String[] args) {
try {
new ThrowException().runme();
} catch (Exception e) {
System.out.println("yes, I caught it");
} finally {
System.out.println("finally processing");
}

}

}

class ThrowException{
public void runme() throws Exception{
throw new Exception();
}
}

*Converter gave out:*

package main

import (
"fmt"
"os"
)

type CatchException struct{}

func main() {

var args []string = os.Args

var ce CatchException = CatchException{}
ce.CatchException_main(args)
}

/** generated method **/
func (catchException *CatchException) CatchException_main(args []string) {
defer func() {
if err := recover(); err != nil {
str := err.(string)
switch str {
case "Exception":
fmt.Println("yes, I caught it")
default:
fmt.Println("No, something is not right")
}
}
fmt.Println("finally processing")
}()

({}).runme()
}

type ThrowException struct{}

func (throwException *ThrowException) runme() {
panic("Exception")
}
воскресенье, 27 марта 2022 г. в 15:11:48 UTC+3, alex-coder: 

> After several months of switching from Java to Golang, it seemed to me that
> it would be interesting to make the translation of Java code into Golang 
> automatically.
> The text below shows what has been done so far.
>
> The work is not a prototype, but rather indicates the possibility of 
> achieving a result.
> Therefore, I deliberately simplify the development context of the 
> Converter where it was 
> possible. 
>
> At first it seemed important to me that between Java and Go there is a 
> difference 
> between the implementation of the Dynamic Dispatching, more precisely, 
> there is no 
> Dynamic Dispatching in Go. The applied solution in the current 
> implementation 
> looks not only ugly but even violates the several very important rules of 
> the OO design, 
> I'm not kidding here. But this option looks like that it will be working. 
>
> Onward I will provide the 4 code samples in Java, followed by the 
> automatically 
> generated Golang code and comments as needed. 
>
> *1. Of course, I started with the most popular program: "Hello World".*
>
> package main;
>
> public class HelloWorld {
>   public static void main(  String[] args){
> System.out.println("Hello World");
>   }
> }
>
> *Converter gave out:*
>
> package main
>
> import (
> "fmt"
> "os"
> )
>
> type HelloWorld struct{}
>
> func main() {
>
> var args []string = os.Args
>
> var hw HelloWorld = HelloWorld{}
> hw.HelloWorld_main(args)
> }
>
> /** generated method **/
> func (helloWorld *HelloWorld) HelloWorld_main(args []string) {
> fmt.Println("Hello World")
> }
>
> *2. Next, it was interesting to deal with the problem of a simple 
> inheritance.*
>
> package main;
>
> public class TestInheritance {
>   public static void main(  String[] args){
> Inheritance inh=null;
> inh=new Second();
> inh.hello();
> inh=new Third();
> inh.hello();
>   }
> }
> public interface Inheritance {
>   public void hello();
> }
> class Second implements Inheritance {
>   public void hello(){
> System.out.println("Second");
>   }
> }
> class Third implements Inheritance {
>   public void hello(){
> System.out.println("Third");
>   }
> }
>  
> *Converter gave out:*
>
> package main
>
> import (
> "fmt"
> "os"
> )
>
> type TestInheritance struct{}
>
> func main() {
>
> var args []string = os.Args
>
> var ti TestInheritance = TestInheritance{}
> ti.TestInheritance_main(args)
> }
>
> /** generated method **/
> func (testInheritance *TestInheritance) TestInheritance_main(args 
> []string) {
>
> var inh Inheritance
> inh = AddressSecond(Second{})
> inh.hello()
> inh = AddressThird(Third{})
> inh.hello()
> }
>
> type Inheritance interface {
> hello()
> }
> type Second struct{}
>
> func (second *Second) hello() {
> fmt.Println("Second")
> }
>
> type Third s

[go-nuts] Java to Go converter - 2

[alex-coder]

After several months of switching from Java to Golang, it seemed to me that
it would be interesting to make the translation of Java code into Golang 
automatically.
The text below shows what has been done so far.

The work is not a prototype, but rather indicates the possibility of 
achieving a result.
Therefore, I deliberately simplify the development context of the Converter 
where it was 
possible. 

At first it seemed important to me that between Java and Go there is a 
difference 
between the implementation of the Dynamic Dispatching, more precisely, 
there is no 
Dynamic Dispatching in Go. The applied solution in the current 
implementation 
looks not only ugly but even violates the several very important rules of 
the OO design, 
I'm not kidding here. But this option looks like that it will be working. 

Onward I will provide the 4 code samples in Java, followed by the 
automatically 
generated Golang code and comments as needed. 

*1. Of course, I started with the most popular program: "Hello World".*

package main;

public class HelloWorld {
  public static void main(  String[] args){
System.out.println("Hello World");
  }
}

*Converter gave out:*

package main

import (
"fmt"
"os"
)

type HelloWorld struct{}

func main() {

var args []string = os.Args

var hw HelloWorld = HelloWorld{}
hw.HelloWorld_main(args)
}

/** generated method **/
func (helloWorld *HelloWorld) HelloWorld_main(args []string) {
fmt.Println("Hello World")
}

*2. Next, it was interesting to deal with the problem of a simple 
inheritance.*

package main;

public class TestInheritance {
  public static void main(  String[] args){
Inheritance inh=null;
inh=new Second();
inh.hello();
inh=new Third();
inh.hello();
  }
}
public interface Inheritance {
  public void hello();
}
class Second implements Inheritance {
  public void hello(){
System.out.println("Second");
  }
}
class Third implements Inheritance {
  public void hello(){
System.out.println("Third");
  }
}
 
*Converter gave out:*

package main

import (
"fmt"
"os"
)

type TestInheritance struct{}

func main() {

var args []string = os.Args

var ti TestInheritance = TestInheritance{}
ti.TestInheritance_main(args)
}

/** generated method **/
func (testInheritance *TestInheritance) TestInheritance_main(args []string) 
{

var inh Inheritance
inh = AddressSecond(Second{})
inh.hello()
inh = AddressThird(Third{})
inh.hello()
}

type Inheritance interface {
hello()
}
type Second struct{}

func (second *Second) hello() {
fmt.Println("Second")
}

type Third struct{}

func (third *Third) hello() {
fmt.Println("Third")
}

func AddressSecond(s Second) *Second { return  }
func AddressThird(t Third) *Third{ return  }


*3. In the following example, it is necessary to correctly definea 
common interface for the inheritance tree.*

package no.packeges;

public class TestExtension {
  public static void main(  String[] args){
TestExtension te=new TestExtension();
te.hello();
te=new Second();
te.hello();
te=new Third();
te.hello();
te=new Fourth();
te.hello();
  }
  public void hello(){
System.out.println("hello");
  }
}
class Second extends TestExtension {
  public void hello(){
System.out.println("Second");
  }
}
class Third extends TestExtension {
  public void hello(){
System.out.println("Third");
  }
}
class Fourth extends Third {
  public void hello(){
System.out.println("Fourth");
  }
}

*Converter gave out:*

package main

import (
"fmt"
"os"
)

type TestExtension struct{}

func main() {

var args []string = os.Args

var te TestExtension = TestExtension{}
te.TestExtension_main(args)
}
func (testExtension *TestExtension) hello() {
fmt.Println("hello")
}

/** generated method **/
func (testExtension *TestExtension) TestExtension_main(args []string) {

var te ITestExtension = AddressTestExtension(TestExtension{})
te.hello()
te = AddressSecond(Second{})
te.hello()
te = AddressThird(Third{})
te.hello()
te = AddressFourth(Fourth{})
te.hello()
}

type Second struct {
TestExtension
}

func (second *Second) hello() {
fmt.Println("Second")
}

type Third struct {
TestExtension
}

func (third *Third) hello() {
fmt.Println("Third")
}

type Fourth struct {
Third
}

func (fourth *Fourth) hello() {
fmt.Println("Fourth")
}

type ITestExtension interface { 
/** Generated Method */
hello()
}

func AddressSecond(s Second) *Second  { return  }
func AddressThird(t Third) *Third { return  }
func AddressTestExtension(t TestExtension) *TestExtension { return  }
func AddressFourth(f Fourth) *Fourth  { return  }





*4. Now the Dynamic Dispatching 

Re: [go-nuts] IsNil check. How?

[Alex Besogonov]

> The reflect code panics, because you are comparing a struct value to nil. 
>> Struct values can not be nil.
>>
>> No. I’m comparing AN INTERFACE, not a struct.
>>
> You are using `reflect` to inspect the dynamic value of that interface. 
> That dynamic value is a struct.
>
No. It should be a POINTER to a struct, which would have been fine. Instead 
Go's reflection incorrectly latches on the type of the embedding structure.
 

> The interface’s provenance is _through_ a struct that has an embedded 
>> pointer, but this should not matter to the code that accepts the interface.
>>
> I completely agree with this. That's why it is so important not to store 
> invalid values in an interface. The code using that interface has no 
> reasonable way to check if the value is valid. So it has to rely on the 
> caller to only provide valid implementations.
>
The code is NOT using anything incorrect. The interface is obtained through 
a pointer to a struct, which is completely valid. The only problem is that 
this pointer is embedded inside a struct.

If you rewrite the code to use a named field, it would work. This means 
that the language behaves differently depending on a field having a name.
 
>
> But really, the solution here is not to "check better". It's to not store 
> invalid implementations of an interface in the interface. 
>
> I gave you the real example, somewhat simplified.
>
Then this is the real example with the fix applied: 
> https://go.dev/play/p/04H1KenHjRV
>
The real example would look like this:  https://go.dev/play/p/mwUfh4_RBUU - 
you do see why it's a tad problematic?

-- 
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/58d5770b-4888-4980-8f9e-c96310d57490n%40googlegroups.com.

Re: [go-nuts] IsNil check. How?

[Alex Besogonov]

> Here's a simplified version of the real code: 
> https://go.dev/play/p/8LfgIGhd8GR  - it 
> compiles without any issues.
> 
> Yes it compiles. Plenty of buggy Go code will compile. Here is another 
> example  of buggy interface-based code 
> which compiles just fine. We can't prevent users from writing buggy code.
This is not a buggy code. This is a buggy language spec.

> It seems in this case, the bug is storing such a value in that interface. The 
> solution is to not do that.
No. The bug is in Go’s spec that treats values and pointers differently when 
coercing values to an interface type.

> Note that in your case, the dynamic value of that interface is not nil. It's 
> a struct value. Structs can not be nil.
Incorrect. Go language allows coercing a struct with an embedded pointer to an 
interface. Spec:
"If S contains an embedded field *T, the method sets of S and *S both include 
promoted methods with receiver T or *T."

> Except that you can not. In my case I have an interface that has the nil data 
> part, and the program crashes because the reflect code doesn't know that I'm 
> accessing the interface.
> The reflect code panics, because you are comparing a struct value to nil. 
> Struct values can not be nil.
No. I’m comparing AN INTERFACE, not a struct. The interface’s provenance is 
_through_ a struct that has an embedded pointer, but this should not matter to 
the code that accepts the interface.

Would you argue that these statements should behave differently: '1 + 1 == 2’ 
and ‘2 == 2’? Because you argue that ‘1 + 1’ is not ‘2’ and should not work 
this way.

> Again, just write different reflect code then.
Which? Go seems to be losing the type of the variable. It’s not possible to say 
“get me a value as THIS interface type”.

> Reflect gives you the capability to write any dynamic check you want. If you 
> want to check that an embedded pointer field is not-nil, then write the 
> reflect code to check for that. I don't really understand what you are trying 
> to check. But you can implement whatever heuristic you want, using reflect.
I’m trying to check that a freaking interface pointer part is nil. That’s it.

> But really, the solution here is not to "check better". It's to not store 
> invalid implementations of an interface in the interface.
I gave you the real example, somewhat simplified.

> There *are* valid uses for this check - json.Unmarshal is one such. But those 
> cases need reflection anyway. So reflect is a far more sensible and flexible 
> way for programmers to implement whatever check they need, than changing the 
> language.
OK. How do I make this check using reflection? I can’t find a way to do it. The 
only way is to use `unsafe` to manually hack into the low-level interface  
representation to extract the pointer part.

> You can check my example, if you remove the nil check and use non-nil 
> parameters, it would work just fine.
> Okay. Then it seems you have your solution - "remove the nil check and use 
> non-nil parameters”.
Not feasible. It would require huge amounts of code in call sites.

-- 
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/C90A489D-F7C7-435F-AD23-42535CBC4CEC%40gmail.com.

Re: [go-nuts] IsNil check. How?

[Alex Besogonov]

On Wednesday, March 16, 2022 at 12:29:07 PM UTC-7 axel.wa...@googlemail.com 
wrote:

> On Wed, Mar 16, 2022 at 7:02 PM Alex Besogonov  
> wrote:
>
>> Nope. Your solution doesn't work either: 
>> https://go.dev/play/p/DSik2kJ-gg4 (it doesn't crash, just falsely 
>> returns 'false').
>>
> That's your original code. I assume, though, you are trying to demonstrate 
> that this doesn't return `true` when passed a nil-slice/func/chan/map. 
> That's by design - the function does what it is designed to do, check if an 
> interface value contains a nil-pointer. If you want something else, write a 
> different function.
>
I don't believe that's true. The function is passed an interface (Tester) 
that has a nil pointer part but a non-nil type. That type also happens to 
be a struct with an embedded pointer to another struct that implements the 
interface.

Here's a simplified version of the real code: 
https://go.dev/play/p/8LfgIGhd8GR - it compiles without any issues.
  

> What I'm trying to check is pretty straightforward: do I get the nil value 
>> passed to a function.
>>
>
> The way to check that is `return v == nil`. What you seem to be interested 
> in is "I want to write a function which checks if the dynamic type of a 
> function is a pointer, slice, channel, function or map type and if so, 
> returns if the dynamic value is nil". You can write that easily enough 
> <https://go.dev/play/p/X_pHOrxxago>.
>
Except that you can not. In my case I have an interface that has the nil 
data part, and the program crashes because the reflect code doesn't know 
that I'm accessing the interface.

You can check my example, if you remove the nil check and use non-nil 
parameters, it would work just fine.

-- 
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/70a80a76-44b5-4af3-9eb5-2d8794e4d3c4n%40googlegroups.com.

Re: [go-nuts] IsNil check. How?

[Alex Besogonov]

Nope. Your solution doesn't work either: https://go.dev/play/p/DSik2kJ-gg4 
(it doesn't crash, just falsely returns 'false').

What I'm trying to check is pretty straightforward: do I get the nil value 
passed to a function. All types are completely valid, the structure is 
correctly cast to the base interface type and its methods can be safely 
called: https://go.dev/play/p/xseNiCSB0uA

I don't see anything "uninteresting" in that. In a real program the 
interface is simply passed through an intermediate function, so I can't use 
an exact type.

That's a stupid part of the language and there's no good justification why 
this hasn't been yet fixed.
On Wednesday, March 16, 2022 at 10:36:48 AM UTC-7 axel.wa...@googlemail.com 
wrote:

> On Wed, Mar 16, 2022 at 6:21 PM Alex Besogonov  
> wrote:
>
>> I'm trying to solve the eternal "interface == nil" problem and I can't 
>> find a solution in this case: https://go.dev/play/p/DSik2kJ-gg4
>>
>
> ISTM that you are discovering why this check just is not an interesting 
> check to make in the first place. 
>
> There is no meaning you can assign to "is the dynamic value of a non-nil 
> interface nil", as `nil` might not even be a valid value for its dynamic 
> type. It's also not a *helpful* check, because even non-nil pointers can 
> cause a panic, if you call an associated method on them.
>
> You *can* write a check to see if a value contains a pointer relatively 
> easily using reflect:
> https://go.dev/play/p/dDHp7KnoHHS
> But it's not a very useful check, unless you specifically want to work 
> further with the pointer using reflect (e.g. how json.Unmarshal stores a 
> value in a pointer).
>  
>
>>
>> It looks like casting to the base pointer type confuses the reflection 
>> package. Is there a way to solve this?
>>
>> PS: PLEASE do add "nilptr" to the language proper.
>>
>> -- 
>> 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 
>> https://groups.google.com/d/msgid/golang-nuts/469b88b2-6d64-4bcd-8b92-18f9781c4fd3n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/469b88b2-6d64-4bcd-8b92-18f9781c4fd3n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/75f9517f-c6ea-4a93-8c88-d1293b5c8c0en%40googlegroups.com.

[go-nuts] IsNil check. How?

[Alex Besogonov]

Hi!

I'm trying to solve the eternal "interface == nil" problem and I can't find 
a solution in this case: https://go.dev/play/p/DSik2kJ-gg4

It looks like casting to the base pointer type confuses the reflection 
package. Is there a way to solve this?

PS: PLEASE do add "nilptr" to the language proper.

-- 
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/469b88b2-6d64-4bcd-8b92-18f9781c4fd3n%40googlegroups.com.

[go-nuts] Fuzz Testing in Go 1.18

[Alex Pliutau]

Hi,

I recently made a video on fuzzing support in Go 1.18. I'd like to hear 
your feedback if that's possible - https://youtu.be/w8STTZWdG9Y

Best,
Alex

-- 
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/847eaccd-a2f3-4f90-a022-2893afa6a770n%40googlegroups.com.

[go-nuts] Go 1.18 Beta 2 is released

[Alex Rakoczy]

Hello gophers,

We have just released go1.18beta2, a beta version of Go 1.18.
It is cut from the master branch at the revision tagged go1.18beta2.

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://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.18beta2
is by using the go command:
$ go get golang.org/dl/go1.18beta2
$ go1.18beta2 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.18beta2

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

Cheers,
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/CA%2BxaJdSwm5kJXW9eaw0eqvcjFqfFv1G9mN%2BmgDP_yLmX5b4wKw%40mail.gmail.com.

[go-nuts] Jobs

[Alex Dvoretskiy]

What is a good way to find Go developers and Go jobs nowadays?

-- 
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/a70ed635-0af5-46f6-9d02-3b7f9737fe8cn%40googlegroups.com.

[go-nuts] Re: Java to Golang converter

[alex-coder]

The topic is very interesting, is anyone being worked on a subject ?
Thank you.

четверг, 11 мая 2017 г. в 21:19:13 UTC+3, dtr...@gmail.com: 

>
> Java has vast number of libraries.
>
> Good thing is Golang is catching up with its own style.
>
> There are cases though where there is no equivalent libraries ( PDF 
> reading / writing, TIFF reading writing, Office File formats)
>
> There were a few attempts for Java to Go conversions but not complete (if 
> ever can be complete).
>
> github.com/dglo/java2go (converter but not with UTF-8 capabilities)
>
> https://github.com/timob/javaparser (java parser)
>
> github.com/tinycedar/class-parser  (java class parser)
>
> github.com/tinylcy/SmallVM (Java VM interpreter)
>
> github.com/tinycedar/vanilla
>
> All of these projects show the need to read from Java.
>
> Is there any other project or effort to map java functions --> go or even 
> a decent converter?
>
> Any plans to make a decent converter from somebody?
>
>
>

-- 
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/626dd8a3-9014-4dbc-b0df-24407de7198en%40googlegroups.com.

[go-nuts] [security] Go 1.17.5 and Go 1.16.12 are released

[Alex Rakoczy]

Hello gophers,

We have just released Go versions 1.17.5 and 1.16.12, minor point releases.

These minor releases include two security fixes following the security
policy <https://go.dev/security>:

   - net/http: limit growth of header canonicalization cache

   An attacker can cause unbounded memory growth in a Go server accepting
   HTTP/2 requests.

For users who cannot immediately update to the new release, setting the
GODEBUG=http2server=0 environment variable before calling Serve will
disable HTTP/2 unless it was manually configured through the
golang.org/x/net/http2 package.

This issue is also fixed in golang.org/x/net/http2
v0.0.0-20211209124913-491a49abca63, for users manually configuring HTTP/2.

Thank you to murakmii for reporting this issue.

This is CVE-2021-44716 and Go issue go.dev/issue/50058.


   - syscall: don’t close fd 0 on ForkExec error

   When a Go program running on a Unix system is out of file descriptors
   and calls syscall.ForkExec (including indirectly by using the os/exec
   package), syscall.ForkExec can close file descriptor 0 as it fails. If this
   happens (or can be provoked) repeatedly, it can result in misdirected I/O
   such as writing network traffic intended for one connection to a different
   connection, or content intended for one file to a different one.

   For users who cannot immediately update to the new release, the bug can
   be mitigated by raising the per-process file descriptor limit.

   Thank you to Tomasz Maczukin and Kamil Trzciński of GitLab for reporting
   this issue.

   This is CVE-2021-44717 and Go issue go.dev/issue/50057.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.17.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.17.5" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Alex and Filippo 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/CA%2BxaJdSJpsFC4xQdPu%2B%2BMnjNyGR4RFGX_-w4R-pkAcTuu2x7jA%40mail.gmail.com.

Re: [go-nuts] UML && Golang, part 2 ?

[alex-coder]

After all, I found that plantuml is more suitable for code visualization. 
If anyone is interested, you will find it there: https://plantuml.com/

Thank all for participation.

суббота, 13 ноября 2021 г. в 19:43:20 UTC+3, alex-coder: 

> Satyendra,
> >> https://github.com/ofabry/go-callvis
>
> very interesting, but looks like a little bit out of date.
>
> Thank you.
>
>
> воскресенье, 4 июля 2021 г. в 18:57:46 UTC+3, satyendra...@gmail.com: 
>
>> Alex you can try this.
>>
>> https://github.com/ofabry/go-callvis
>>
>> Thanks and regards,
>> Satyendra
>>
>> On Sun, Jul 4, 2021, 9:15 PM alex-coder  wrote:
>>
>>> Well, if there is a complex or not very complex system written in a 
>>> programming language,
>>> using uml helps faster understand both the system and the dependencies 
>>> and constractions in the code. 
>>> Especially if the system is unfamiliar.
>>>
>>> Right ? :-)
>>>
>>> воскресенье, 4 июля 2021 г. в 14:27:29 UTC+3, Jan Mercl: 
>>>
>>>> On Sun, Jul 4, 2021 at 1:16 PM alex-coder  wrote: 
>>>>
>>>> > But what do you use instead then ? 
>>>>
>>>> For what? 
>>>>
>>>> In case it's not obvious, I never touched UML and I don't really 
>>>> understand its utility. So I'm asking an honest question. Knowing the 
>>>> answer might help to possibly provide some answer to your question. 
>>>>
>>> -- 
>>> 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 
>>> https://groups.google.com/d/msgid/golang-nuts/2f3b4c90-5180-4522-b29f-b8ca2ad4c492n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/2f3b4c90-5180-4522-b29f-b8ca2ad4c492n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/b4fc90df-40a8-486e-9dd6-bc29fdba3b22n%40googlegroups.com.

Re: [go-nuts] UML && Golang, part 2 ?

[alex-coder]

Satyendra,
>> https://github.com/ofabry/go-callvis

very interesting, but looks like a little bit out of date.

Thank you.


воскресенье, 4 июля 2021 г. в 18:57:46 UTC+3, satyendra...@gmail.com: 

> Alex you can try this.
>
> https://github.com/ofabry/go-callvis
>
> Thanks and regards,
> Satyendra
>
> On Sun, Jul 4, 2021, 9:15 PM alex-coder  wrote:
>
>> Well, if there is a complex or not very complex system written in a 
>> programming language,
>> using uml helps faster understand both the system and the dependencies 
>> and constractions in the code. 
>> Especially if the system is unfamiliar.
>>
>> Right ? :-)
>>
>> воскресенье, 4 июля 2021 г. в 14:27:29 UTC+3, Jan Mercl: 
>>
>>> On Sun, Jul 4, 2021 at 1:16 PM alex-coder  wrote: 
>>>
>>> > But what do you use instead then ? 
>>>
>>> For what? 
>>>
>>> In case it's not obvious, I never touched UML and I don't really 
>>> understand its utility. So I'm asking an honest question. Knowing the 
>>> answer might help to possibly provide some answer to your question. 
>>>
>> -- 
>> 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 
>> https://groups.google.com/d/msgid/golang-nuts/2f3b4c90-5180-4522-b29f-b8ca2ad4c492n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/2f3b4c90-5180-4522-b29f-b8ca2ad4c492n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/446d6d1e-8847-4fcf-a354-9351129eb804n%40googlegroups.com.

Re: [go-nuts] ast.NewPackage errors for built in types

[K. Alex Mills]

I'm guessing here, but you probably do need the full type-checker for that,
depending on what you mean by "a native type".

In go we can alias types in two ways.

type A uint8
type B = uint8

There are subtle differences between the two which I don't claim to
understand... In any case, AFAIK both are essentially built-in types at
runtime.

Suppose these types are declared in a third-party package on GitHub and
another package uses A and B (since they're exported) to declare a struct
like this.

import "github.com/foo/bar"

type MyStruct struct {
  Byte1 bar.A
  Byte2 bar.B
}

AFAIK, the compiler cannot tell whether Byte1 and Byte2 are builtin types
or a struct without seeing their definition hosted on GitHub. Which means
downloading, parsing, and type-checking the code from GitHub.

But it gets a little worse. Type-checking the remote code entails
downloading any of its dependencies recursively and doing the same thing...
I'm sure you can see how this can take some time -- especially for large
projects.

Anyway, it sounds to me like what you're asking to do requires the use of
the type-checker and because of the dependency management involved I
believe the most convenient route to type-checking (at this time) lives in
the packages package.

Happy to learn if anyone else knows otherwise.

On Sun, Oct 17, 2021, 5:00 AM Steven Hartland 
wrote:

> I need to be able to tell the types of fields, in particular are fields of
> a struct a native type or a struct themselves.
>
> The ast parse even with a simple importer don’t provide that info.
>
> On Sat, 16 Oct 2021 at 21:06, 'Richard Oudkerk' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> I am not sure what "import external packages" means.
>>
>> Apart dot imports (which I have never seen used for real) why would you
>> need to load the imported packages?
>>
>> On Saturday, 16 October 2021 at 20:34:17 UTC+1 Steven Hartland wrote:
>>
>>> Thanks Richard, that allowed me to replace a hand rolled
>>> universe scope 
>>>
>>> My importer varies from yours in that for correct lookups for versioned
>>> packages or those with '-' in I had to copy ImportPathToAssumedName
>>> from x/tools/internal/imports/fix.go.
>>>
>>> func simpleImporter(imports map[string]*ast.Object, path string)
>>> (*ast.Object, error) {
>>> pkg := imports[path]
>>> if pkg == nil {
>>> pkg = ast.NewObj(ast.Pkg, ImportPathToAssumedName(path))
>>> pkg.Data = ast.NewScope(nil) // required by
>>> ast.NewPackage for dot-import
>>> imports[path] = pkg
>>> }
>>> return pkg, nil
>>> }
>>>
>>> This now works for all cases which don't import external packages. So
>>> now I just need to do the on demand load of packages, which I suspect will
>>> lead me right back to packages.Load.
>>>
>>> On Sat, 16 Oct 2021 at 15:59, 'Richard Oudkerk' via golang-nuts <
>>> golan...@googlegroups.com> wrote:
>>>
 You could try building the universe scope for ast.NewPackage from
 types.Universe.  For example

 https://play.golang.org/p/1E5Iu4vW3g9

 func NewPackage(fset *token.FileSet, files map[string]*ast.File)
 (*ast.Package, error) {
 univ, err := universe()
 if err != nil {
 return nil, err
 }
 return ast.NewPackage(fset, files, dummyImporter, univ)
 }

 func dummyImporter(imports map[string]*ast.Object, importPath string)
 (*ast.Object, error) {
 pkg := imports[importPath]
 if pkg == nil {
 pkg = ast.NewObj(ast.Pkg, path.Base(importPath))
 pkg.Data = ast.NewScope(nil)
 imports[importPath] = pkg
 }
 return pkg, nil
 }

 func universe() (*ast.Scope, error) {
 u := ast.NewScope(nil)
 for _, name := range types.Universe.Names() {
 o := types.Universe.Lookup(name)
 if o == nil {
 return nil, fmt.Errorf("failed to lookup %s in universe scope", name)
 }
 var objKind ast.ObjKind
 switch o.(type) {
 case *types.Const, *types.Nil:
 objKind = ast.Con
 case *types.TypeName:
 objKind = ast.Typ
 case *types.Builtin:
 objKind = ast.Fun
 default:
 return nil, fmt.Errorf("unexpected builtin %s of type %T", o.Name(), o)
 }
 obj := ast.NewObj(objKind, name)
 if u.Insert(obj) != nil {
 return nil, fmt.Errorf("types internal error: double declaration")
 }
 obj.Decl = u
 }
 return u, nil
 }

 On Saturday, 16 October 2021 at 14:38:43 UTC+1 eli...@gmail.com wrote:

> On Fri, Oct 15, 2021 at 2:13 PM Steven Hartland <
> ste...@multiplay.co.uk> wrote:
>
>> I converted my code to x/tools/go/packages
>>  and while
>> it did solve the problem it's VERY slow in comparison.
>>
>> I have a set of 21 tests operating on a single package which has at
>> most two very basic types, no imports and using go/parser
>>  they take 

Re: [go-nuts] ast.NewPackage errors for built in types

[K. Alex Mills]

FWIW: I'm not surprised that it's slower because it's handling
significantly more of the compilation. The parser is very fast. Adding in
type-checking is going to be less fast.

IIRC, the packages package also has to make network calls and do filesystem
I/O behind the scenes in some cases. The parser doesn't have to do anything
more than parse the code and output the AST.

It could certainly be the case that the packages library is more than you
need. Without understanding more about your use-case it will be hard to say
for sure.

On Fri, Oct 15, 2021, 4:13 PM Steven Hartland 
wrote:

> I converted my code to x/tools/go/packages
>  and while it
> did solve the problem it's VERY slow in comparison.
>
> I have a set of 21 tests operating on a single package which has at most
> two very basic types, no imports and using go/parser
>  they take 0.011s but with go/packages
>  that increases
> to 3.548s a 300x slow down.
>

> I'm setting a basic mode: packages.NeedName | packages.NeedSyntax
>
> The package.Load call takes ~220ms whereas ast.NewPackage only takes 2.7µs.
>
> As the resulting ast.File's are pretty much the same, I'm wondering if for
> my use case packages.Load is doing way more than I need?
>
> Another downside is for tests run in a temporary directory outside of the
> package space package.Load fails with:
> directory /tmp/tests76985775 outside available modules
>
> I fixed it by calling ioutil.TempDir with "." but that's not ideal.
>
> Thoughts?
>
> On Tue, 12 Oct 2021 at 13:42, Steven Hartland 
> wrote:
>
>> Thanks David, much appreciated, I will have a look at both.
>>
>> When migrating from go/ast to go/types did you hit anything of note I
>> should look out for?
>>
>> On Mon, 11 Oct 2021 at 17:06, David Finkel 
>> wrote:
>>
>>>
>>>
>>> On Mon, Oct 11, 2021 at 5:48 AM Steven Hartland 
>>> wrote:
>>>
 If the ast.Files passed to ast.NewPackage includes built in types such
 as int it returns an error e.g.
 file1.go:5:6: undeclared name: int

 Is there a way to prevent that?

>>>
>>> Generally, I always add the `builtin` package to the list of packages
>>> I'm parsing.
>>> I wrote a little library for exactly this kind of package loading a few
>>> years ago:
>>> https://gitlab.com/dfinkel/goastpkg/-/blob/master/go_ast_parser.go
>>> (https://pkg.go.dev/golang.spin-2.net/astpkg)
>>>

 Playground example: https://play.golang.org/p/Yg30TTzoLHP

 My goal is to take multiple files, resolve inter file dependencies e.g.
 a type referencing another type in a different file and process the
 resulting ast.Files. So if there is a better way to achieve this I'm all
 ears.

>>>
>>> In general, I've stopped using the `go/ast` internal references as much
>>> and have started using resolved `go/types` references as they're more
>>> reliable and better-specified.
>>> (golang.org/x/tools/go/packages
>>>  has a
>>> LoadMode flag for generating `go/types.Info` (NeedTypesInfo
>>> 
>>> ))
>>>

Regards
Steve

 --
 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/CAHEMsqbJoJxuo3c-mofMtzXXJhYCzV2skW2ZB3ZPY6WtA8%2BxHw%40mail.gmail.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/CAHEMsqYMSBUfuOUvptv6UrvBFTwFxjOhJZ5sMN-omOx5ESL5hw%40mail.gmail.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/CALJzkY-prCAwkqeWXxuGCZaEYQ4%2B7QukUWbqG0VzGpKF71F%2BFw%40mail.gmail.com.

Re: [go-nuts] ast.NewPackage errors for built in types

[K. Alex Mills]

It's been several months since I used these packages but IIRC, go/ast only
requires code to parse correctly, while go/types actually runs the
type-checker.

Running the type checker implies having a complete picture of all the types
used in a Go program, which, in my recollection, usually means reaching out
to download third-party dependencies if they aren't already available.

That can be a bit much in my experience, but there's no way around it
because of how Go's type system works.

On Tue, Oct 12, 2021, 7:42 AM Steven Hartland 
wrote:

> Thanks David, much appreciated, I will have a look at both.
>
> When migrating from go/ast to go/types did you hit anything of note I
> should look out for?
>
> On Mon, 11 Oct 2021 at 17:06, David Finkel  wrote:
>
>>
>>
>> On Mon, Oct 11, 2021 at 5:48 AM Steven Hartland 
>> wrote:
>>
>>> If the ast.Files passed to ast.NewPackage includes built in types such
>>> as int it returns an error e.g.
>>> file1.go:5:6: undeclared name: int
>>>
>>> Is there a way to prevent that?
>>>
>>
>> Generally, I always add the `builtin` package to the list of packages I'm
>> parsing.
>> I wrote a little library for exactly this kind of package loading a few
>> years ago:
>> https://gitlab.com/dfinkel/goastpkg/-/blob/master/go_ast_parser.go
>> (https://pkg.go.dev/golang.spin-2.net/astpkg)
>>
>>>
>>> Playground example: https://play.golang.org/p/Yg30TTzoLHP
>>>
>>> My goal is to take multiple files, resolve inter file dependencies e.g.
>>> a type referencing another type in a different file and process the
>>> resulting ast.Files. So if there is a better way to achieve this I'm all
>>> ears.
>>>
>>
>> In general, I've stopped using the `go/ast` internal references as much
>> and have started using resolved `go/types` references as they're more
>> reliable and better-specified.
>> (golang.org/x/tools/go/packages
>>  has a
>> LoadMode flag for generating `go/types.Info` (NeedTypesInfo
>> 
>> ))
>>
>>>
>>>Regards
>>>Steve
>>>
>>> --
>>> 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/CAHEMsqbJoJxuo3c-mofMtzXXJhYCzV2skW2ZB3ZPY6WtA8%2BxHw%40mail.gmail.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/CAHEMsqavYgUqPOBo6zB5SsizVB39JO9vNUePnecDN-664e0NUQ%40mail.gmail.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/CALJzkY82V19XgZS_31-16BYAFU7NRF3tTbjisVS8dvMHd8d6Pg%40mail.gmail.com.

[go-nuts] [ANN] Pure Go NFSv4 client

[Alex Besogonov]

Hi!

Here's my pure Go NFSv4 client. It's designed to work with Amazon EFS 
(Elastic FileSystem) but also can work against Linux kNFSD or Ganesha (in 
fact, Ganesha is used for integration testing).

Enjoy: https://github.com/Cyberax/go-nfs-client

-- 
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/5cd43d10-011f-4df4-a76b-c37144ef0793n%40googlegroups.com.

[go-nuts] Re: question about Profiling Go Programs sample.

[alex-coder]

Vladimir, one more question.
Does it mean that it is impossible to display recursive call in web by use 
pprof, it is necessary to use some additional tool, right ?

четверг, 30 сентября 2021 г. в 11:38:49 UTC+3, alex-coder: 

> a little bit more resources:
> golang pprof 实战 | Wolfogre's Blog 
> <https://blog.wolfogre.com/posts/go-ppof-practice/>
> it seems to be in Chinese (I may be wrong), but thanks to google.
> четверг, 30 сентября 2021 г. в 09:55:17 UTC+3, alex-coder: 
>
>> Hi
>> >>I think this is expected
>> you are experienced.
>>
>> >> Depending on what you're looking for,
>> firstly, I want to learn how to use pprof properly and secondly, 
>> I even could not imagine that it is not my mistake or not using tool 
>> properly..
>>
>>
>> thank you so much.:-)
>> среда, 29 сентября 2021 г. в 21:55:20 UTC+3, vlad...@varank.in: 
>>
>>> Hey there,
>>>
>>> > I took  runtime/cpuprof.go with  version 1.4, where cpuprof.go just 
>>> appeared with the same result. :-)
>>>
>>> I think this is expected.
>>> Go 1.4 was released in 2014 — several years after the original post 
>>> about pprof, had been published. In fact, Go 1.4 is the version where the 
>>> relevant part of the runtime's profiler was migrated from C to Go. In this 
>>> version the same constant, I pointed earlier, already presented in this 
>>> source code (note maxCPUProfStack=64).
>>>
>>> > Vladimir, is there any resource to read about current and probably 
>>> future of the go profiling?
>>>
>>> Depending on what you're looking for, there are quite a few materials I 
>>> could recommend:
>>> - the documentation for runtime/pprof and net/http/pprof packages [1]
>>> - the documentation for google/pprof tool [2]
>>> - Go wiki on performance [3]
>>> - Felix Geisendörfer's (DataDog) notes on Go profiling internals [4] (he 
>>> also gave several talks about the topic last summer).
>>>
>>> Hope that could help.
>>>
>>> [1]: https://pkg.go.dev/runtime/pprof, https://pkg.go.dev/net/http/pprof
>>> [2]: https://github.com/google/pprof/tree/master/doc
>>> [3]: https://github.com/golang/go/wiki/Performance
>>> [4]: https://github.com/DataDog/go-profiler-notes
>>> On Wednesday, September 29, 2021 at 1:59:10 PM UTC+2 alex-coder wrote:
>>>
>>>> Vladimir,
>>>>
>>>> I took  runtime 
>>>> <https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/> 
>>>> <https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/>/
>>>> cpuprof.go 
>>>> <https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/cpuprof.go>
>>>>  with  version 
>>>> 1.4, where cpuprof.go just appeared with the same result. :-)
>>>> it should be something else.
>>>>
>>>> Regards.
>>>>
>>>> вторник, 28 сентября 2021 г. в 11:31:55 UTC+3, alex-coder: 
>>>>
>>>>> Ok, thank you.
>>>>> Vladimir, is there any resource to read about current and probably 
>>>>> future of the go profiling ?
>>>>> In fact it is not only very important but and very, very interesting.
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>> вторник, 28 сентября 2021 г. в 06:38:31 UTC+3, vlad...@varank.in: 
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I suspect this is due to how the current version of Go runtime's CPU 
>>>>>> profiler keeps only up to 64 items, when it builds the function's stack 
>>>>>> frame (refer to 
>>>>>> https://github.com/golang/go/blob/go1.17/src/runtime/cpuprof.go#L21) 
>>>>>> With that, the resulting profile misses the relationship between 
>>>>>> main.DFS 
>>>>>> and its parent function, thus it "hangs" beneath the root node now.
>>>>>>
>>>>>> Keep in mind that the original post is almost 10 year old now. Some 
>>>>>> other details might have changed as well.
>>>>>>
>>>>>> Cheers,
>>>>>> V.
>>>>>>
>>>>>> On Monday, September 27, 2021 at 11:03:53 AM UTC+2 alex-coder wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> currently I walk through sample given there:
>>>>>>> Profiling Go Programs - go.dev <https://go.dev/blog/pprof>
>>>>>>>
>>>>>>> but when I came at the point where the user should enter web command 
>>>>>>> to the pprof
>>>>>>> I do not see that the function DFS call itself on a picture.
>>>>>>> Looks like I do use a proper version of the sample - go_pro, where 
>>>>>>> the recursion is present:
>>>>>>> multi-language-bench/src/havlak/go_pro at master · 
>>>>>>> hundt98847/multi-language-bench · GitHub 
>>>>>>> <https://github.com/hundt98847/multi-language-bench/tree/master/src/havlak/go_pro>
>>>>>>>
>>>>>>> So, what could be the reason that the picture is painted not 
>>>>>>> properly ?
>>>>>>>
>>>>>>> I use 1.17.1, windows 10.
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>>

-- 
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/6a418a3f-aaa8-4f8a-917a-89ef4d9b0360n%40googlegroups.com.

[go-nuts] Re: question about Profiling Go Programs sample.

[alex-coder]

a little bit more resources:
golang pprof 实战 | Wolfogre's Blog 
<https://blog.wolfogre.com/posts/go-ppof-practice/>
it seems to be in Chinese (I may be wrong), but thanks to google.
четверг, 30 сентября 2021 г. в 09:55:17 UTC+3, alex-coder: 

> Hi
> >>I think this is expected
> you are experienced.
>
> >> Depending on what you're looking for,
> firstly, I want to learn how to use pprof properly and secondly, 
> I even could not imagine that it is not my mistake or not using tool 
> properly..
>
>
> thank you so much.:-)
> среда, 29 сентября 2021 г. в 21:55:20 UTC+3, vlad...@varank.in: 
>
>> Hey there,
>>
>> > I took  runtime/cpuprof.go with  version 1.4, where cpuprof.go just 
>> appeared with the same result. :-)
>>
>> I think this is expected.
>> Go 1.4 was released in 2014 — several years after the original post about 
>> pprof, had been published. In fact, Go 1.4 is the version where the 
>> relevant part of the runtime's profiler was migrated from C to Go. In this 
>> version the same constant, I pointed earlier, already presented in this 
>> source code (note maxCPUProfStack=64).
>>
>> > Vladimir, is there any resource to read about current and probably 
>> future of the go profiling?
>>
>> Depending on what you're looking for, there are quite a few materials I 
>> could recommend:
>> - the documentation for runtime/pprof and net/http/pprof packages [1]
>> - the documentation for google/pprof tool [2]
>> - Go wiki on performance [3]
>> - Felix Geisendörfer's (DataDog) notes on Go profiling internals [4] (he 
>> also gave several talks about the topic last summer).
>>
>> Hope that could help.
>>
>> [1]: https://pkg.go.dev/runtime/pprof, https://pkg.go.dev/net/http/pprof
>> [2]: https://github.com/google/pprof/tree/master/doc
>> [3]: https://github.com/golang/go/wiki/Performance
>> [4]: https://github.com/DataDog/go-profiler-notes
>> On Wednesday, September 29, 2021 at 1:59:10 PM UTC+2 alex-coder wrote:
>>
>>> Vladimir,
>>>
>>> I took  runtime 
>>> <https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/> 
>>> <https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/>/
>>> cpuprof.go 
>>> <https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/cpuprof.go>
>>>  with  version 
>>> 1.4, where cpuprof.go just appeared with the same result. :-)
>>> it should be something else.
>>>
>>> Regards.
>>>
>>> вторник, 28 сентября 2021 г. в 11:31:55 UTC+3, alex-coder: 
>>>
>>>> Ok, thank you.
>>>> Vladimir, is there any resource to read about current and probably 
>>>> future of the go profiling ?
>>>> In fact it is not only very important but and very, very interesting.
>>>>
>>>> Thank you.
>>>>
>>>>
>>>> вторник, 28 сентября 2021 г. в 06:38:31 UTC+3, vlad...@varank.in: 
>>>>
>>>>> Hello,
>>>>>
>>>>> I suspect this is due to how the current version of Go runtime's CPU 
>>>>> profiler keeps only up to 64 items, when it builds the function's stack 
>>>>> frame (refer to 
>>>>> https://github.com/golang/go/blob/go1.17/src/runtime/cpuprof.go#L21) 
>>>>> With that, the resulting profile misses the relationship between main.DFS 
>>>>> and its parent function, thus it "hangs" beneath the root node now.
>>>>>
>>>>> Keep in mind that the original post is almost 10 year old now. Some 
>>>>> other details might have changed as well.
>>>>>
>>>>> Cheers,
>>>>> V.
>>>>>
>>>>> On Monday, September 27, 2021 at 11:03:53 AM UTC+2 alex-coder wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> currently I walk through sample given there:
>>>>>> Profiling Go Programs - go.dev <https://go.dev/blog/pprof>
>>>>>>
>>>>>> but when I came at the point where the user should enter web command 
>>>>>> to the pprof
>>>>>> I do not see that the function DFS call itself on a picture.
>>>>>> Looks like I do use a proper version of the sample - go_pro, where 
>>>>>> the recursion is present:
>>>>>> multi-language-bench/src/havlak/go_pro at master · 
>>>>>> hundt98847/multi-language-bench · GitHub 
>>>>>> <https://github.com/hundt98847/multi-language-bench/tree/master/src/havlak/go_pro>
>>>>>>
>>>>>> So, what could be the reason that the picture is painted not properly 
>>>>>> ?
>>>>>>
>>>>>> I use 1.17.1, windows 10.
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>>

-- 
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/bbb3129f-bfc4-401c-80dc-99c575889fe1n%40googlegroups.com.

[go-nuts] Re: question about Profiling Go Programs sample.

[alex-coder]

Hi
>>I think this is expected
you are experienced.

>> Depending on what you're looking for,
firstly, I want to learn how to use pprof properly and secondly, 
I even could not imagine that it is not my mistake or not using tool 
properly..


thank you so much.:-)
среда, 29 сентября 2021 г. в 21:55:20 UTC+3, vlad...@varank.in: 

> Hey there,
>
> > I took  runtime/cpuprof.go with  version 1.4, where cpuprof.go just 
> appeared with the same result. :-)
>
> I think this is expected.
> Go 1.4 was released in 2014 — several years after the original post about 
> pprof, had been published. In fact, Go 1.4 is the version where the 
> relevant part of the runtime's profiler was migrated from C to Go. In this 
> version the same constant, I pointed earlier, already presented in this 
> source code (note maxCPUProfStack=64).
>
> > Vladimir, is there any resource to read about current and probably 
> future of the go profiling?
>
> Depending on what you're looking for, there are quite a few materials I 
> could recommend:
> - the documentation for runtime/pprof and net/http/pprof packages [1]
> - the documentation for google/pprof tool [2]
> - Go wiki on performance [3]
> - Felix Geisendörfer's (DataDog) notes on Go profiling internals [4] (he 
> also gave several talks about the topic last summer).
>
> Hope that could help.
>
> [1]: https://pkg.go.dev/runtime/pprof, https://pkg.go.dev/net/http/pprof
> [2]: https://github.com/google/pprof/tree/master/doc
> [3]: https://github.com/golang/go/wiki/Performance
> [4]: https://github.com/DataDog/go-profiler-notes
> On Wednesday, September 29, 2021 at 1:59:10 PM UTC+2 alex-coder wrote:
>
>> Vladimir,
>>
>> I took  runtime 
>> <https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/> 
>> <https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/>/
>> cpuprof.go 
>> <https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/cpuprof.go>
>>  with  version 
>> 1.4, where cpuprof.go just appeared with the same result. :-)
>> it should be something else.
>>
>> Regards.
>>
>> вторник, 28 сентября 2021 г. в 11:31:55 UTC+3, alex-coder: 
>>
>>> Ok, thank you.
>>> Vladimir, is there any resource to read about current and probably 
>>> future of the go profiling ?
>>> In fact it is not only very important but and very, very interesting.
>>>
>>> Thank you.
>>>
>>>
>>> вторник, 28 сентября 2021 г. в 06:38:31 UTC+3, vlad...@varank.in: 
>>>
>>>> Hello,
>>>>
>>>> I suspect this is due to how the current version of Go runtime's CPU 
>>>> profiler keeps only up to 64 items, when it builds the function's stack 
>>>> frame (refer to 
>>>> https://github.com/golang/go/blob/go1.17/src/runtime/cpuprof.go#L21) 
>>>> With that, the resulting profile misses the relationship between main.DFS 
>>>> and its parent function, thus it "hangs" beneath the root node now.
>>>>
>>>> Keep in mind that the original post is almost 10 year old now. Some 
>>>> other details might have changed as well.
>>>>
>>>> Cheers,
>>>> V.
>>>>
>>>> On Monday, September 27, 2021 at 11:03:53 AM UTC+2 alex-coder wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> currently I walk through sample given there:
>>>>> Profiling Go Programs - go.dev <https://go.dev/blog/pprof>
>>>>>
>>>>> but when I came at the point where the user should enter web command 
>>>>> to the pprof
>>>>> I do not see that the function DFS call itself on a picture.
>>>>> Looks like I do use a proper version of the sample - go_pro, where the 
>>>>> recursion is present:
>>>>> multi-language-bench/src/havlak/go_pro at master · 
>>>>> hundt98847/multi-language-bench · GitHub 
>>>>> <https://github.com/hundt98847/multi-language-bench/tree/master/src/havlak/go_pro>
>>>>>
>>>>> So, what could be the reason that the picture is painted not properly ?
>>>>>
>>>>> I use 1.17.1, windows 10.
>>>>>
>>>>> Thank you.
>>>>>
>>>>>

-- 
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/01eacc8e-b5e3-4ab4-9052-94767cfd54dbn%40googlegroups.com.

[go-nuts] Re: question about Profiling Go Programs sample.

[alex-coder]

Vladimir,

I took  runtime 
<https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/> 
<https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/>/
cpuprof.go 
<https://cs.opensource.google/go/go/+/refs/tags/go1.4:src/runtime/cpuprof.go> 
with  version 
1.4, where cpuprof.go just appeared with the same result. :-)
it should be something else.

Regards.

вторник, 28 сентября 2021 г. в 11:31:55 UTC+3, alex-coder: 

> Ok, thank you.
> Vladimir, is there any resource to read about current and probably future 
> of the go profiling ?
> In fact it is not only very important but and very, very interesting.
>
> Thank you.
>
>
> вторник, 28 сентября 2021 г. в 06:38:31 UTC+3, vlad...@varank.in: 
>
>> Hello,
>>
>> I suspect this is due to how the current version of Go runtime's CPU 
>> profiler keeps only up to 64 items, when it builds the function's stack 
>> frame (refer to 
>> https://github.com/golang/go/blob/go1.17/src/runtime/cpuprof.go#L21) 
>> With that, the resulting profile misses the relationship between main.DFS 
>> and its parent function, thus it "hangs" beneath the root node now.
>>
>> Keep in mind that the original post is almost 10 year old now. Some other 
>> details might have changed as well.
>>
>> Cheers,
>> V.
>>
>> On Monday, September 27, 2021 at 11:03:53 AM UTC+2 alex-coder wrote:
>>
>>> Hi All,
>>>
>>> currently I walk through sample given there:
>>> Profiling Go Programs - go.dev <https://go.dev/blog/pprof>
>>>
>>> but when I came at the point where the user should enter web command to 
>>> the pprof
>>> I do not see that the function DFS call itself on a picture.
>>> Looks like I do use a proper version of the sample - go_pro, where the 
>>> recursion is present:
>>> multi-language-bench/src/havlak/go_pro at master · 
>>> hundt98847/multi-language-bench · GitHub 
>>> <https://github.com/hundt98847/multi-language-bench/tree/master/src/havlak/go_pro>
>>>
>>> So, what could be the reason that the picture is painted not properly ?
>>>
>>> I use 1.17.1, windows 10.
>>>
>>> Thank you.
>>>
>>>

-- 
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/83f33008-f35f-4642-855f-05d2e2ec016cn%40googlegroups.com.

[go-nuts] Re: question about Profiling Go Programs sample.

[alex-coder]

Ok, thank you.
Vladimir, is there any resource to read about current and probably future 
of the go profiling ?
In fact it is not only very important but and very, very interesting.

Thank you.


вторник, 28 сентября 2021 г. в 06:38:31 UTC+3, vlad...@varank.in: 

> Hello,
>
> I suspect this is due to how the current version of Go runtime's CPU 
> profiler keeps only up to 64 items, when it builds the function's stack 
> frame (refer to 
> https://github.com/golang/go/blob/go1.17/src/runtime/cpuprof.go#L21) With 
> that, the resulting profile misses the relationship between main.DFS and 
> its parent function, thus it "hangs" beneath the root node now.
>
> Keep in mind that the original post is almost 10 year old now. Some other 
> details might have changed as well.
>
> Cheers,
> V.
>
> On Monday, September 27, 2021 at 11:03:53 AM UTC+2 alex-coder wrote:
>
>> Hi All,
>>
>> currently I walk through sample given there:
>> Profiling Go Programs - go.dev <https://go.dev/blog/pprof>
>>
>> but when I came at the point where the user should enter web command to 
>> the pprof
>> I do not see that the function DFS call itself on a picture.
>> Looks like I do use a proper version of the sample - go_pro, where the 
>> recursion is present:
>> multi-language-bench/src/havlak/go_pro at master · 
>> hundt98847/multi-language-bench · GitHub 
>> <https://github.com/hundt98847/multi-language-bench/tree/master/src/havlak/go_pro>
>>
>> So, what could be the reason that the picture is painted not properly ?
>>
>> I use 1.17.1, windows 10.
>>
>> Thank you.
>>
>>

-- 
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/efbbb5ce-0ec0-4d73-84c0-6cf71c68c368n%40googlegroups.com.

[go-nuts] question about Profiling Go Programs sample.

[alex-coder]

Hi All,

currently I walk through sample given there:
Profiling Go Programs - go.dev 

but when I came at the point where the user should enter web command to the 
pprof
I do not see that the function DFS call itself on a picture.
Looks like I do use a proper version of the sample - go_pro, where the 
recursion is present:
multi-language-bench/src/havlak/go_pro at master · 
hundt98847/multi-language-bench · GitHub 


So, what could be the reason that the picture is painted not properly ?

I use 1.17.1, windows 10.

Thank you.

-- 
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/7f516db7-e796-4329-8da4-a6b6f28197e6n%40googlegroups.com.

Re: [go-nuts] Parse JSON case-sensitively

[Alex Howarth]

Could you perhaps achieve this with reflect and UnmarshalJSON() ?

The following basic example compares against the case-sensitive json tag:

https://play.golang.org/p/Oe_tovxe9Ld

On Thu, 23 Sept 2021 at 14:23, 'Aaron' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hi all
>
> Anyone know of a JSON package (or other solution) which is case-sensitive
> when decoding - and is also mature, simple, and parses into a struct?
> I've looked at a few open-source packages, but the ones I've found seem to
> be focused on performance, or allowing you to access the JSON in different
> ways, or require code-generation, or something.
> Really I just want a drop-in replacement for encoding/json that is case
> sensitive.
> Wondering about forking the package myself... but obviously don't want to
> do that if there's an existing solution.
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a3d25416-2490-4719-a38c-9f6a43008184n%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/CAB-c0PcZiy-RmBw_C4_6xEFm7rNqPbbknQtWUfzescM_K0eCMg%40mail.gmail.com.

[go-nuts] mkwinsyscall and handling HRESULT

['Alex Crane' via golang-nuts]

I recently used mkwinsyscall for the functions around creating 
AppContainers 
(e.g. 
https://docs.microsoft.com/en-us/windows/win32/api/userenv/nf-userenv-createappcontainerprofile)

e.g. Something like:
//sys   CreateAppContainerProfile(name *uint16, displayName *uint16, 
description *uint16, caps *windows.SIDAndAttributes, capsCount uint32, outSid 
**windows.SID) (hres error) = Userenv.CreateAppContainerProfile

(N.B. I would rather have used string type rather than *uint16 but there 
was no way to signal that this is a UTF-16 function prototype as the 
function name doesn't end in W, so the generated code used *uint8 - not the 
point of this discussion but I wonder if an annotation to //sys lines can 
be added to indicate generate UTF-16)

The error that is returned is an HRESULT, though mkwinsyscall treats it as 
a syscall.Errno. This works fine for printing the error, but I had hoped to 
use errors.Is(err, os.ErrExist) to handle the already exists case. This 
picks up ERROR_ALREADY_EXISTS (0xB7) but unfortunately because  
CreateAppContainerProfile returns an HRESULT, it returns 0x800700B7, so  
errors.Is(err, os.ErrExist) returns false

So I suppose my question is, what is the best way to handle this? 
  - Should a hack be added to Errno functions (or even a wrapper around 
Errno creation?) to mask off the first word if it's 0x8007?
  - Should HRESULT be a different type to Errno much like I noticed someone 
recently added NTSTATUS (along with a way to mark an error as so in 
mkwinsyscall)? Can begin to implement Errors.Is for the Win32 facility at 
least.

Hope I've made this clear..

Thanks,
Alex

-- 
*This electronic message contains information from Ava Security/Ava 
federal, which may be privileged or confidential. The information is 
intended for use only by the individual(s) or entity named above. If you 
are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this information is strictly 
prohibited. If you have received this electronic message in error, please 
notify the sender. Activity and use of the Ava Security Limited/Ava Federal 
email system is monitored to secure its effective operation and for other 
lawful business purposes. Communications using this system will also be 
monitored and may be recorded to secure effective operation and for other 
lawful business purposes. *

-- 
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/42c90497-41a0-4470-80ed-5d45b502e10bn%40googlegroups.com.

[go-nuts] Re: Profiling goroutines

[Alex Besogonov]

Use pprof labels to mark goroutines. This provides way more context than 
anonymous goroutine IDs.

On Friday, September 3, 2021 at 1:19:55 PM UTC-7 peppy...@gmail.com wrote:

> Hey guys, 
>
> I am trying to get a full picture using a pprof of a highly paralelised 
> binary (read many goroutines doing stuff) but I am struggling to find any 
> information on this topic - I think what I am seeing at the moment is just 
> a single goroutine/main thread in the web UI that the tool provides.
>
> Is there more information on how to obtain a bigger picture that may 
> contain more info (although thinking about it, it may be too much info) ?
>
> Kindly,
> Peter.
>

-- 
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/c5fb9f2a-6bd6-4357-a61f-a1decf7ad874n%40googlegroups.com.

[go-nuts] Go 1.16.7 and Go 1.15.15 are released

[Alex Rakoczy]

Hello gophers,

We have just released Go versions 1.16.7 and 1.15.15, minor point releases.

These minor releases include a security fix according to the new security
policy.

A net/http/httputil ReverseProxy can panic due to a race condition if its
Handler aborts with ErrAbortHandler, for example due to an error in copying the
response body. An attacker might be able to force the conditions leading to the
race condition.

This is issue https://golang.org/issue/46866 and CVE-2021-36221. Thanks to
Andrew Crump (VMware) for reporting this issue.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.16.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.16.7" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
David, Carlos, and Alex 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/CA%2BxaJdQp1vfCXRPE3C44zp7hsNNWddTi2kQe%2BayXwu%3DGHvKqaA%40mail.gmail.com.

[go-nuts] Go 1.17 Release Candidate 2 is released

[Alex Rakoczy]

Hello gophers,

We have just released go1.17rc2, a release candidate version of Go 1.17.
It is cut from release-branch.go1.17 at the revision tagged go1.17rc2.

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://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.17rc2
is by using the go command:
$ go get golang.org/dl/go1.17rc2
$ go1.17rc2 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.17rc2

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

Cheers,
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/CA%2BxaJdSSkE8M76dFO%2BLMWJbS1-UpdNaSCB70F_4DuRBkwANKXA%40mail.gmail.com.

Re: [go-nuts] UML && Golang, part 2 ?

[alex-coder]

Well, if there is a complex or not very complex system written in a 
programming language,
using uml helps faster understand both the system and the dependencies and 
constractions in the code. 
Especially if the system is unfamiliar.

Right ? :-)

воскресенье, 4 июля 2021 г. в 14:27:29 UTC+3, Jan Mercl: 

> On Sun, Jul 4, 2021 at 1:16 PM alex-coder  wrote:
>
> > But what do you use instead then ?
>
> For what?
>
> In case it's not obvious, I never touched UML and I don't really
> understand its utility. So I'm asking an honest question. Knowing the
> answer might help to possibly provide some answer to your question.
>

-- 
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/2f3b4c90-5180-4522-b29f-b8ca2ad4c492n%40googlegroups.com.

[go-nuts] UML && Golang, part 2 ?

[alex-coder]

Ok, folk, as I see UML is not very popular within the community. :-)
But what do you use instead then ?

Anyway it must be some tool to present the code as a picture.
The picture is worth a thousand words :-).

Thank you.

-- 
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/db5362fb-6365-4b88-9b56-98c88cd5cb62n%40googlegroups.com.

[go-nuts] UML && Golang

[alex-coder]

Hi All !

I can't find an IDE that has a conversion tool from Golang code to uml 
diagrams. 
I will be very grateful for the link to.
You see, the picture is worth a thousand words :-).

Thank you.

-- 
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/25b47822-0a80-4dcd-983b-00460b3b5e4an%40googlegroups.com.

[go-nuts] Re: problems using external modules with go 1.16.4

[Alex]

Was writing my reply then Jan beat me lol, anyway he didn't linked the 
tutorial soo...
https://golang.org/doc/tutorial/getting-started
On Friday, 7 May 2021 at 9:21:29 pm UTC+8 natxo@gmail.com wrote:

> hi,
>
> I am struggling with the new go version.
>
> I have a simple script that imports a github module, and before (don't 
> know which go version) I could just run:
>
> go get github/user/module
>
> and then in my crappy script I could
>
> package main
> import github.com/user/module
>
> func main() {
> p := module.New()
> p.run(whatever)
> }
>
> but this now exits with the error:
> no required module provides package github.com/user/module: go.mod file 
> not found in current directory or any parent directory; see 'go help 
> modules'
>
> I do not want to write a module, I just want to use a module. So how do I 
> do this? I am reading all the tutorials  listed on the go help modules 
> output, but at this point I do not need to write a module.
>
> A bit confused. I am obviously doing it wrong, but I cannot understand why.
>
> Any help greatly appreciated.
>
> Regards,
> Natxo
>
>
>
>
>
>

-- 
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/f1435504-efc7-4455-aa42-277efc1a7f6cn%40googlegroups.com.

Re: [go-nuts] HTTP request reading

[K. Alex Mills]

Partial responses inline, HTH.

On Thu, Apr 29, 2021, 6:09 AM Amit Saha  wrote:

> Hi all, when an incoming request comes in, does the ListenAndServe()
> function read the first line (as explained in
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages) to figure
> out whether there is a handler registered or not for the path and then
> simply hands it over to the handler (if there is one)?


In the http package, that role is played by the ServeMux
.


> It seems like it is also reading the headers, and then populating the
> http.Request object with them. But, I am curious as to why does it do
> so? Is there any specific header that the server must look for?
>

HTTP headers arrive on the wire before the body, so they have to be
consumed prior to the body. The HTTP package parses them and makes them
available so the handler and middleware can make use of them as needed to
do header-related things like authentication.


> As far as the Body is concerned, that is left to the handler to
> decide, is that correct?
>

I guess you mean that the handler gets to decide for itself whether to read
the body or not. AFAIK, that's correct.

One benefit of parsing the headers into a map is that it makes HTTP
middleware more composeable and easier to write. Parsing the headers first
means different middlewares can examine the same headers. The same is not
true of the body, which can only be consumed once unless you add special
handling to store it in memory for later.


> Thanks,
> Amit.
>
> --
> 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/CANODV3kSLPyV0snkPOr8Q_j%2BR%3DGOfVie2FNxEA1B-8%2BFvQxMEA%40mail.gmail.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/CALJzkY8qgh-GKPK_vKC-%3Dz1gGfZoNHT62KfWtMh%3D0bbv-R5afw%40mail.gmail.com.

[go-nuts] Re: Setting the Don't Fragment (DF) bit on OSX

[Alex Besogonov]

DF bit is needed to discover the MTU on the application level, exactly 
because MTU discovery can be broken on lower levels of the network stack. 
QUIC specifies this procedure here: 
https://tools.ietf.org/html/draft-ietf-quic-transport-05#page-53

On Saturday, April 24, 2021 at 1:37:26 PM UTC-7 ico@gmail.com wrote:

> I'm curious, why do you need to set DF bit? I'm asking, because as a 
> network engineer I'm often experiencing broken apps with this setting. It 
> usually ends up network pointing to app and vice versa.
> New tunnel along the path, either GRE or IPSec is lowering MTU, new 
> technologies like Cisco SD-WAN are all tunnel inside tunnel inside MPLS and 
> MTU can go as low as 1260. 
> Different workarounds are configured on routers as dynamic mss size 
> adjustment.
> In your case you are at least trying to discover MTU, but path could be in 
> many cases asymmetric. 
>
> On Friday, April 23, 2021 at 8:20:15 AM UTC+2 Marten Seemann wrote:
>
>> For my QUIC implementation , 
>> I'm trying to set the DF bit on outgoing packets.
>>
>> The following code works fine on Linux:
>> addr, _ := net.ResolveUDPAddr("udp", ":0")
>> conn, _ := net.ListenUDP("udp", addr)
>> rawConn, _ := conn.SyscallConn()
>> rawConn.Control(func(fd uintptr) {
>> unix.SetsockoptInt(int(fd), unix.IPPROTO_IP, unix.IP_MTU_DISCOVER, 1)
>> })
>>
>> On OSX, the sockopt doesn't have a named constant, the correct value to 
>> use here is 28. The code above only works if I'm listening on an address 
>> that's unambiguously IPv4, e.g. *127.0.0.1:0 *.
>> If I listen on an address that allows me to send and receive both IPv4 
>> and IPv6 (like *:0*), it doesn't work anymore: *SetsockoptInt *now 
>> returns error 22 (invalid argument). That's unfortunate as users of the 
>> library often listen on *:0*.
>>
>> Is there any way to make this work analogously to how it works on Linux?
>>
>

-- 
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/9407910f-0cd2-4a35-ba24-9b367c9fda50n%40googlegroups.com.

Re: [go-nuts] go text://protocol client?

[K. Alex Mills]

On Sun, Apr 11, 2021, 5:15 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Sun, Apr 11, 2021 at 5:11 AM Kurtis Rader  wrote:
>
>>
>> It is nice that the specification allows for an efficient implementation.
>> But I agree with Dan that your documentation is opaque, obtuse,
>> inscrutable, etc. So much so that I initially thought it was some sort of
>> April Fools Day joke.
>>
>>
> April Fools?
>
> No.
>
> It's an art installation. A lament to the mistakes we've made. The
> documents WE've written. But no-one reads. We revel in the 113 lines of
> pure specification, as a temple to Alan Kay. Documentation must be
> executable! The page implements human Hypertext is the Engine of
> Application State (HATEOAS), creating an interlinked web of important data.
> You MUST dig(1) to understand. Also note that the page is a mirror into a
> better world. A world in which text://protocol exists! It's for the youth.
> They never experienced the raw information exchange driven by
> Sync-on-Green. They never experienced Unix in its pure form. Or plan 9.
> Instead, they are forced, by the power of the DOM and CSS, to live in a
> pin-holed world where the light only shines occasionally. This is their BBS.
>
> This doesn't belong on a mailing list. It should be put in an art gallery.
>

>
Well I'm convinced this is art, and once it's viewed that way, I think it
stops being confounding and becomes delightful.

Sending it to my Art History contacts for analysis. Maybe by putting it in
the proper context we can come to understand it better (or at least...
differently).


> --
> 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/CAGrdgiUQNgEXaaB%3Dy8BCVaE%2Bc%2BRCwxbmLeUJNh%2B-Lq%2B27t3LWQ%40mail.gmail.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/CALJzkY-hGCRQB1cV%3DsexR05dyHZF07a19wL%3D-PVxtE9sZNMf0w%40mail.gmail.com.

Re: [go-nuts] Modules... why it has to be so painfull?

[Alex Howarth]

Have you tried go mod edit -replace github.com/foo/bar=/path/to/local/bar ?

https://golang.org/ref/mod#go-mod-edit

On Wed, 7 Apr 2021 at 17:31, Slawomir Pryczek  wrote:
>
> Hey Guys, I'm struggling with the new "modules" approach and after
checking several help files it seems it's inconvinient beyond belief.
Basically i have an app:
>
> ...src/
> /myapp/main.go package main
> /pool/pool.go package pool
>
> And i can't even include package pool into main without manually
initializing module, then installing it, and then when i do any change to
pool i'll have to re-get / re-install the package, so it even breaks things
as simple as conviniently building a basic app with >1 shared package.
>
> Question is why it's no longer possible to break the project into
independent packages and easily re-use them. I have eg. a webserver which
implements each operation as separate package, and also it has slab
allocator which other projects are using. And it works great.
>
> Maybe someday i'd like to convert the slab allocator into separated
module, but why forcing users to do so much unnecessary work and pretend
everyone wants to expose everything they're writing as module from earliest
stage of the project?
>
> Is there any way to retain this kind of structure without countless hours
wasted on manually initializing modules and other completely pointless
maintenance tasks. Previously i was just able to create a package in gopath
and use it everywhere, refactoring was very easy and i could easily split
any project into multiple packages. Actually go was so good because
refactoring and reorganizing code was so easy. Now it seems that's no
longer possible and in docs I found info that gopath approach will be
obsolete, so i'm trying to go with the new one. Which seems so painfull...
>
> Also read several posts about local packages. Complexity of this is
beyond ridiculous. Really i need to install a local proxy or use some
special directives to allow my appa and appb to use packagec? Really it
needs to be so complex and so user unfriendly so instead of writing code
we'll be thinking about setting up proxies and configuring dependencies
just to share some code between 2 local apps because this has to be done
via HTTP or special configuration?
>
> Anyone has an idea for a reasonable solution which will allow easy
refactoring and code organization in packages, in this new model?
>
> Thanks,
> Slawomir.
>
> --
> 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/bb6d0bd0-e411-4c93-a1ee-5eec44e1bc48n%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/CAB-c0PcAp09JJEZvMgPLM%3Dqm2rjzxX0V6iw0y2m-kZ5KNYQEdQ%40mail.gmail.com.

Re: [go-nuts] Go code review site?

[Alex Howarth]

You could try the Slack channel #reviews on gophers.slack.com

-alex

On Sun, 4 Apr 2021, 09:20 Tong Sun,  wrote:

> I remember I've been to a page/site where people can ask for review for
> their open source projects, commits, etc.
>
> Is there such site/service, or my memory has fainted (e.g., it's for go
> core only etc)?
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/1a3c8525-9bfd-43d6-9b63-17ffac3dc2cdn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/1a3c8525-9bfd-43d6-9b63-17ffac3dc2cdn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAB-c0PdCyiH%3D7MFYD2XiYGmhgNzKME40uVVUJaWXwEWXF9Q1qg%40mail.gmail.com.