France
Particle physicist turned software engineer
Ticket created by ~sbinet on ~sbinet/varda
we could perhaps use CIDs from IPFS instead of "rolling our own" scheme of SHA-224.
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 tosyscall/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 newwasip1/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
andGo-1.20.x
)-- View on the web: https://todo.sr.ht/~eliasnaur/gio/513
Ticket created by ~sbinet on ~eliasnaur/gio
trying to compile
x/explorer@v0.1.0
with the upcoming Go-1.21 version (and its newwasip1/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
andGo-1.20.x
)
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
.
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 rootx/odf
package and a newx/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).
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"` }
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.
Ticket created by ~sbinet on ~sbinet/odf
The OpenDocuments specifications are gathered here:
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 ?