Re: [go-nuts] Parsing go.mod

[Kurtis Rader]

On Mon, Sep 2, 2019 at 10:44 PM James Pettyjohn 
wrote:

> This might be a bad idea but I'm trying to parse the go.mod file for data
> as part of my build process - if at all possible I'd like to avoid
> duplicating the data that is already there in another file.
>

In this type of situation you should explain why you need to parse a go.mod
file. Especially since you seem to be asking something not already asked a
thousand times. It is possible, perhaps likely, the reason you want to do
this can be solved some other way.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD8E4uy3XLGV44vx7CLS4KVefi7L1TSjquWB%3D3VNGCpEqg%40mail.gmail.com.

Re: [go-nuts] Parsing go.mod

[Dan Kortschak]

Not really exposed, but there is code you could copy.

https://golang.org/pkg/cmd/go/internal/modfile/#Parse

On Mon, 2019-09-02 at 22:44 -0700, James Pettyjohn wrote:
> Hi,
> 
> This might be a bad idea but I'm trying to parse the go.mod file for
> data 
> as part of my build process - if at all possible I'd like to avoid 
> duplicating the data that is already there in another file.
> 
> Is there an exposed package that can be used for this?
> 
> - 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/4d672a4c60b90b4552a5f5bf672e925f313cc942.camel%40kortschak.io.

[go-nuts] Parsing go.mod

[James Pettyjohn]

Hi,

This might be a bad idea but I'm trying to parse the go.mod file for data 
as part of my build process - if at all possible I'd like to avoid 
duplicating the data that is already there in another file.

Is there an exposed package that can be used for this?

- 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/79c5a541-9f66-4907-9a58-8a74c7fb349c%40googlegroups.com.

Re: [go-nuts] playground - time.Sleep causes deadlock

[Robert Engels]

Actually, in thinking about this some more, the atomics are completely 
unnecessary. Your solution being the best, but even without it, the channels 
create a happens before scenario - between the write of closed and “the channel 
close” and the read of closed. That is, for a channel to be reported as closed 
all other writes prior must be visible. 

> On Sep 2, 2019, at 6:52 PM, Robert Engels  wrote:
> 
> As far as I know you are attributing properties to the memory model that 
> don’t yet exist - they’re working on it. Even the “happens before” in 
> relation to atomics is not yet defined. The position from the Go “team” so 
> far has been, whatever the behavior you see, that’s the spec (in terms of 
> memory model)
> 
> Still, I would hope the memory model would cover this case as it would 
> (probably) avoid unnecessary atomic writes. In this case if there were atomic 
> Boolean or bytes it wouldn’t be subject to tearing, maybe int32 in most 
> platforms. 
> 
> Still, like I said, if you want add the atomic writes, go ahead. This is 
> definitely safer. But I think when the full memory model spec arrives it 
> won’t be necessary. 
> 
>> On Sep 2, 2019, at 6:02 PM, roger peppe  wrote:
>> 
>> 
>> 
>>> On Mon, 2 Sep 2019, 21:32 robert engels,  wrote:
>>> (you’re comments were quoted, but I think I am replying correctly).
>>> 
>>> The memory barriers provided by the Write Lock, and release will force the 
>>> flush to memory of all mutations before the flush (the closed mutation) - 
>>> meaning the atomic read will read the correct value.
>> 
>> 
>> In this case, I'm much more interested in writing Go code that's correct 
>> according to the spec than Go code that happens to work on some current 
>> architecture. Let's try to make code that's "obviously correct" rather than 
>> "not obviously incorrect". The memory model has no mention of "memory 
>> barriers" or "flushing".
>> 
>>> 
>>> There is a chance that a fully specified memory model could make that not 
>>> be possible, but in the current de-facto memory model it is going to be the 
>>> case on any CPU architecture I’m aware of. Some transactional memory 
>>> systems might be able to avoid the flush on the ‘closed’, but unlikely.
>>> 
>>> I would welcome you writing a test case to demonstrate this not being the 
>>> case and failing.
>> 
>> 
>> On a 32 bit architecture, the 64 bit write could easily be split across two 
>> non-atomic operations. AFAIK there's nothing about the atomic read that says 
>> that it couldn't observe a partial write by one of the write operations 
>> inside the mutex. It may well be possible to write a test case to 
>> demonstrate the issue on a 32-bit ARM machine. And even if it isn't, I would 
>> much always flag up code like this in a code review as being too subtle and 
>> prone to potential errors.
>> 
>>> 
>>> The reason the race detector reports a race is because it expects all 
>>> access to be guarded by the same guard, the Lock/Release must perform the 
>>> same memory barriers on the SMP systems I’m aware of.
>> 
>> 
>> Yes. That's what the memory model expects, and how Go code should be 
>> written. If code fails when run with the race detector, it should be fixed, 
>> IMHO.
>> 
>>> 
>>> The comment on the better “read” method is definitely the way to go. It 
>>> still encapsulates the channel(s), and avoids any of the ambiguity of the 
>>> memory model (while probably improving the performance a bit).
>>> 
>>> Agreed that the encapsulation can cause issues like you describe, but the 
>>> response was originally related to “priority channels”, and I was 
>>> demonstrating a technique (with additional channels behind the struct) that 
>>> would allow easy implementations of priorities. But the code I provided 
>>> certainly simplifies the case of multi writer/readers with indeterministic 
>>> behavior/shutdown (without using panic/recover which is probably the 
>>> easiest for the simple case).
>>> 
>>> 
 On Sep 2, 2019, at 11:16 AM, roger peppe  wrote:
 
