I think a more “standard” and certainly portable way to do this is with a tmp
file, and a rename/move at the end - along with a clean-up of tmp at
application start (if worried about crashes).
Using the proper file and process permissions on the tmp file - since you need
these to protect the
On Thu, Oct 11, 2018, at 18:48, Greg Saylor wrote:
> 1. Create a temporary file and squirrel away the file handle
> 2. Unlink the temporary file by name
> 3. Various functions would write stuff to the file
> 4. If the programs completes to some successful state, create a hardlink to
> the file
Thank you ! I will record what you said to my bookmark, also I will update
my question in Stackoverflow to let more people see your answer.
On Friday, October 12, 2018 at 10:02:55 AM UTC+8, Burak Serdar wrote:
>
>
>
> On Thu, Oct 11, 2018 at 7:51 PM iamwwc >
> wrote:
>
>> Did you mean ->
>>
On Fri, Oct 12, 2018, 2:31 PM Ian Lance Taylor wrote:
> On Thu, Oct 11, 2018 at 4:48 PM, Greg Saylor
> wrote:
> >
> > In other programming languages (this is specific to Linux/Unix systems),
> in
> > the past to ensure security in the even of a program crash, we would do
> > something like:
> >
So no matter if I say yes or no, both ways are bad? I think is not a very fair
way to argue.
Anyway, with the Ruby standard you can do either. The Ruby standard defines
that there are strictly conforming Ruby processors, which implement the
standard and conforming Ruby processors which may
On Thu, Oct 11, 2018 at 7:51 PM iamwwc wrote:
> Did you mean ->
> --
>
> For all typed object such as type *** struct, type *** func(), type
> int, their field cannot be redeclare? and cannot be used at left side of
> :=?
>
That is correct. A member field cannot
Did you mean ->
--
For all typed object such as type *** struct, type *** func(), type int,
their field cannot be redeclare? and cannot be used at left side of :=?
But what puzzles me is Golang docs said "at least one of the non-blank
variables is new.
The IDE is probably buggy, but you are wrong as well. The problem is
c.file, not err.
c.file cannot be on the left side of :=, it is not a name you can
redeclare. You have to write:
var err error
c.file, err= os.OpenFile...
or:
f, err:=os.OpenFile
c.file=f
On Thu, Oct 11, 2018 at 7:21 PM
On Thu, Oct 11, 2018 at 4:48 PM, Greg Saylor wrote:
>
> In other programming languages (this is specific to Linux/Unix systems), in
> the past to ensure security in the even of a program crash, we would do
> something like:
>
> 1. Create a temporary file and squirrel away the file handle
> 2.
Hi, everyone, I have in trouble about `short variable declaration`
Here is my codes snippet
package utils
import "os"
type FileController struct{
file *os.File}
func (c *FileController)OpenFile(path string)error{
c.file, err := os.OpenFile(path,os.O_CREATE | os.O_RDWR,0755)
I'm trying to learn how to safely use this asm, and I don't understand some
of the existing asm in the runtime package. From amd64.s:
TEXT runtime·procyield(SB),NOSPLIT,$0-0
MOVL cycles+0(FP), AX
My understanding of $0-0 is it's supposed to indicate the sizes of the
arguments, in this case
Thanks a bunch. I will give a serious "go".
Background - a tool that is command line now. Developed on Linux but
typical user in Windows. Just cross built for windows. Want to add a
minimal frontend - simple dialog. Being like a calculator - don't want to
have elaborate "install" procedures.
Hello,
In other programming languages (this is specific to Linux/Unix systems), in
the past to ensure security in the even of a program crash, we would do
something like:
1. Create a temporary file and squirrel away the file handle
2. Unlink the temporary file by name
3. Various functions
On Thu, 11 Oct 2018 06:15:16 +0200, you wrote:
>But that is not what I am getting at. Five years ago I was somewhat
>involved in the effort to make Ruby an ISO standard language. From the get
>go it was a largely bureaucratic effort. We specified a common sub set of a
>then already old version of
Hi,
Many thanks for that feedback! We have a long way to go for a full toolkit
but it's close to supporting basic applications.
Being designed for the Go language makes it so much quicker and easier to
develop with than other possible toolkit choices - and I'm not just saying
that from a biased
Hi,
As the Fyne toolkit depends on EFL you need to either install that yourself
or use our bootstrap tool[1]. If you have done one or other of those then
the error you are seeing is strange, I can try to help you off-list (if so
please provide info about OS etc).
I am trying to find ways to
Hi,
Great questions, thanks!
1. We can bundle in the libraries for Windows and for macOS - but on linux
probably not (unless your app is LGPL/GPL due to a licensing issue that I
have not found a better solution to). But distribution on Linux it is
normal to depend on external libraries :).
There
Quoting gary.willoug...@victoriaplumb.com (2018-10-11 10:38:38)
>Add it to this: https://github.com/golang/go/wiki/Go2GenericsFeedback
Already did (before posting to the list); it's at the top.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
Quoting Dean B (2018-10-11 14:58:01)
> Yeah that's why I was about how operators were the primary reason
> interfaces couldn't work out. Your proposal doesn't include operators,
> which was the reason interfaces aren't used. Syntax in Go is pretty
> important, which I imagine is the reason that
Yes, that's acceptable.
Le jeu. 11 oct. 2018 à 21:28, Sam Whited a écrit :
> On Thu, Oct 11, 2018, at 14:14, Thomas Bruyelle wrote:
> > That say, the downside is I have to keep both hash system, until all
> users
> > connect, which can take a long time, or can never happen!
>
> Or at least
On Thu, Oct 11, 2018, at 14:14, Thomas Bruyelle wrote:
> That say, the downside is I have to keep both hash system, until all users
> connect, which can take a long time, or can never happen!
Or at least until enough users have updated that you don't mind forcing the
rest to update their
That say, the downside is I have to keep both hash system, until all users
connect, which can take a long time, or can never happen!
Le jeu. 11 oct. 2018 à 21:08, Thomas Bruyelle a
écrit :
> This is brillant, thanks again Sam.
> I think I'll go for something like that. The argon2 hash can hold
This is brillant, thanks again Sam.
I think I'll go for something like that. The argon2 hash can hold the
version, just behind the mode, I could use that to distinguish old and new
hash.
$argon2i$*v=13*
$m=65536,t=3,p=4$SZ30vQfC522jpGssj92FkQ$xO4vPBrnd+DW/CbhiGjWW7u0s/nf7PcGUjS5bWQElYo
Le jeu.
On Thu, Oct 11, 2018, at 13:56, Thomas Bruyelle wrote:
> Unfortunately, because of that version mismatch, all my users' hashes were
> created with a version not supported by golang.org/x/crypto/argon2, so I
> can't migrate :/
I hope no problems are ever discovered in Argon2 then, it's generally
Wow indeed Sam you're completely right, with Version13 the test passes.
Thank you a lot for help.
Unfortunately, because of that version mismatch, all my users' hashes were
created with a version not supported by golang.org/x/crypto/argon2, so I
can't migrate :/
Le jeudi 11 octobre 2018
Yeah that's why I was about how operators were the primary reason
interfaces couldn't work out.
Your proposal doesn't include operators, which was the reason interfaces
aren't used. Syntax in Go is pretty important, which I imagine is the
reason that operators didn't work out. I'm working on
Wow indeed Sam you're completely right, with Version13 the test passes.
Thank you a lot for help.
Unfortunately, because of that version mismatch, all my users' hashes were
created with a version not supported by golang.org/x/crypto/argon2, so I
can't migrate :/
Le jeudi 11 octobre 2018
Hmm, I suppose I imagined having read a deeper reason than syntax :/.
That does seem like an incredibly shallow reason to introduce a whole
new non-orthogonal concept (I see others have attempted to tackle the
syntax issue, including yourself).
There are actually deeper difficulties than syntax
On Thu, Oct 11, 2018, at 11:37, Thomas Bruyelle wrote:
> I want to update my authentication code by using
> golang.org/x/crypto/argon2, as a replacement of
> github.com/tvdburgt/go-argon2 which uses the legacy C lib under the hood
> through CGO.
> The main benefit is of course to drop the
Hi all,
I want to update my authentication code by using
golang.org/x/crypto/argon2, as a replacement of
github.com/tvdburgt/go-argon2 which uses the legacy C lib under the hood
through CGO.
The main benefit is of course to drop the usage of CGO.
But I encounter a serious issue, with the same
I've encountered similar behavior with testdata directories within GOPATH,
when not in module-aware mode.
I found this thread while searching for answers, so I'm linking the issue I
just
created in case anyone else runs into the same bug:
https://github.com/golang/go/issues/28155
On Wednesday,
Looking at the proposal, operators are the reason that contracts are used
rather than interfaces.
Why not use interfaces instead of contracts?
> *The interface method syntax is familiar.* *Writing contract bodies
> with x + x is ordinary Go syntax, but it*
> *is stylized, repetitive, and looks
We are trying to use Go-Modules
We have reusable repo : "github/mycompany/funcs" many repo's use this,
example : "github/mycompany/eCom/basket.go"
A new ticket says : "basket should support export to xls" .
In order to do that, we want to :
1. Add funcs.go a function
Add it to this: https://github.com/golang/go/wiki/Go2GenericsFeedback
On Wednesday, 10 October 2018 22:14:35 UTC+1, Ian Denhardt wrote:
>
> I've seen a lot of folks expressing the sentiment "we should just use
> interfaces instead of this new contract thing." Most of the discussion
> I've seen
Historically Go developers resist any attempts to add goroutine-local
storage. Unless they change their opinion, this proposal is DOA.
--
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
Ok, that's an interesting line of investigation - I'll take a look into
that and let you know if I find anything.
Thanks
Nathan
On Thu, 11 Oct 2018 at 13:04, Robert Engels wrote:
> It is not necessarily the open doc that is freeing the memory, could be
> the close doc as well - meaning it
It is not necessarily the open doc that is freeing the memory, could be the
close doc as well - meaning it needs the file and opt reference while it is
open. Probably not file, but possible opt. The other thing are you sure that
the opt doesn’t contain a reference that is freed to early...
>
Hi,
That was at least a working theory there for a while; that perhaps the open
document was doing some freeing of the memory before it returned. The
reason we discounted that was some docs the defer func() free works fine.
It could be a weird bug in that library, and I'm still considering
Are you sure the document is not doing the free of the file and the opt when it
is destroyed? It might need those references beyond the function scope.
> On Oct 11, 2018, at 3:52 AM, ndav...@turnitin.com wrote:
>
>
> package main
>
> /*
> #cgo CFLAGS: -g -Wall -I/usr/local/include
> #cgo
Ok, to give some update apparently our Makefile uses `build -i` where it
tries to install package dependency.
This explains the conflicted `.a` files.
It was there before GOCACHE to speed up `go build`
Thanks for the help!
On Wednesday, October 10, 2018 at 9:40:28 PM UTC+2, Yulrizka wrote:
>
package main
/*
#cgo CFLAGS: -g -Wall -I/usr/local/include
#cgo LDFLAGS: -L/usr/local/lib -lm -lstdc++
#include
#include
#include
#include
// tet_pcos_get_string wraps the TET_pcos_get_string so we can use it in
Go, cgo does not support
// variadic args, this is the solution
char*
On Thu, Oct 11, 2018 at 10:15 AM wrote:
> What I am wondering is why the closure approach does not work?
ISTM it should work. Please post a full, standalone reproduction code here
or at the issue tracker, thanks.
--
-j
--
You received this message because you are subscribed to the Google
Hi all,
Apologies if this has already been asked and answered elsewhere, I took a
look and couldn't find anything.
I have a simple cgo program that looks a little something like:
func doTheCGo(){
f := C.CString("/path/to/file.ext")
o := C.CString("useful values for c call")
defer
43 matches
Mail list logo
