vdobler/chart 623

Provide basic charts in go

vdobler/ht 22

Http Testing made easy

vdobler/plot 10

Provide ggplot2-like plotting in Go

vdobler/webtest 7

Testing framework for web applications

vdobler/ft 1

First test

vdobler/stable 1

Some experiments with stable sorting in Go.

vdobler/bender 0

An easy-to-use library for creating load testing applications

issue commentgolang/go

net/http: SameSiteDefaultMode adds an incorrect 'Set-Cookie' attribute


No matter what version of the spec we're going off, `SameSite? by itself isn't valid.. As best as I can tell anyway.

I took a look at which defines the Set-Cookie header field:

samesite-av    = "SameSite" / "SameSite=" samesite-value
samesite-value = "Strict" / "Lax"

As you can see a single "SameSite" was okay.

But you are right it seems as if this was changed in :

samesite-av       = "SameSite=" samesite-value
samesite-value    = "Strict" / "Lax" / "None"

So it does matter which spec we try to implement.

Is far as I understand the Chromium sources and the spec 6265bis-05 a "naked" SameSite would lead to dropping the samesite-av which then is treated as None (from 6265bis-05: "Note: This algorithm maps the "None" value, as well as any unknown value, to the "None" behavior, which is helpful for backwards compatibility when introducing new variants.").

So we a) should document the issue with SameSiteDefaultMode but b) we do not need to change how SameSiteDefaultMode is serialized (as it will be treated as None).


comment created time in 8 days

issue openedOrlovEvgeny/go-mcache

Cache seems to be a singleton

Try this:

	a, b := mcache.New(), mcache.New()
a.Set("foo", 123, time.Second)
val, ok := b.Get("foo")
fmt.Println(val, ok)

Which will produce "123 ok". It seems you cannot have multiple caches. This should either be documented clearly or fixed.

created time in a month

create barnchvdobler/aoc19

branch : master

created branch time in 2 months

created repositoryvdobler/aoc19

created time in 3 months

issue commentgolang/go

x/tools/cmd/godoc: Proposal: let godoc recognize mT styled source

I'm totally in favour for rendering numbered and bulletpoint lists better (read as ul and li in HTML) but Marktop is just dead ugly to read and painful to write. It'll make my workday miserable when I have to write it and when I have to read it.

This proposal aims at too much. I think the current godoc formating lacks two things: a) Inline verbatim/fixed width/code styling and b) automatic list detection.

Headings, paragraphs are solved and work (not perfectly but they work).

URLs can be detected reliably and I actually do like to see the URL of a link before clicking on it, so I do not see the need for a link text that differs from the URL. (This is different for very technical URLs with e.g. lots of query parameters, but such URLs are uncommon in documentation).

For b) it is hard to find some heuristic which works well for list existing in the wild (I tried it on the corpus). This might be fixable as most list which are not detected by a simple heuristic are rendered badly in the current version anyway. This might be doable and would make complicated documentation (e.g. package doc better). Even the spec uses uls and lis.

Common wisdom for a) is to use backticks as in markdown. This is ugly, simply because it is markdown and input and output render different characters. A less invasive option would be to use two spaces which makes a word/identifier to stand out in plain text:

Foo foos the  target  while aiming at bar.

Being rendered as "Foo foos target while aiming at bar." I think something like this would help as it makes writing documentation easier as you have to reword less and have to rename arguments less to produce understandable documentation.

(Just my contribution to this bikeshedding.)


comment created time in 3 months

issue commentjung-kurt/gofpdf

AddUTF8FromBytes modifies its argument utf8bytes resulting in a panic if you generate two PDFs wih the "same" font bytes.

I do not thing that the PR #318 is a proper fix for the underlying problem. Making a copy before modifying the byte slice hides the actual problem: somehow reading the font is not a read-only action.

This type of stopgap solution can be used without this "fix" (actually that's what I'm doing now: make a copy). But I think the actual modification should be fixed instead of hidden behind a copy.


comment created time in 4 months

issue commentgolang/go

proposal: backports: fix regressions in previous releases for N days

Without at least some litte pressure to use the current version people will stick to old stuff longer than it is healthy (either because they are lazy or because they are afraid). So please: Do not backport too much stuff and especially not for too long.

It sometimes takes us two or three weeks to switch to the latest release. But this time frame is determined by holidays, people being sick, planed downtimes and fixing production issues and not by having to get the new release working with our software.