>> Btw, the removing of the GOMAXPROCS causes things to execute serially- 
>> which is fine according to the spec - but it does make demonstrating 
>> certain concurrency structs/problems pretty difficult.
>> Unless something's changed recently, all programs in the playground 
>> execute without parallelism, so setting GOMAXPROCS shouldn't have any 
>> effect. The fact that it does have an affect appears to be a bug. I'd 
>> suggest reporting it as an issue.
>> 
>> As I pointed out in another reply, I am fairly certain the atomic 
>> operations must be valid in these cases due to the happens before 
>> relationship of them and mutexes.
>> In that other reply:
>> 
>> You can simply validate it by run: go run -race main.go for you program: 
>> https://play.golang.org/p/JRSEPU3Uf17
>> Not true. The race detector does not detect certain cases and can 
>> overreport.
>> Firstly, AFAIK 

Re: [go-nuts] playground - time.Sleep causes deadlock

[Robert Engels]

As far as I know you are attributing properties to the memory model that don’t 
yet exist - they’re working on it. Even the “happens before” in relation to 
atomics is not yet defined. The position from the Go “team” so far has been, 
whatever the behavior you see, that’s the spec (in terms of memory model)

Still, I would hope the memory model would cover this case as it would 
(probably) avoid unnecessary atomic writes. In this case if there were atomic 
Boolean or bytes it wouldn’t be subject to tearing, maybe int32 in most 
platforms. 

Still, like I said, if you want add the atomic writes, go ahead. This is 
definitely safer. But I think when the full memory model spec arrives it won’t 
be necessary. 

