[go-nuts] Do I need to use runtime.KeepAlive in this case?

[Cholerae Hu]

package main

// void a(long *p) {}
import "C"

import (
"unsafe"
)

//go:noinline
func b() {
x := int64(0)
C.a((*C.long)(unsafe.Pointer()))
// do something without x
}

func main() {
b()
}

x should be considered unreachable after C.a . If x is something allocated 
on heap, do I need to use runtime.KeepAlive(x) to make sure x will not be 
garbage collected?

-- 
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: I am starting Golang and I am looking for a example to Login, Logout, Signup..

[grandagon]

Have you checked this?  https://gist.github.com/mschoebel/9398202

-- 
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: Deferring a close that can fail

[David Collier-Brown]

Hmmn, Donald Knuth would not have liked this (;-))

Knuthput, if I remember correctly, didn't have "fail on close()" semantics.
>
>
--dave

-- 
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] [security] Vulnerability in golang.org/x/crypto/salsa20

[Filippo Valsorda]

Hello gophers, Commit b7391e95

fixes a vulnerability in the amd64 implementation of the
golang.org/x/crypto/salsa20 and golang.org/x/crypto/salsa20/salsa packages
that affects large message sizes or high counter values. If more than 256
GiB of keystream is generated, or if the counter otherwise grows greater
than 32 bits, the amd64 implementation will first generate incorrect
output, and then cycle back to previously generated keystream. Repeated
keystream bytes can lead to loss of confidentiality in encryption
applications, or to predictability in CSPRNG applications. The issue might
affect uses of golang.org/x/crypto/nacl with extremely large messages.
Architectures
other than amd64 and uses that generate less than 256 GiB of keystream for
a single salsa20.XORKeyStream
 invocation are
unaffected. The vulnerable code is derived from the amd64-xmm5 and
amd64-xmm6 implementations that are distributed with SUPERCOP
, NaCl  and
at https://cr.yp.to/snuffle.html. The issue is present in those upstreams,
but is not considered a problem by their author because of the policy at
https://nacl.cr.yp.to/valid.html, and because support for counters larger
than 32 bits is an incomplete experiment. We attach a patch that applies to
the amd64-xmm5 and amd64-xmm6 salsa20.s files for any downstream that might
want to fix this issue. This issue was discovered and reported by Michael
McLoughlin. Cheers, 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.
For more options, visit https://groups.google.com/d/optout.


salsa20.s.diff
Description: Binary data

Re: [go-nuts] Re: Deferring a close that can fail

[David Collier-Brown]

Looks as if "Close()-like things" all fall into two categories

   - the usual horrid one, in which you can discover too late something 
   didn't complete, or
   - the trivial case, in which the pre-close operations are transactional 
   and xxx.Close() only ever returns nil

Which means I have to make my work transactional. In this case I did, but 
I'm lazy and would really really prefer Tony Hoare to have done that. 

As usual, I ended up drawing DFAs and boring my colleagues to tears 
reviewing the correctness of the code that wrote output (to influx) and got 
a nil error back before it marked the input (from Kafka) as having been 
read.

That and a bunch of code-reading allows me to treat this (one! singular! 
individual!) case of a failed close as a harmless horrible thing. A thing 
that requires me to rerun the program, so that it can re-read anything that 
I haven't marked as committed.

Sigh. 

Safety-critical system development is cool, but it's not *fun* unless you 
like brain pain. Or writing proofs in prolo(n)g.
 
--dave (admitted nerd, but not masochist) c-b

>

-- 
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: Deferring a close that can fail

[Manlio Perillo]

On Wednesday, March 20, 2019 at 10:53:44 PM UTC+1, Kurtis Rader wrote:
>
> On Wed, Mar 20, 2019 at 2:08 PM Manlio Perillo  > wrote:
>
>> Note from the Linux close documentation:
>>
>> Not checking the return value of close() is a common but nevertheless 
>> serious programming error. It is quite possible that errors on a previous 
>> write (2) operation are first 
>> reported at the final close(). Not checking the return value when closing 
>> the file may lead to silent loss of data. This can especially be observed 
>> with NFS and with disk quota.
>>
>> A successful close does not guarantee that the data has been successfully 
>> saved to disk, as the kernel defers writes. It is not common for a file 
>> system to flush the buffers when the stream is closed. If you need to be 
>> sure that the data is physically stored use fsync 
>> (2). (It will depend on the disk 
>> hardware at this point.)
>>
>
> There are only two reasons to check if close() has failed:
>
> 1) Checking if errno == EBADF if that indicates a logic error in the 
> program because the fd should have been valid at the time of the close().
>
> 2) To log a message about an unexpected close() failure.
>
>
And I suggest to use something like:

