~sbinet

France

Particle physicist turned software engineer

Trackers

~sbinet/aranet4

Last active 3 months ago

~sbinet/varda

Last active 7 months ago

~sbinet/odf

Last active 8 months ago

~sbinet/gg

Last active 10 months ago

~sbinet/star-tex

Last active 2 years ago

#5 consider using CIDs from IPFS 7 months ago

Ticket created by ~sbinet on ~sbinet/varda

we could perhaps use CIDs from IPFS instead of "rolling our own" scheme of SHA-224.

#513 x/explorer: compilation failure with (upcoming) Go-1.21 8 months ago

on ~eliasnaur/gio

RIP CallImport.

That is caused because the undocumented CallImport was replaced by //go:wasmimport. Since keeping both is quite unmaintainable, it's easier to move everything to syscall/js (which is also not stable, and slower).

The issue caused by using syscall/js is one additional copy each time. I will send one PR to replace it, maybe at the end of this week.

-- Lucas Rodrigues inkeliz@inkeliz.com

On Mon, Jul 10, 2023, at 4:37 PM, ~sbinet wrote:

trying to compile x/explorer@v0.1.0 with the upcoming Go-1.21 version (and its new wasip1/wasm target), leads to:

$> gogio -x -target js  -o _wasm ./my-app
go list -f {{.ImportPath}} ./cmd/varda
go list -f {{.Dir}} ./cmd/varda
go build -ldflags=-X gioui.org/app/internal/log.appID=org.example.myapp 
-tags= -o _wasm/main.wasm ./cmd/varda
gogio: go build -ldflags=-X 
gioui.org/app/internal/log.appID=org.example.myapp -tags= -o 
_wasm/main.wasm ./cmd/varda failed: # gioui.org/x/explorer
../../gocode/pkg/mod/gioui.org/x@v0.1.0/explorer/explorer_js.s:6: 
unrecognized instruction "CallImport"
../../gocode/pkg/mod/gioui.org/x@v0.1.0/explorer/explorer_js.s:10: 
unrecognized instruction "CallImport"
../../gocode/pkg/mod/gioui.org/x@v0.1.0/explorer/explorer_js.s:14: 
unrecognized instruction "CallImport"
asm: assembly of 
../../gocode/pkg/mod/gioui.org/x@v0.1.0/explorer/explorer_js.s failed

(the same code does compile successfully with Go-1.19.x and Go-1.20.x)

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/513

#513 x/explorer: compilation failure with (upcoming) Go-1.21 8 months ago

Ticket created by ~sbinet on ~eliasnaur/gio

trying to compile x/explorer@v0.1.0 with the upcoming Go-1.21 version (and its new wasip1/wasm target), leads to:

$> gogio -x -target js  -o _wasm ./my-app
go list -f {{.ImportPath}} ./cmd/varda
go list -f {{.Dir}} ./cmd/varda
go build -ldflags=-X gioui.org/app/internal/log.appID=org.example.myapp -tags= -o _wasm/main.wasm ./cmd/varda
gogio: go build -ldflags=-X gioui.org/app/internal/log.appID=org.example.myapp -tags= -o _wasm/main.wasm ./cmd/varda failed: # gioui.org/x/explorer
../../gocode/pkg/mod/gioui.org/x@v0.1.0/explorer/explorer_js.s:6: unrecognized instruction "CallImport"
../../gocode/pkg/mod/gioui.org/x@v0.1.0/explorer/explorer_js.s:10: unrecognized instruction "CallImport"
../../gocode/pkg/mod/gioui.org/x@v0.1.0/explorer/explorer_js.s:14: unrecognized instruction "CallImport"
asm: assembly of ../../gocode/pkg/mod/gioui.org/x@v0.1.0/explorer/explorer_js.s failed

(the same code does compile successfully with Go-1.19.x and Go-1.20.x)

#5 odf: add creation of documents 8 months ago

Ticket created by ~sbinet on ~sbinet/odf

It would be great to be able to create ODF documents (ODT, ODS, ...) directly in Go using x/odf.

#4 odf: reorganize nodes and parser ? 8 months ago

Ticket created by ~sbinet on ~sbinet/odf

The sheer amount of types that the OpenDocument specification describes renders the documentation of the x/odf package quite unmanageable.

We should perhaps reorganize the generated code into an x/odf/internal/odf package and provide some type aliases inside the root x/odf package and a new x/odf/ast one for the nodes.

It would be nice to split the nodes into text, draw, style, ... -related packages but it may prove undoable (because of cyclic imports).

#3 odt2md: improved heuristics for code-blocks 8 months ago

Ticket created by ~sbinet on ~sbinet/odf