> On Sep 2, 2019, at 6:02 PM, roger peppe  wrote:
> 
> 
> 
>> On Mon, 2 Sep 2019, 21:32 robert engels,  wrote:
>> (you’re comments were quoted, but I think I am replying correctly).
>> 
>> The memory barriers provided by the Write Lock, and release will force the 
>> flush to memory of all mutations before the flush (the closed mutation) - 
>> meaning the atomic read will read the correct value.
> 
> 
> In this case, I'm much more interested in writing Go code that's correct 
> according to the spec than Go code that happens to work on some current 
> architecture. Let's try to make code that's "obviously correct" rather than 
> "not obviously incorrect". The memory model has no mention of "memory 
> barriers" or "flushing".
> 
>> 
>> There is a chance that a fully specified memory model could make that not be 
>> possible, but in the current de-facto memory model it is going to be the 
>> case on any CPU architecture I’m aware of. Some transactional memory systems 
>> might be able to avoid the flush on the ‘closed’, but unlikely.
>> 
>> I would welcome you writing a test case to demonstrate this not being the 
>> case and failing.
> 
> 
> On a 32 bit architecture, the 64 bit write could easily be split across two 
> non-atomic operations. AFAIK there's nothing about the atomic read that says 
> that it couldn't observe a partial write by one of the write operations 
> inside the mutex. It may well be possible to write a test case to demonstrate 
> the issue on a 32-bit ARM machine. And even if it isn't, I would much always 
> flag up code like this in a code review as being too subtle and prone to 
> potential errors.
> 
>> 
>> The reason the race detector reports a race is because it expects all access 
>> to be guarded by the same guard, the Lock/Release must perform the same 
>> memory barriers on the SMP systems I’m aware of.
> 
> 
> Yes. That's what the memory model expects, and how Go code should be written. 
> If code fails when run with the race detector, it should be fixed, IMHO.
> 
>> 
>> The comment on the better “read” method is definitely the way to go. It 
>> still encapsulates the channel(s), and avoids any of the ambiguity of the 
>> memory model (while probably improving the performance a bit).
>> 
>> Agreed that the encapsulation can cause issues like you describe, but the 
>> response was originally related to “priority channels”, and I was 
>> demonstrating a technique (with additional channels behind the struct) that 
>> would allow easy implementations of priorities. But the code I provided 
>> certainly simplifies the case of multi writer/readers with indeterministic 
>> behavior/shutdown (without using panic/recover which is probably the easiest 
>> for the simple case).
>> 
>> 
>>> On Sep 2, 2019, at 11:16 AM, roger peppe  wrote:
>>> 
> Btw, the removing of the GOMAXPROCS causes things to execute serially- 
> which is fine according to the spec - but it does make demonstrating 
> certain concurrency structs/problems pretty difficult.
> Unless something's changed recently, all programs in the playground 
> execute without parallelism, so setting GOMAXPROCS shouldn't have any 
> effect. The fact that it does have an affect appears to be a bug. I'd 
> suggest reporting it as an issue.
> 
> As I pointed out in another reply, I am fairly certain the atomic 
> operations must be valid in these cases due to the happens before 
> relationship of them and mutexes.
> In that other reply:
> 
> You can simply validate it by run: go run -race main.go for you program: 
> https://play.golang.org/p/JRSEPU3Uf17
> Not true. The race detector does not detect certain cases and can 
> overreport.
> Firstly, AFAIK there is no implied happens-before relationship between a 
> non-atomic write to a variable and an atomic read from a variable, 
> because there is no synchronization event associated with the atomic read.
> 
> Secondly, I am aware that the race detector can give false negatives in 
> some cases, but it should not provide false positives AFAIK. There's only 
> one such case that I'm aware of, and that's quite a different issue.
> 
> Given that the race detector reports a race in this 

Re: [go-nuts] playground - time.Sleep causes deadlock

[roger peppe]

On Mon, 2 Sep 2019, 21:32 robert engels,  wrote:

> (you’re comments were quoted, but I think I am replying correctly).
>
> The memory barriers provided by the Write Lock, and release will force the
> flush to memory of all mutations before the flush (the closed mutation) -
> meaning the atomic read will read the correct value.
>

In this case, I'm much more interested in writing Go code that's correct
according to the spec than Go code that happens to work on some current
architecture. Let's try to make code that's "obviously correct" rather than
"not obviously incorrect". The memory model has no mention of "memory
barriers" or "flushing".