comment created time in 5 months

issue openedjung-kurt/gofpdf

panic: runtime error: index out of range when using AddUTF8FromBytes and generating 2 PDFs

I've encountered a strange problem: I can generate a PDF with embedded UTF-8 font without any problems, but just once. Generating the same PDF once more results in a panic because the input utf8bytes to AddUTF8FontFromBytes is modified.

$ ./fpdfpanic
Making PDF
--> OK
Making PDF
panic: runtime error: index out of range [20] with length 12

goroutine 1 [running]:*utf8FontFile).getSymbols(0xc0000cc2a0, 0x14, 0xc0000c6e28, 0xc00006c210, 0xc00006c1b0, 0xc00006a120, 0xb, 0xb, 0xc0000c6e28, 0xc00006c210, ...)
	/Users/m0252720/go/pkg/mod/ +0x522*utf8FontFile).parseSymbols(0xc0000cc2a0, 0xc0000a36e0, 0xb, 0xc00006c2a0, 0x3ff0000000000000, 0x0, 0x0, 0x0)
	/Users/m0252720/go/pkg/mod/ +0x541*utf8FontFile).GenerateСutFont(0xc0000cc2a0, 0xc0000a36e0, 0x0, 0xc000014a3a, 0x3)
	/Users/m0252720/go/pkg/mod/ +0x3eb*Fpdf).putfonts(0xc0002ce800)
	/Users/m0252720/go/pkg/mod/ +0xb78*Fpdf).putresources(0xc0002ce800)
	/Users/m0252720/go/pkg/mod/ +0x75*Fpdf).enddoc(0xc0002ce800)
	/Users/m0252720/go/pkg/mod/ +0x121*Fpdf).Close(0xc0002ce800)
	/Users/m0252720/go/pkg/mod/ +0xa1
	/Users/m0252720/go/src/tmp/fpdfpanic/main.go:28 +0x215
	/Users/m0252720/go/src/tmp/fpdfpanic/main.go:17 +0xd5

Here is (stripped) the code to reproduce above error:

package main

import (


var fontBytes []byte

func main() {
	fontBytes, _ = base64.StdEncoding.DecodeString(dvscData)

func makePDF() *bytes.Buffer {
	fmt.Println("Making PDF")
	pdf := gofpdf.New("P", "mm", "A4", "")
	pdf.AddUTF8FontFromBytes("HNC", "", fontBytes)
	pdf.SetXY(20, 20)
	pdf.SetFont("HNC", "", 12)
	pdf.MultiCell(0, 15, "abcABC1234", "", "L", false)

	out := &bytes.Buffer{}
	fmt.Println("--> OK")
	return out

// DejaVuSansCondensed.ttf in base64 encoding. (trimmed).
var dvscData = `AAEAAAAUAQAAB ..... `

The problem does not happen if the font is loaded from disk, e.g. with // pdf.AddUTF8Font("HNC", "", "..../")

The panic does not happen on the first rendering but on all subsequent renderings (not show in demo code above).

The reason is that somehow AddUTF8FontFromBytes modifies its input utf8bytes. Mkeing a copy beforehand avoids the problem and renders all PDFs without problems.

         // Working code:
	pdf := gofpdf.New("P", "mm", "A4", "")
	cpy := make([]byte, len(fontBytes))
	copy(cpy, fontBytes)
	pdf.AddUTF8FontFromBytes("HNC", "", cpy)

(Maybe this modification if the utf8bytes argument is intended but then it should be documented.)

created time in 5 months

issue commentgolang/go

go/doc: lines ending with parenthesis cannot be headings

We needed some way to distinguish a headline from a simple sentence. A very early implementation used two preceding blank line to signal a heading but this was considered to be markup and some heuristic was chosen to distinguish a heading. This heuristic produces several false negatives, like this issue or that you cannot have a headline in a script without uppercase characters. In Englisch (european languages in general) you can reword a heading to match the rules.

Proper documentation fixes only half of the problem. We could allow the headline to end in a ")" if preceded by a matching "(". And document this. But this process becomes endless: You still cannot have "Reaching 99.5%" as a heading but "Reaching (99.5%)" would be rendered as a heading.

While I dislike markup in code comments I think the rules for a good heading heuristic are even worse than non-invasive markup like two preceding blank lines.


comment created time in 5 months