[go-nuts] Re: Secure password hashing algorithm in go.

2019-01-06 Thread ssrs
Have you get a solution? i have the same problem too, golang is not 
compatible with java SecretKeyFactory

在 2015年12月2日星期三 UTC+8上午7:47:22,Jeff写道:
>
> I'm am looking to implement in go, the following code written in Java.
> I have not  been able to find any apis or modules for this.  Is it 
> possible to achieve this, did I just not the right resources? How are we 
> doing secure hashing in go?
> Thanks.
>
>   /**
>  * Encrypts the given password with a salt
>  *
>  * @param password The password string to be encrypted
>  * @param salt A randomly generated salt for the password 
> encryption
>  * @return The byte[] containing the encrypted password
>  * @throws NoSuchAlgorithmException
>  * @throws InvalidKeySpecException
>  */
> public static byte[] getEncryptedPassword(String password, byte[] salt)
> throws NoSuchAlgorithmException, InvalidKeySpecException {
> String algorithm = "PBKDF2WithHmacSHA1";
> int derivedKeyLength = 160;
> // The NIST recommends at least 1,000 iterations:
> // 
> http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf
> int iterations = 2;
>
> KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 
> iterations, derivedKeyLength);
>
> SecretKeyFactory f = SecretKeyFactory.getInstance(algorithm);
>
> return f.generateSecret(spec).getEncoded();
> }
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] gotcha: don't take the address of a for-range loop variable

2019-01-06 Thread Ian Lance Taylor
On Sun, Jan 6, 2019 at 10:38 PM  wrote:
>
> https://play.golang.org/p/NnACN5fLPT3
>
> I was taking the address of the for-loop variable ("" in the example above) 
> and was surprised to find that all my items pointed the same address. I 
> thought I had found most of the Golang gotchas by now, but this is a new one 
> to me.

This is related to https://golang.org/doc/faq#closures_and_goroutines
.  But in general in a range loop the value is copied from the range
source to the loop variable.  Your sample code seems to think that the
loop variable is a reference to the slice element, but it's not; it's
a copy.  It's not surprising that the address of that copy, the loop
variable v, is always the same.

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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] gotcha: don't take the address of a for-range loop variable

2019-01-06 Thread buchanae
https://play.golang.org/p/NnACN5fLPT3

I was taking the address of the for-loop variable ("" in the example 
above) and was surprised to find that all my items pointed the same 
address. I thought I had found most of the Golang gotchas by now, but this 
is a new one to me.

-A

-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: How to make the first character in a string lowercase?

2019-01-06 Thread dhananjay Verma
thank you

On Tue, 30 Oct 2018 at 00:21 messju mohr  wrote:

> I don't know if that is "the easiest", but I would do something like this:
> https://play.golang.org/p/DOhP5kc8rO4
>
> On Sun, Oct 28, 2018 at 11:35:33PM -0700, dhananja...@gmail.com wrote:
> >https://play.golang.org/p/vFW8NxzL_hv
> >this will work fine
> >On Saturday, 24 November 2012 16:21:23 UTC+5:30, Nikolai wrote:
> >
> >  Hi!
> >  What is the easiest way to make a string "LikeThis" --> "likeThis"?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/WfpmVDQFecU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] [Ann] create full github release from command line, not just a tag

2019-01-06 Thread Justin Israel
I've been using goreleaser  so far, to publish
github releases with cross-compiled assets. I am not familiar with the
wireframe project though. Do they share some overlap?

On Mon, Jan 7, 2019 at 5:50 PM Tong Sun  wrote:

> IIRC, github used to create full releases each time you push a git
> tag, but now it only creates tags, not releases. After pushing a git tag,
> people need to go to GitHub UI, find created tag, press "Edit tag", change
> nothing and press "Publish release", then they'll get full release and
> event.
>
> But I much prefer to be able to create full Release  with title,
> description, or assets from the command line.
> So I was wondering if there is any way to "Publish release" from a command
> line.
> and it turns out that now creating releases are via API:
> https://developer.github.com/v3/repos/releases/#create-a-release
>
>
> So I added the feature to easygen/wireframe, to "Publish release" from
> command line. The details can be found at
>
> https://github.com/go-easygen/wireframe#github-create-release---create-release-in-github
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] [Ann] create full github release from command line, not just a tag

2019-01-06 Thread Tong Sun
IIRC, github used to create full releases each time you push a git tag, but 
now it only creates tags, not releases. After pushing a git tag, people 
need to go to GitHub UI, find created tag, press "Edit tag", change nothing 
and press "Publish release", then they'll get full release and event. 