translating an OpenOffice preformatted block into a CommonMark one should result in:

bla
bla

instead, we get:

`bla`

`bla`

glamour has an interesting approach (ansi.StyleConfig) we could steal.

// StyleConfig is used to configure the styling behavior of an ANSIRenderer.
type StyleConfig struct {
	Document   StyleBlock `json:"document,omitempty"`
	BlockQuote StyleBlock `json:"block_quote,omitempty"`
	Paragraph  StyleBlock `json:"paragraph,omitempty"`
	List       StyleList  `json:"list,omitempty"`

	Heading StyleBlock `json:"heading,omitempty"`
	H1      StyleBlock `json:"h1,omitempty"`
	H2      StyleBlock `json:"h2,omitempty"`
	H3      StyleBlock `json:"h3,omitempty"`
	H4      StyleBlock `json:"h4,omitempty"`
	H5      StyleBlock `json:"h5,omitempty"`
	H6      StyleBlock `json:"h6,omitempty"`

	Text           StylePrimitive `json:"text,omitempty"`
	Strikethrough  StylePrimitive `json:"strikethrough,omitempty"`
	Emph           StylePrimitive `json:"emph,omitempty"`
	Strong         StylePrimitive `json:"strong,omitempty"`
	HorizontalRule StylePrimitive `json:"hr,omitempty"`

	Item        StylePrimitive `json:"item,omitempty"`
	Enumeration StylePrimitive `json:"enumeration,omitempty"`
	Task        StyleTask      `json:"task,omitempty"`

	Link     StylePrimitive `json:"link,omitempty"`
	LinkText StylePrimitive `json:"link_text,omitempty"`

	Image     StylePrimitive `json:"image,omitempty"`
	ImageText StylePrimitive `json:"image_text,omitempty"`

	Code      StyleBlock     `json:"code,omitempty"`
	CodeBlock StyleCodeBlock `json:"code_block,omitempty"`

	Table StyleTable `json:"table,omitempty"`

	DefinitionList        StyleBlock     `json:"definition_list,omitempty"`
	DefinitionTerm        StylePrimitive `json:"definition_term,omitempty"`
	DefinitionDescription StylePrimitive `json:"definition_description,omitempty"`

	HTMLBlock StyleBlock `json:"html_block,omitempty"`
	HTMLSpan  StyleBlock `json:"html_span,omitempty"`
}

// StyleBlock holds the basic style settings for block elements.
type StyleBlock struct {
	StylePrimitive
	Indent      *uint   `json:"indent,omitempty"`
	IndentToken *string `json:"indent_token,omitempty"`
	Margin      *uint   `json:"margin,omitempty"`
}

// StylePrimitive holds all the basic style settings.
type StylePrimitive struct {
	BlockPrefix     string  `json:"block_prefix,omitempty"`
	BlockSuffix     string  `json:"block_suffix,omitempty"`
	Prefix          string  `json:"prefix,omitempty"`
	Suffix          string  `json:"suffix,omitempty"`
	Color           *string `json:"color,omitempty"`
	BackgroundColor *string `json:"background_color,omitempty"`
	Underline       *bool   `json:"underline,omitempty"`
	Bold            *bool   `json:"bold,omitempty"`
	Upper           *bool   `json:"upper,omitempty"`
	Lower           *bool   `json:"lower,omitempty"`
	Title           *bool   `json:"title,omitempty"`
	Italic          *bool   `json:"italic,omitempty"`
	CrossedOut      *bool   `json:"crossed_out,omitempty"`
	Faint           *bool   `json:"faint,omitempty"`
	Conceal         *bool   `json:"conceal,omitempty"`
	Overlined       *bool   `json:"overlined,omitempty"`
	Inverse         *bool   `json:"inverse,omitempty"`
	Blink           *bool   `json:"blink,omitempty"`
	Format          string  `json:"format,omitempty"`
}

#2 odf: generate from RelaxNG 8 months ago

Ticket created by ~sbinet on ~sbinet/odf

Right now, we generate the parser and ODF types from a simplified representation of the original RelaxNG document (using a "simple" scfg document).

We should instead generate the parser and ODF types from the original RelaxNG XML document.

As a first step, we could ignore all the semantics of zeroOrXXX, interleave, ... elements.

#2 migrate raster away from golang/freetype 10 months ago

Ticket created by ~sbinet on ~sbinet/gg

we don't have yet a performant enough replacement:

perhaps Gio when it gets a pure-CPU renderer ?

#1 migrate to x/image/font throughout 10 months ago

Comment by ~sbinet on ~sbinet/gg

REPORTED RESOLVED CLOSED