> There is a chance that a fully specified memory model could make that not
> be possible, but in the current de-facto memory model it is going to be the
> case on any CPU architecture I’m aware of. Some transactional memory
> systems might be able to avoid the flush on the ‘closed’, but unlikely.
>
> I would welcome you writing a test case to demonstrate this not being the
> case and failing.
>

On a 32 bit architecture, the 64 bit write could easily be split across two
non-atomic operations. AFAIK there's nothing about the atomic read that
says that it couldn't observe a partial write by one of the write
operations inside the mutex. It may well be possible to write a test case
to demonstrate the issue on a 32-bit ARM machine. And even if it isn't, I
would much always flag up code like this in a code review as being too
subtle and prone to potential errors.


> The reason the race detector reports a race is because it expects all
> access to be guarded by the same guard, the Lock/Release must perform the
> same memory barriers on the SMP systems I’m aware of.
>

Yes. That's what the memory model expects, and how Go code should be
written. If code fails when run with the race detector, it should be fixed,
IMHO.


> The comment on the better “read” method is definitely the way to go. It
> still encapsulates the channel(s), and avoids any of the ambiguity of the
> memory model (while probably improving the performance a bit).
>
> Agreed that the encapsulation can cause issues like you describe, but the
> response was originally related to “priority channels”, and I was
> demonstrating a technique (with additional channels behind the struct) that
> would allow easy implementations of priorities. But the code I provided
> certainly simplifies the case of multi writer/readers with indeterministic
> behavior/shutdown (without using panic/recover which is probably the
> easiest for the simple case).
>
>
> On Sep 2, 2019, at 11:16 AM, roger peppe  wrote:
>
> Btw, the removing of the GOMAXPROCS causes things to execute serially-
>> which is fine according to the spec - but it does make demonstrating
>> certain concurrency structs/problems pretty difficult.
>>
>> Unless something's changed recently, all programs in the playground
>> execute without parallelism, so setting GOMAXPROCS shouldn't have any
>> effect. The fact that it does have an affect appears to be a bug. I'd
>> suggest reporting it as an issue.
>>
>> As I pointed out in another reply, I am fairly certain the atomic
>> operations must be valid in these cases due to the happens before
>> relationship of them and mutexes.
>>
>> In that other reply:
>>
>> You can simply validate it by run: go run -race main.go for you program:
>> https://play.golang.org/p/JRSEPU3Uf17
>>
>> Not true. The race detector does not detect certain cases and can
>> overreport.
>>
>> Firstly, AFAIK there is no implied happens-before relationship between a
>> non-atomic write to a variable and an atomic read from a variable, because
>> there is no synchronization event associated with the atomic read.
>>
>> Secondly, I am aware that the race detector can give false negatives in
>> some cases, but it should not provide false positives AFAIK. There's only
>> one such case that I'm aware of, and that's quite a different issue
>> .
>>
>> Given that the race detector reports a race in this very clear and
>> simple case , ISTM that your
>> program is wrong.
>>
>> From https://golang.org/ref/mem:
>>
>> If you must read the rest of this document to understand the behavior of
>> your program, you are being too clever.
>> Don't be clever.
>>
>> Also, there's really no point in the atomic read. You could implement the
>> Read method as follows:
>>
>> func (c *MultiWriterIntChan) Read() (int, bool) {
>>  x, ok := <-c.ch
>>  return x, ok
>>
>> }
>>
>> That is, let the close state flow naturally downstream via the channel.
>> That way it will still work correctly if you start to use a buffered
>> channel, for example.
>>
>> I don’t agree that returning the channel is a proper design, it breaks
>> the encapsulation. Technically mine could use multiple channels behind the
>> scenes - yours cannot.
>>
>> There's a trade-off here. By encapsulating in a method, you make it

[go-nuts] Re: Go module and local dependencies

[Igor Maznitsa]

maven golang plugin  allows to 
process such cases automatically and organize mix from local parts of 
project and modules 
,
 
but it needs knowledge of maven buid tool

