On Thu, Sep 16, 2021 at 11:17 PM yba...@gmail.com wrote:
> - Design in a non-blocking tcp way (that is let the user use
> select()/poll()/epoll() sycall).
> - Or design it with blocking tcp io inside go routines, which would return
> 2 channels (read and write). Then let the user do a channel-sel
https://go.dev/blog/tls-cipher-suites
In case anyone has not seen it, Filippo has published a blog post which
shows
how SSL Cypher Suite negotiation is fundamentally broken in the older TLS
versions.
My understanding of the post is that to run a secure server on the
internet,
just make sure y
Hi, when using a custom io.ReadCloser nop as body with method POST, PUT,
PATCH, TRACE or custom then (*http.Request).Write outputs a body of the
form "0\r\n\r\n" (without the quotes).
Proof-of-concept: https://play.golang.org/p/Rg2cZ0wihdd
Besides the fix, I think it would be useful to have bod
The advantage of Go is to be able to use millions of blocking Go routines.
Synchronous programming is much easier than async - especially for streaming
protocols.
> On Sep 16, 2021, at 4:17 PM, yba...@gmail.com wrote:
>
> Hello everyone,
>
> I am trying to design a new library to encode/de
Hello everyone,
I am trying to design a new library to encode/decode MQTT messages. I began
the work, and now I must decide how to design the TCP processing of my
library, and I am facing two choices:
- Design in a non-blocking tcp way (that is let the user use
select()/poll()/epoll() sycall).
Alright, I got it fixed. I ran go in legacy mode (as *@Anderson Queiroz*
suggested) by manually setting it in the win env var: GO111MODULE=off
(since it's a temp var which resets upon every instance); and reinstalled
Git.
Thanks for the assist guys!
On Wednesday, September 15, 2021 at 3:56:51
Alright, I got it fixed. As Anderson suggested, I ran go in legacy mode by
manually setting GO111MODULE=off in win env var so I doesn't reset upon
next instance of go (since it's a temporary variable). I also reinstalled
git.
Thanks for the assist guys!
On Wednesday, September 15, 2021 at 3:56
Hi Remi,
You might want to open a bug on https://github.com/golang/go/issues/new and
try to check if 1.17 (not 1.17.1) has the same problem - that will reduce
the scope of thing to verify for dev team
Andrey
On Wednesday, September 15, 2021 at 1:05:52 PM UTC-6 remi.p...@gmail.com
wrote:
> He
> the comparison against yaegi (at least on the fibonacci example) is
> flabergasting. (did you try against gomacro[1]?)
We haven't tested gomacro, but we can certainly add it to the benchmarks.
> do you plan to expose a REPL powered by Scriggo?
At the moment this is not planned yet as we woul
Hi Christoph,
> Curious – how close is the interpreter to the latest Go version?
The interpreter implements Go 1.17 with some limitations that we need to
work on. You can see the following page:
https://scriggo.com/limitations
> And how fast are new Go versions adopted?
We try to support th
On Wed Sep 15, 2021 at 15:15 CET, Marco Gazerro wrote:
> Announcing Scriggo, an open source Golang template engine that uses Go
> as
> its scripting language. Scriggo also includes an embeddable interprter
> for
> the Go language.
>
> https://github.com/open2b/scriggo
it's a rather interesting pro
Hi Marco,
That's super interesting, especially the Go interpreter part.
Curious – how close is the interpreter to the latest Go version?
And how fast are new Go versions adopted?
Thanks,
Christoph
On Wednesday, September 15, 2021 at 3:15:43 PM UTC+2 Marco Gazerro wrote:
> Announcing Scriggo,
12 matches
Mail list logo