defer fun() {
if err := xxx.Close(); err != nil {
log.Printf("here: close(): %v", err)
}()


But thinking you can do anything about the other failure modes, especially 
> EINTR, is mistaken. See
>
> https://lwn.net/Articles/576478/
> http://austingroupbugs.net/view.php?id=529
> https://sourceware.org/bugzilla/show_bug.cgi?id=14627
>
>
On UNIX systems, Go Close() don't check for EINTR.
HPUX is not currently supported by Go, but what about other systems?


Manlio Perillo 

-- 
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: Deferring a close that can fail

[Kurtis Rader]

On Wed, Mar 20, 2019 at 2:08 PM Manlio Perillo 
wrote:

> Note from the Linux close documentation:
>
> Not checking the return value of close() is a common but nevertheless
> serious programming error. It is quite possible that errors on a previous
> write (2) operation are first reported
> at the final close(). Not checking the return value when closing the file
> may lead to silent loss of data. This can especially be observed with NFS
> and with disk quota.
>
> A successful close does not guarantee that the data has been successfully
> saved to disk, as the kernel defers writes. It is not common for a file
> system to flush the buffers when the stream is closed. If you need to be
> sure that the data is physically stored use fsync
> (2). (It will depend on the disk
> hardware at this point.)
>

There are only two reasons to check if close() has failed:

1) Checking if errno == EBADF if that indicates a logic error in the
program because the fd should have been valid at the time of the close().

2) To log a message about an unexpected close() failure.

But thinking you can do anything about the other failure modes, especially
EINTR, is mistaken. See

https://lwn.net/Articles/576478/
http://austingroupbugs.net/view.php?id=529
https://sourceware.org/bugzilla/show_bug.cgi?id=14627

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

[go-nuts] Re: Deferring a close that can fail

[Manlio Perillo]

On Wednesday, March 20, 2019 at 12:57:51 AM UTC+1, David Collier-Brown 
wrote:
>
> It's a known bad thing to defer a close for anything buffered, as 
> discussed at https://www.joeshaw.org/dont-defer-close-on-writable-files/
> but some constructs lack a Sync() call.
>
>
Note from the Linux close documentation:

Not checking the return value of close() is a common but nevertheless 
serious programming error. It is quite possible that errors on a previous 
write (2) operation are first reported 
at the final close(). Not checking the return value when closing the file 
may lead to silent loss of data. This can especially be observed with NFS 
and with disk quota.

A successful close does not guarantee that the data has been successfully 
saved to disk, as the kernel defers writes. It is not common for a file 
system to flush the buffers when the stream is closed. If you need to be 
sure that the data is physically stored use fsync 
(2). (It will depend on the disk 
hardware at this point.)

> [...]


Manlio Perillo

-- 
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] Deferring a close that can fail

[David Collier-Brown]

>
> On Wednesday, March 20, 2019 at 1:44:23 AM UTC-4, Shulhan wrote:

Any Close on file or connection should be called only if only the 
> call to Open function or method success. 
>
> You have two options here: either you remove the panic when Close is 
> error (only logging it) or call Close only if Open is success.  I 
> usually prefer the latter. 
>
> -- 
> { "github":"github.com/shuLhan", "site":"kilabit.info" } 
>

You and I agree: my code snippit will panic if the open fails,  or if (the 
open suceeds && the close fails)

--dave 

-- 
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] Deferring a close that can fail

[Robert Engels]

The update statement is fine as long as any data sources participate in an XA 
transaction. 

This is bar the simplest solution but may not meet performance constraints 
which is why people use other techniques. 


> On Mar 20, 2019, at 4:13 PM, David Collier-Brown  wrote:
> 
> 
> 
> 
> 
> 4:12 PM (less than a minute ago)
> 
> 
>> Any Close on file or connection should be called only if only the 
>> call to Open function or method success. 
>> 
>> You have two options here: either you remove the panic when Close is 
>> error (only logging it) or call Close only if Open is success.  I 
>> usually prefer the latter. 
>  
> You and I agree: my code snippit will panic if the open fails,  or if (the 
> open suceeds && the close fails)
> 
> --dave
>> 
> 
> -- 
> 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.

Re: [go-nuts] Deferring a close that can fail

[David Collier-Brown]

4:12 PM (less than a minute ago)