-- 
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/cce6ab4b-9a40-41ed-a1a5-fcfdc6fcddb4%40googlegroups.com.

Re: [go-nuts] playground - time.Sleep causes deadlock

[robert engels]

(you’re comments were quoted, but I think I am replying correctly).

The memory barriers provided by the Write Lock, and release will force the 
flush to memory of all mutations before the flush (the closed mutation) - 
meaning the atomic read will read the correct value.

There is a chance that a fully specified memory model could make that not be 
possible, but in the current de-facto memory model it is going to be the case 
on any CPU architecture I’m aware of. Some transactional memory systems might 
be able to avoid the flush on the ‘closed’, but unlikely.

I would welcome you writing a test case to demonstrate this not being the case 
and failing.

The reason the race detector reports a race is because it expects all access to 
be guarded by the same guard, the Lock/Release must perform the same memory 
barriers on the SMP systems I’m aware of.

The comment on the better “read” method is definitely the way to go. It still 
encapsulates the channel(s), and avoids any of the ambiguity of the memory 
model (while probably improving the performance a bit).

Agreed that the encapsulation can cause issues like you describe, but the 
response was originally related to “priority channels”, and I was demonstrating 
a technique (with additional channels behind the struct) that would allow easy 
implementations of priorities. But the code I provided certainly simplifies the 
case of multi writer/readers with indeterministic behavior/shutdown (without 
using panic/recover which is probably the easiest for the simple case).


> On Sep 2, 2019, at 11:16 AM, roger peppe  wrote:
> 
>> Btw, the removing of the GOMAXPROCS causes things to execute serially- which 
>> is fine according to the spec - but it does make demonstrating certain 
>> concurrency structs/problems pretty difficult.
>> Unless something's changed recently, all programs in the playground execute 
>> without parallelism, so setting GOMAXPROCS shouldn't have any effect. The 
>> fact that it does have an affect appears to be a bug. I'd suggest reporting 
>> it as an issue.
>> 
>> As I pointed out in another reply, I am fairly certain the atomic operations 
>> must be valid in these cases due to the happens before relationship of them 
>> and mutexes.
>> In that other reply:
>> 
>> You can simply validate it by run: go run -race main.go for you program: 
>> https://play.golang.org/p/JRSEPU3Uf17 
>> Not true. The race detector does not detect certain cases and can overreport.
>> Firstly, AFAIK there is no implied happens-before relationship between a 
>> non-atomic write to a variable and an atomic read from a variable, because 
>> there is no synchronization event associated with the atomic read.
>> 
>> Secondly, I am aware that the race detector can give false negatives in some 
>> cases, but it should not provide false positives AFAIK. There's only one 
>> such case that I'm aware of, and that's quite a different issue 
>> .
>> 
>> Given that the race detector reports a race in this very clear and simple 
>> case , ISTM that your program is 
>> wrong.
>> 
>> From https://golang.org/ref/mem :
>> 
>> If you must read the rest of this document to understand the behavior of 
>> your program, you are being too clever.
>> 
>> Don't be clever.
>> Also, there's really no point in the atomic read. You could implement the 
>> Read method as follows:
>> 
>> func (c *MultiWriterIntChan) Read() (int, bool) {
>>  x, ok := <-c.ch 
>>  return x, ok  
> 
>> }
> 
>> That is, let the close state flow naturally downstream via the channel. That 
>> way it will still work correctly if you start to use a buffered channel, for 
>> example.
>> 
>> I don’t agree that returning the channel is a proper design, it breaks the 
>> encapsulation. Technically mine could use multiple channels behind the 
>> scenes - yours cannot.
>> There's a trade-off here. By encapsulating in a method, you make it harder 
>> to wait for values in combination with other events (you'd need to create a 
>> goroutine to call your Read method and send the result to a channel, adding 
>> buffering, context switch overhead, and more state that needs to be 
>> explicitly shut down). 
> 
> 
> 
> -- 
> 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/CAJhgaci57DOYHOk7C%3DjM8B6wenCxYv4JvNn2%3D13OGcd66Yc3EA%40mail.gmail.com
>  
> .