But I much prefer to be able to create full Release  with title, 
description, or assets from the command line. 
So I was wondering if there is any way to "Publish release" from a command 
line. 
and it turns out that now creating releases are via API:
https://developer.github.com/v3/repos/releases/#create-a-release


So I added the feature to easygen/wireframe, to "Publish release" from 
command line. The details can be found at
https://github.com/go-easygen/wireframe#github-create-release---create-release-in-github


-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] C++ 11 to Golang convertor

2019-01-06 Thread Eric S. Raymond
Jan Mercl <0xj...@gmail.com>:
> I would like to learn more about that strategy, if possible.

Diggingpaper by two French guys on how astoundingly perverse parsing C
can get...Perry Metzger pointed me at it...

Ah, here it is:

A simple, possibly correct LR parser for C11

http://gallium.inria.fr/~fpottier/publis/jourdan-fpottier-2016.pdf

Perry is adopting their parsing strategy for his codewalker.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] C++ 11 to Golang convertor

2019-01-06 Thread Jan Mercl
I would like to learn more about that strategy, if possible.

On Sun, Jan 6, 2019, 22:38 Eric S. Raymond  wrote:

>
> Having studied the problem, the most serious blocker is an ambiguity
> between
> typedefs and variable names in some contexts. And there exists a good
> strategy for resolving those.
> --
>
>
>
> --

-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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] C++ 11 to Golang convertor

2019-01-06 Thread Eric S. Raymond
Jan Mercl <0xj...@gmail.com>:
> I'm afraid that a lot, if not most of existing C code, even when simple,
> clean and preprocessor-abuse-free, cannot be parsed before preprocessing.

Having studied the problem, the most serious blocker is an ambiguity between
typedefs and variable names in some contexts. And there exists a good
strategy for resolving those.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: What are the reasonable reasons to use pointers?

2019-01-06 Thread Michael Jones
My hardest-to-debug ever bug was because of this.

Because FORTRAN is pass by reference, the compiler must do something
special for the four in "SQRT(4.0)" -- and the PDP-10 (TOPS-10) FORTRAN
compiler used a global literal table for this. I had a function that
modified an argument, erroneously passed a literal  number in, the compiler
housed the number (may have been a 2)  in the the gkobal table, and after
that, all the "2" arguments in my program were invisibly changed.

I was 16 or 17, was an explorer scout at BTL, and was quick to embrace 6th
edition UNIX and ed over TOPS-10 and TECO (ignoring the brilliantly named
SOS, "son  of stopgap")

On Sun, Jan 6, 2019 at 12:15 PM Rob Pike  wrote:

> Fortran depends heavily on pointers for its semantics: It is a call by
> reference language. You just don't see them explicit in the language and
> you have no control over whether an argument will be modified by a
> procedure.
>
> -rob
>
>
> On Mon, Jan 7, 2019 at 5:13 AM Victor Giordano 
> wrote:
>
>> i guess that a good question to start is there is a language that doesn't
>> relays on pointer. Fortran as someone says below, may be a good example how
>> things get done using values only. I programmed in COBOL in the universitiy
>> and don't recall to use pointers. There aren't necessary at all,
>> nevertheless they provide inderection or referrals that allow to express
>> things more efficiently in certain scenarios. You could write an entire
>> program witout using pointers,i guess, that call is in the cook chief!.
>> Nice topic to talk.
>>
>>
>> El martes, 1 de enero de 2019, 8:34:34 (UTC-3), 伊藤和也 escribió:
>>>
>>> What are the reasonable reasons to use pointers? Are pointers neseccary?
>>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] C++ 11 to Golang convertor

2019-01-06 Thread Jan Mercl
On Sun, Jan 6, 2019 at 2:27 PM Eric S. Raymond  wrote:

> But for both of them our intended strategy is *not* to preprocess.
> Instead, we're willing to accept that some abuses of the preprocessor
> need to be punted to a human, but treat other uses as part of the
> parse tree.

I'm afraid that a lot, if not most of existing C code, even when simple,
clean and preprocessor-abuse-free, cannot be parsed before preprocessing.

-- 

-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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: What are the reasonable reasons to use pointers?

2019-01-06 Thread Rob Pike
Fortran depends heavily on pointers for its semantics: It is a call by
reference language. You just don't see them explicit in the language and
you have no control over whether an argument will be modified by a
procedure.

-rob


On Mon, Jan 7, 2019 at 5:13 AM Victor Giordano 
wrote:

> i guess that a good question to start is there is a language that doesn't
> relays on pointer. Fortran as someone says below, may be a good example how
> things get done using values only. I programmed in COBOL in the universitiy
> and don't recall to use pointers. There aren't necessary at all,
> nevertheless they provide inderection or referrals that allow to express
> things more efficiently in certain scenarios. You could write an entire
> program witout using pointers,i guess, that call is in the cook chief!.
> Nice topic to talk.
>
>
> El martes, 1 de enero de 2019, 8:34:34 (UTC-3), 伊藤和也 escribió:
>>
>> What are the reasonable reasons to use pointers? Are pointers neseccary?
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] [ANN] go-resty v1.11.0 released - Simple HTTP and REST client library

2019-01-06 Thread Jeevanandam M.
Production Version : gopkg.in/resty.v1
godoc  : https://godoc.org/gopkg.in/resty.v1

Changelog:

Enhancements

  * Add Content-Type application/json-rpc into Auto Unmarshaling support 
#203 @jeevatkm
  * Add Context() method into Request and consider logging prerequesthook 
updates in the debug log #206 @jeevatkm

Cheers,
Jeeva

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: What are the reasonable reasons to use pointers?

2019-01-06 Thread Victor Giordano
i guess that a good question to start is there is a language that doesn't 
relays on pointer. Fortran as someone says below, may be a good example how 
things get done using values only. I programmed in COBOL in the universitiy 
and don't recall to use pointers. There aren't necessary at all, 
nevertheless they provide inderection or referrals that allow to express 
things more efficiently in certain scenarios. You could write an entire 
program witout using pointers,i guess, that call is in the cook chief!.
Nice topic to talk.


El martes, 1 de enero de 2019, 8:34:34 (UTC-3), 伊藤和也 escribió:
>
> What are the reasonable reasons to use pointers? Are pointers neseccary?
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] C++ 11 to Golang convertor

2019-01-06 Thread Eric S. Raymond
andrey mirtchovski :
> > It would sure help if Go had sum types. Has there been any discussion
> > of adding these?
> 
> one of many, but has links to others: 
> https://github.com/golang/go/issues/19412

Thanks.  My experience report on the reposurgeon port will point at yet another
use case for sum types that I think is significant - enabling compile-time
checking for limited polymorphism in an array of events.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] C++ 11 to Golang convertor

2019-01-06 Thread andrey mirtchovski
> It would sure help if Go had sum types. Has there been any discussion
> of adding these?

one of many, but has links to others: https://github.com/golang/go/issues/19412

-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] C++ 11 to Golang convertor

2019-01-06 Thread Eric S. Raymond
Andy Balholm :
> A good translation from C to Go needs to look as much like the original, 
> un-preprocessed C source as possible. But a powerful translation tool will 
> probably need to preprocess, parse, and typecheck the code, while keeping 
> track of the source location that everything corresponds to—and then use that 
> information to guide the translation.

Perry and I have two different target languages in mind.  Perry's
target language is basically a repaired C - type-safe, almost
upward-compatible. He and I have the same strategic goal - draining
the swamp of old, leaky C code - we're just betting on slightly
different ways to do it. We intend to cooperate as much as possible.

But for both of them our intended strategy is *not* to preprocess.
Instead, we're willing to accept that some abuses of the preprocessor
need to be punted to a human, but treat other uses as part of the
parse tree.

For example if you have a set of #defines each of which expands to a
syntactically well-formed C expression. it seems clear to us that the
right thing is to recognize this and map them to const and func
declrations, checking for and throwing an error on capture of any
identifier that isn't a defined global.

We're willing to throw an error on that, or on syntactically
ill-formed macro expansion because we're not aiming for a completely
perfect mechanized trannlation.  We know this is impossible in the
general case.  Instead, our goal is just to get punt-to-a-human
frequency low enough that very large translations are practical with a
relatively small amount of human effort.

We don't mind requiring users to make point changes to C codebases to
get them through the translator when the code was horrible in C in
the first place.

As for unions, we'll do the stupidest possible thing that can work -
translate them to structs and throw a warning.  If the union was just
a space optimization, that's it. If not, then a human must intervene.

(Both projects are contingent on funding we don't yet have, alas.
It's not like we need to buy a cyclotron or anything but we do need to
be able to eat and pay rent for a couple years each.)

It would sure help if Go had sum types. Has there been any discussion
of adding these?
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
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.
For more options, visit https://groups.google.com/d/optout.