> Any Close on file or connection should be called only if only the 
> call to Open function or method success. 
>
> You have two options here: either you remove the panic when Close is 
> error (only logging it) or call Close only if Open is success.  I 
> usually prefer the latter. 
>
 
You and I agree: my code snippit will panic if the open fails,  or if (the 
open suceeds && the close fails)

--dave

>
>

-- 
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] Deferring a close that can fail

[David Collier-Brown]

>
> Any Close on file or connection should be called only if only the 
> call to Open function or method success. 
>
> You have two options here: either you remove the panic when Close is 
> error (only logging it) or call Close only if Open is success.  I 
> usually prefer the latter. 
>
 
You and I agree: my code snippit will panic if the open fails,  or if (the 
open suceeds && the close fails)

--dave

-- 
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] boringcrypto+fipsonly: way more strict than fips 140-2?

[Wojciech S. Czarnecki]

On Wed, 20 Mar 2019 03:10:37 -0700 (PDT)
Riccardo Raccuia  wrote:

> My intent is not to start a debate on any cipher/mode/signature algs' 
> weaknesses but merely to understand some the limitations that are enforced 
> when using the "crypto/tls/fipsonly" package of the famous boringcrypto 
> fork of golang.

In short: FIPS is all about about bureaucracy, "US National Security"
and $$$ that follows. Real soundness and code security is important
but is of second thought to above.

https://blog.ipswitch.com/fips-validated-vs-fips-compliant

Validated is exact version of boringcrypto: 24e.d6f5
It will not lose its validation even if it has a bug.
If it will fix this bug its validation is lost.

> Really, I understand and agree that we're much better off without CBC and 
> SHA1, although sometimes one might not have a choice.

If you need something that NIST allows you are free to make NIST
application for your own changes / configuration of an open source software.
It was done eg. for Crypto++ in the past.

> Does anyone know the reasons behind the much stricter limitations compared 
> to FIPS 140-2 when in fipsonly mode?

Adam Langley is a well recognized expert in the field. I trust in his decisions.
 
> Thanks !!

Hope this helps.

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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] Go command support for "make"

[Ian Lance Taylor]

On Wed, Mar 20, 2019 at 7:01 AM Paul Jolly  wrote:
>
> > test $(go list -f '{{.Stale}}' internal/package$) = "true"
>
> Does .Stale still have meaning/is it still accurate in a build cache world?

I doubt it, but I'm not sure the original question has any meaning in
that world.  In a build cache world there's no reason to ever ask
whether something is up to date.  You just unconditionally run
whatever command is required to make it up to date.

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.

Re: [go-nuts] Go command support for "make"

[Paul Jolly]

Hi Ian,

> test $(go list -f '{{.Stale}}' internal/package$) = "true"

Does .Stale still have meaning/is it still accurate in a build cache world?

-- 
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] Go command support for "make"

[Ian Lance Taylor]

On Tue, Mar 19, 2019 at 10:05 PM Lucio  wrote:
>
> I'm hoping this already has an answer, rather than require additional 
> features. I also don't expect this to be a popular request, but I do consider 
> its merits as greater than the disadvantages, so here goes.
>
> Efforts to eliminate the use of the Unix "make" command by producing a vastly 
> more modern "go" command have been valiant and largely successful, in my 
> opinion, at least, but I personally come up short on a regular basis, perhaps 
> because I don't really know the "go" command as intimately as I ought to.
>
> As soon as I need a slightly unusual target in a development environment, I 
> am prone to add an entry in a Makefile (actually "mkfile" as most of my 
> development occurs in a Plan 9 environment), but I come against a barrier: I 
> need to determine not only if local modules are more recent than the target, 
> but also if related modules in imported packages are fresher than the target.
>
> I don't mind having to list the packages involved, ideally by the label I use 
> within the code for each of them, that is acceptable. What I don't know how 
> to do and suspect may need a small enhancement to the "go" command, is to 
> reach into each package (directory) and verify that it is or is not reason to 
> rebuild the target.
>
> What I just realised is that my Makefile/mkfile-foo isn't sufficient to *do 
> something* with such information, but at this point I'm willing to cross that 
> bridge when I come to it. For now, having a "go status infernal/package", 
> say, even if it provides a single reply: "updated=yes", for example (someone 
> here will think of a better approach, no doubt) will be a useful start. 
> Obviously, the command is run in a directory other than the one being 
> verified.
>
> Suggestions, from anyone, on how to do something like that? I don't mind 
> getting my fingers dirty, but I'm hoping for the direction that makes such a 
> facility as useful to as many Gophers as possible.