-- 
You received this message because you are 

[go-nuts] Re: Closed channel vs nil channel when writing

[Jake Montgomery]

On Monday, September 2, 2019 at 9:41:54 AM UTC-4, T L wrote:

>
> https://go101.org/article/channel.html
>

That is a great, and pretty detailed article. For quick reference I like 
https://dave.cheney.net/2014/03/19/channel-axioms .

-- 
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/f5e50f58-f258-46b3-86a2-f544c319aa23%40googlegroups.com.

Re: [go-nuts] playground - time.Sleep causes deadlock

[roger peppe]

>
> Btw, the removing of the GOMAXPROCS causes things to execute serially-
> which is fine according to the spec - but it does make demonstrating
> certain concurrency structs/problems pretty difficult.
>
> Unless something's changed recently, all programs in the playground
> execute without parallelism, so setting GOMAXPROCS shouldn't have any
> effect. The fact that it does have an affect appears to be a bug. I'd
> suggest reporting it as an issue.
>
> As I pointed out in another reply, I am fairly certain the atomic
> operations must be valid in these cases due to the happens before
> relationship of them and mutexes.
>
> In that other reply:
>
> You can simply validate it by run: go run -race main.go for you program:
> https://play.golang.org/p/JRSEPU3Uf17
>
> Not true. The race detector does not detect certain cases and can
> overreport.
>
> Firstly, AFAIK there is no implied happens-before relationship between a
> non-atomic write to a variable and an atomic read from a variable, because
> there is no synchronization event associated with the atomic read.
>
> Secondly, I am aware that the race detector can give false negatives in
> some cases, but it should not provide false positives AFAIK. There's only
> one such case that I'm aware of, and that's quite a different issue
> .
>
> Given that the race detector reports a race in this very clear and simple
> case , ISTM that your program is
> wrong.
>
> From https://golang.org/ref/mem:
>
> If you must read the rest of this document to understand the behavior of
> your program, you are being too clever.
>
> Don't be clever.
>
> Also, there's really no point in the atomic read. You could implement the
> Read method as follows:
>
> func (c *MultiWriterIntChan) Read() (int, bool) {
>   x, ok := <-c.ch
>   return x, ok
>
> }
>
> That is, let the close state flow naturally downstream via the channel.
> That way it will still work correctly if you start to use a buffered
> channel, for example.
>
> I don’t agree that returning the channel is a proper design, it breaks the
> encapsulation. Technically mine could use multiple channels behind the
> scenes - yours cannot.
>
> There's a trade-off here. By encapsulating in a method, you make it harder
> to wait for values in combination with other events (you'd need to create a
> goroutine to call your Read method and send the result to a channel, adding
> buffering, context switch overhead, and more state that needs to be
> explicitly shut down).
>
>

-- 
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/CAJhgaci57DOYHOk7C%3DjM8B6wenCxYv4JvNn2%3D13OGcd66Yc3EA%40mail.gmail.com.

[go-nuts] SFTPGo, the full featured and highly configurable SFTP server, nears 1.0 release

[Nicola Murino]

Hi all,

Since the initial SFTPGo public release I received a lot of feedbacks, 
mostly positive, thank you to everyone!

The following contributions were merged:

- Support for multiple public keys for a single user.
- Support for multiple private host keys.
- Improvements to the provided systemd service.
- Improvements to the docs. English is not my native language so pull 
requests that improve the README, fixing spelling errors and/or clarify 
concepts, are really appreciate.
- Support for bcrypt hashed passwords.

To solve some community raised concerns I added the following new features:

- Support for bblot key/value store as SQLite alternative for small 
installations or embedded systems (for example RPI). Some users had issues 
with SQLite dependency that is a CGO package and so it requires a compiler 
at build time. You can get/build SFTPGo setting GCO_ENABLED to 0, this way 
SQLite support will be disabled but PostgreSQL, MySQL and bbolt will work 
and you don't need a C compiler for building.
- More flexible configuration system. Some users were concerned about the 
initial JSON only configuration: for example JSON configuration files don't 
allow comments. We switched to viper (https://github.com/spf13/viper) so 
now configuration is a your choice: JSON, TOML, YAML, HCL, envfile are 
supported.

I added the following new features too:

- Support for configurable system commands and/or HTTP notifications on 
upload, download, delete or rename.
- Configurable atomic uploads support: files are uploaded to a temporary 
path and renamed to the requested path when the client ends the upload. 
Atomic mode avoids problems such as a web server that serves partial files 
when the files are being uploaded.
- Support for pbkdf2 hashed passwords. The default passwords hashing algo 
remains argon2id.
- CLI Rest API client to easy manage users and connections.
- Configurable SCP support: we have our own SCP implementation in pure Go 
since we can't rely on scp system command to proper handle permissions, 
quota and user's home dir restrictions.
- Other minor improvements.

We have now reached the first beta version! No new features or API 
breakages will happen before the first 1.0 release, only bugfixes.

If something does not work as expected for you please open an issue on the 
GitHub project page:

https://github.com/drakkan/sftpgo/issues

Binary releases for Linux, macOS and Windows are available:

https://github.com/drakkan/sftpgo/releases

Thank you for helping me to improve SFTPGo.

Yours sincerely,
Nicola

-- 
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/bab4face-4094-4069-834c-b613e541b7e0%40googlegroups.com.

[go-nuts] Re: Closed channel vs nil channel when writing

[T L]

On Sunday, September 1, 2019 at 12:03:58 PM UTC-4, clement auger wrote:
>
> hi,
>
> I am looking for further details and explanations about the various 
> behaviors
> associated with closed Vs nil channels.
>
> I already read 
> https://stackoverflow.com/questions/43616434/closed-channel-vs-nil-channel
> and other publications such as 
>
> https://medium.com/justforfunc/why-are-there-nil-channels-in-go-9877cc0b2308 
> (for example)
>
> They repeat the explanation of the behaviors the programmer will have to 
> deal with, 
> however they don't really explain the internal, nor the reasons of the 
> differences
> found with this example https://play.golang.org/p/4LuZ32gzWbu when 
> closing or niling the channel
>
> I wonder under which case it is useful to panic on write, Vs branching to 
> a default case within a select.
> Said differently what is the advantage of a panic Vs a syntax like ok := 
> mychan <- myval; if !ok { return "not wrote" }
>
> This happened while reading at T.L. in 
> https://groups.google.com/forum/#!topic/golang-nuts/lEKehHH7kZY
>
> *Yes, there are ways to handle the problem of uncertain number of senders, 
> but there are no simple ways.*
> *A mechanism must be designed to avoid any sender writing to a closed 
> channel.*
>
> thanks for anyone able to provide some details.
>


https://go101.org/article/channel.html 

-- 
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/8e676ea6-9565-4745-8052-2a4f677faf41%40googlegroups.com.

[go-nuts] Re: By passing go type check when performing bitwise operator

[T L]

On Sunday, September 1, 2019 at 2:03:37 PM UTC-4, Albert Tedja wrote:
>
>  I am trying to perform some bitwise operators, but Go is not letting me 
> because the mask is an uint and the values are int. Setting the mask to int 
> will break the code since I am shifting bits right and left and prefer the 
> prefix 0 when shifting right, and if I am not mistaken, Go does not have 
> >>>.
>
>
>
Not like Java, Go supports unsigned integers, so >>> is not essential in Go.
 

-- 
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/6ad7cb9a-4147-4bfa-808b-5cc4aa5db626%40googlegroups.com.

Re: [go-nuts] An old problem: lack of priority select cases

[T L]

On Sunday, September 1, 2019 at 2:05:49 PM UTC-4, Albert Tedja wrote:
>
> This is something I ran into a while back, and made a library for it, 
> though, I prefer not to spam the mailing list.  Feel free to send me a dm 
> and I'll send you a github link if you are interested.
>

It would be great if you can share the library here. I'm surely interested. 
And I think many other gophers also have interests. :)
 

>
> On Sunday, September 1, 2019 at 3:02:52 AM UTC-7, T L wrote:
>>
>>
>>
>> On Sunday, September 1, 2019 at 4:35:10 AM UTC-4, rog wrote:
>>>
>>>
>>>
>>> On Sat, 31 Aug 2019 at 10:02, T L  wrote:
>>>


 On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:
>
>
>
> On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>>
>> The reason you're wanting priority select is because you are shutting 
>> down the data channel preemptively, but you can wait for an 
>> acknowledgement 
>> from the run goroutine instead:
>>
>> https://play.golang.org/p/qSWluYy4ifl
>>
>>
> Your solution is clever. The Close method can be called multiple time 
> safely.
> Is there such a beautiful solution for multiple senders?
>  
>

 Translating a multi-senders problem to a single sender problem is the 
 only way I can get:
 https://play.golang.org/p/dAppUxP96g4

>>>
>>> The answer really depends on what you're actually trying to do. What are 
>>> the multiple senders? What's the actual problem you're trying to solve?
>>>
>>> I'd fairly sure you'll be able do what you want without requiring a 
>>> prioritised select, which is what this thread was about.
>>>
>>>   cheers,
>>> rog.
>>>
>>>
>> Yes, there are ways to handle the problem of uncertain number of senders, 
>> but there are no simple ways.
>> A mechanism must be designed to avoid any sender writing to a closed 
>> channel.
>>  
>>
>>>  

>
>> On Wed, 28 Aug 2019 at 18:06, T L  wrote:
>>
>>> The old thread: 
>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>
>>> Go channels are flexible, but in practice, I often encountered some 
>>> situations in which channel are hard to use.
>>> Given an example:
>>>
>>> import "math/rand"
>>>
>>> type Producer struct {
>>> data   chan int
>>> closed chan struct{}
>>> }
>>>
>>> func NewProducer() *Producer {
>>> p :=  {
>>> data:   make(chan int),
>>> closed: make(chan struct{}),
>>> }
>>> 
>>> go p.run()
>>> 
>>> return p
>>> }
>>>
>>> func (p *Produce) Stream() chan int {
>>> return p.data
>>> }
>>>
>>> func (p *Producer) run() {
>>> for {
>>> // If non-blocking cases are selected by their appearance 
>>> order,
>>> // then the following slect block is a perfect use.
>>> select {
>>> case(0) <-p.closed: return
>>> case p.data <- rand.Int():
>>> }
>>> }
>>> }
>>>
>>> func (p *Produce) Clsoe() {
>>> close(p.closed)
>>> close(p.data)
>>> }
>>>
>>> func main() {
>>> p := NewProducer()
>>> for n := p.Stream() {
>>> // use n ...
>>> }
>>> }
>>>
>>>
>>> If the first case in the select block in the above example has a 
>>> higher priority than the second one,
>>> then coding will be much happier for the use cases like the above 
>>> one.
>>>
>>> In short, the above use case requires:
>>> * for receivers, data streaming end is notified by the close of a 
>>> channel.
>>> * for senders, data will never be sent to closed channel.
>>>
>>> But, as Go 1 doesn't support priority select cases, it is much 
>>> tedious to implement the code
>>> satisfying the above listed requirements. The final implementation 
>>> is often very ugly and inefficient.
>>>
>>> Does anyone else also experience the pain?
>>>
>>> -- 
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%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 golan...@googlegroups.com.
 To view this discussion on the web visit