At first glance "go status internal/package" sounds like

test $(go list -f '{{.Stale}}' internal/package$) = "true"

If that doesn't work, can you explain what additional functionality
you're looking for?

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.

Re: [go-nuts] Deferring a close that can fail

[Jesper Louis Andersen]

On Wed, Mar 20, 2019 at 12:57 AM David Collier-Brown 
wrote:

> Is there an idiomatic way to address this? I ended up reading influxDB
> code and doing all sorts of deranged safety-critical-system DFAs to
> reassure myself this will actually work, but every time I do that, my brain
> hurts!
>
>
Not in general, I think.

Suppose we have something along the lines of

UPDATE weather SET observations = observations + 1;

We exec this statement to the database, and we issue a COMMIT. But before
we receive the result of that commit, the program fails, aborts and closes
the connection. At this point whether or not the above statement was
executed is unknown. The database is still consistent in both states, but
we have no real way of knowing, save if we make a unique tag for each
observation and test if the observation was admitted later on. If you then
reread the input and commit it in the same way, you have just counted the
observation twice, which is almost surely not what you want to do.

The problem is akin to having a buffer with written data, but before having
synced it to disk.

The underlying problem is that if you have ephemeral data handling, such as
overwriting data or having a counter, you are throwing away information.
And in general, such computation is not reversible which leads to all sorts
of fun things. If you have persistent data, such as an append-only log,
then you are able to stitch together what happened and then remedy the
problem. It also suggests it is generally safer to write a new file to disk
and then eventually move said file on top of the existing one.

In short, making this a safe semantics requires one to look at the specific
problem at hand and make sure there is a way to recover. You are generally
guaranteed a point-in-time consistent state of your system, if the database
is worth its salt. But from there on, you are on your own to ensure things.

-- 
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] [ANN] Fyne reaches 1.0

[Andrew Williams]

Hi Nick,

Thanks for your message.
As far as I can tell you cannot use OpenGL without Cgo or a native binding 
- like you say it would require reimplementing OpenGL in Go.
We could, however, provide alternative drivers. The Shiny project has pure 
Go drivers for Windows and Linux which avoid OpenGL so that it can avoid 
Cgo.
It would be possible to do the same with Fyne, if someone had the time, but 
of course you would lose potential benefits like hardware acceleration...

Best of luck,
Andrew

On Wednesday, 20 March 2019 11:06:28 UTC, Nick wrote:
>
> Quoth Andrew Williams: 
> > I just wanted to drop a quick announcement here for anyone watching the 
> > progress of Fyne - we have reached 1.0! We now have a stable and 
> performant 
> > base API. 
>
> This looks great, congratulations on reaching 1.0! I had very 
> vaguely been aware of this project, but reading more of your 
> documentation today I'm very impressed and excited to try it out. 
>
> One question, from somebody new-ish to Go: is there scope to have 
> the OpenGL stuff not rely on CGo, and be called purely with native 
> Go? Or would that essentially mean reimplementing full OpenGL stacks 
> for each platform? I'm sure you have good reasons for doing it the 
> way you are, I'm just keen to learn! 
>
> Congratulations to all involved once again, and I look forward to 
> using Fyne soon :) 
>
> Nick 
>

-- 
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] boringcrypto+fipsonly: way more strict than fips 140-2?

[Riccardo Raccuia]

Hello golang-nuts, 

I haven't found a single discussion about this so out of pure curiosity i'm 
going to try and shoot the question.

My intent is not to start a debate on any cipher/mode/signature algs' 
weaknesses but merely to understand some the limitations that are enforced 
when using the "crypto/tls/fipsonly" package of the famous boringcrypto 
fork of golang.

>From src/crypto/tls/boring.go 

: 

// default FIPSCipherSuites is the FIPS-allowed cipher suites,
// in preference order (most preferable first).
var defaultFIPSCipherSuites = []uint16{
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384,
}

Although the boringcrypto's NIST certificate 

 
mentions a number of approved AES modes (e.g. CBC), the GCM mode seems is 
the only mode that will be allowed for TLS 1.2.

Also on signature algorithms, this is what we find later in the same source 
file: 

// supportedSignatureAlgorithms returns the supported signature algorithms.
// It knows that the FIPS-allowed ones are all at the beginning of
// defaultSupportedSignatureAlgorithms.
func supportedSignatureAlgorithms(version uint16) []SignatureScheme {
all := defaultSupportedSignatureAlgorithms
if version < VersionTLS13 {
all = defaultSupportedSignatureAlgorithmsTLS12
}
if !needFIPS() {
return all
}
i := 0
for i < len(all) && all[i] != PKCS1WithSHA1 {
i++
}
return all[:i]
}

PKCS1WithSHA1 is still a perfectly valid FIPS 140-2 

 
signature algorithm but here it is being explicitly excluded from the 
supported algs.

Really, I understand and agree that we're much better off without CBC and 
SHA1, although sometimes one might not have a choice.

Does anyone know the reasons behind the much stricter limitations compared 
to FIPS 140-2 when in fipsonly mode?

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

Re: [go-nuts] [ANN] Fyne reaches 1.0

[Nick]

Quoth Andrew Williams: 
> I just wanted to drop a quick announcement here for anyone watching the 
> progress of Fyne - we have reached 1.0! We now have a stable and performant 
> base API.

This looks great, congratulations on reaching 1.0! I had very 
vaguely been aware of this project, but reading more of your 
documentation today I'm very impressed and excited to try it out.

One question, from somebody new-ish to Go: is there scope to have 
the OpenGL stuff not rely on CGo, and be called purely with native 
Go? Or would that essentially mean reimplementing full OpenGL stacks 
for each platform? I'm sure you have good reasons for doing it the 
way you are, I'm just keen to learn!

Congratulations to all involved once again, and I look forward to 
using Fyne soon :)

Nick

-- 
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] Fyne reaches 1.0

[Andrew Williams]

I just wanted to drop a quick announcement here for anyone watching the 
progress of Fyne - we have reached 1.0! We now have a stable and performant 
base API.

Moving forward we are excited to add new features and enhancements that 
have been requested over the months of development.


The main features of Fyne at this time are:

   - Canvas API (rect, line, circle, text, image)
   - Widget API (box, button, check, entry, form, group, hyperlink, icon, 
   label, progress bar, radio, scroller, tabs and toolbar)
   - Light and dark themes
   - Pointer, key and shortcut APIs (generic and desktop extension)
   - OpenGL driver for Linux, macOS and Windows
   - Tools for embedding data and packaging releases

The entire toolkit is developed using scalable graphics so that it looks 
clean and crisp on different devices and screen densities.

This release only supports desktop applications but watch this space :).


I'd like to thank everyone that has contributed to this milestone.

You can get started today at fyne.io/develop.

-- 
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] protobuf and golang

[R Srinivasan]

Thanks, I'll check it out.

On Wed, Mar 20, 2019 at 2:23 AM Ian Denhardt  wrote:

> This might be more directly what you're after:
>
> https://kaitai.io/
>
> Though disclaimer, I haven't used it myself.
>
> Quoting Wojciech S. Czarnecki (2019-03-19 20:25:08)
> > On Mon, 18 Mar 2019 09:59:59 -0700 (PDT)
> > R Srinivasan  wrote:
> >
> > > my intial attempts to define the data structures have hit a roadblock -
> > > support for data types such as uint16, int16, uint8, int8. Is this an
> > > inherent protobuf limitation or am i overlooking something.
> >
> > Yep. Protobuf is an exchange format of its own.
> >
> > https://github.com/google/flatbuffers should give you more flexibility.
> > If your binary is tightly packed it will not be effortless, but doable.
> >
> > If you need to support bitfields you may also look at the 'bitpeek'
> > simple parser code for inspiration:
> >
> > https://github.com/ohir/bitpeek
> >
> > Hope this helps,
> >
> >
> > --
> > Wojciech S. Czarnecki
> >  << ^oo^ >> OHIR-RIPE
> >
> > --
> > 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.

Re: [go-nuts] protobuf and golang

[Ian Denhardt]

This might be more directly what you're after:

https://kaitai.io/

Though disclaimer, I haven't used it myself.

Quoting Wojciech S. Czarnecki (2019-03-19 20:25:08)
> On Mon, 18 Mar 2019 09:59:59 -0700 (PDT)
> R Srinivasan  wrote:
>
> > my intial attempts to define the data structures have hit a roadblock -
> > support for data types such as uint16, int16, uint8, int8. Is this an
> > inherent protobuf limitation or am i overlooking something.
>
> Yep. Protobuf is an exchange format of its own.
>
> https://github.com/google/flatbuffers should give you more flexibility.
> If your binary is tightly packed it will not be effortless, but doable.
>
> If you need to support bitfields you may also look at the 'bitpeek'
> simple parser code for inspiration:
>
> https://github.com/ohir/bitpeek
>
> Hope this helps,
>
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> 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.