Experience Report building OCR in Go

476 views
Skip to first unread message

Tad Vizbaras

unread,
Jan 15, 2018, 3:32:33 PM1/15/18
to golang-nuts
Experience Report building OCR in Go:



Kevin Malachowski

unread,
Jan 16, 2018, 1:09:48 AM1/16/18
to golang-nuts
Not sure about the GUI points: exp/shiny has worked really well for me and has existed for at least a year. I do admit that 4 years ago I tried my hand at a GUI framework for Go though...

Sebastien Binet

unread,
Jan 16, 2018, 3:07:58 AM1/16/18
to Kevin Malachowski, golang-nuts
On Tue, Jan 16, 2018 at 7:09 AM, Kevin Malachowski <nifta...@gmail.com> wrote:
Not sure about the GUI points: exp/shiny has worked really well for me and has existed for at least a year. I do admit that 4 years ago I tried my hand at a GUI framework for Go though...

beside being a bit barebone (shiny isn't a toolkit yet, far from it) the one grip I have with it is that it isn't network transparent, even though the library on top of which it was developped does support this on Linux.
it prevented me from deploying a few Go applications in my lab because of the setup we have here (thin X-terminals (then sun-rays, now raspi-3s) that connect to heavier multicore, multi-GB-RAM servers.)

that said, at least it does exist :)

-s

Egon

unread,
Jan 16, 2018, 3:41:23 AM1/16/18
to golang-nuts
Not sure why you had to build a GUI separately, there are already a few libs, although some of them are still barebones...

https://github.com/lxn/walk
https://github.com/andlabs/ui

Of course there are also bindings for gtk and qt.

Egon

unread,
Jan 16, 2018, 3:45:22 AM1/16/18
to golang-nuts
As for getting andlabs/ui compiling the easiest I've found is to use msys2...


i.e. installation from scratch:

2. open msys shell
3. pacman -Syu
3.1 close from X
4. pacman -Su
5. pacman -S mingw-w64-x86_64-go
6. pacman -S --needed base-devel mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain

But, yeah... it could be much, much easier.

Tad Vizbaras

unread,
Jan 16, 2018, 7:27:44 AM1/16/18
to golang-nuts
OCR project started 2 years ago. Then there was no usable exp/shiny. 
I still think that GUI frameworks for Go are in baby stages even today. 

Why would I resort to some C libraries when "syscall" works with Windows API well?

Egon

unread,
Jan 16, 2018, 7:56:01 AM1/16/18
to golang-nuts
On Tuesday, 16 January 2018 14:27:44 UTC+2, Tad Vizbaras wrote:
OCR project started 2 years ago. Then there was no usable exp/shiny. 

That makes sense. Although walk, libui, qml are all older than 2 years.
 
I still think that GUI frameworks for Go are in baby stages even today. 

Totally agree.
 
Why would I resort to some C libraries when "syscall" works with Windows API well?

Few reasons, the C libs might provide more widgets and UI editor (i.e. qt + qml)...
or in case of libui, it would provide cross-platform support.

But, yeah, when targeting only Windows and controls are sufficient, then, yes, there's no point in introducing the complexity.

Tad Vizbaras

unread,
Jan 16, 2018, 8:18:08 AM1/16/18
to golang-nuts
I used "walk" for prototyping but found it too complex. I do not mean this as criticism. "walk" uses many closures to init controls and
get GUI working. This is fine if you are into this style of programming. I find reading "walk" internal code challenging.

"walk" was an inspiration. It is possible to build Go Windows GUI apps without C compiler.

In terms of timing it took 1 solid month by 1 developer to get Windows GUI packages working.



Tyler Compton

unread,
Jan 18, 2018, 2:26:05 PM1/18/18
to Tad Vizbaras, golang-nuts
In the Error Handling section, you mention having to write a special package to capture stack traces. Would https://github.com/pkg/errors have done what you want?

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

Tad Vizbaras

unread,
Jan 18, 2018, 2:32:44 PM1/18/18
to golang-nuts
Yes, that what I have used. I feel that package https://github.com/pkg/errors is good enough to be in the standard library. At least part of it that does stack trace. 
In all respects Go worked very well for this project. 

DrGo

unread,
Jan 22, 2018, 10:47:59 PM1/22/18
to golang-nuts
Thanks for your informative report. I fully agree with you re the zero value of maps. A read-only empty is useless.

Sokolov Yura

unread,
Jan 23, 2018, 11:48:54 PM1/23/18
to golang-nuts
+1 for map's zero value. Huge inconsistency in a language.

I think, it were made for speed: map is just a pointer (to hidden struct). Zero-map is just nil pointer. To make zero-value mutable there should be assignment to a pointer on every access.

More over, map has reference identity ie it is always copied by reference:

a := b
b[1] = 1
a[1] == 1

This is impossible to implement with mutable zero value.

Reply all
Reply to author
Forward
0 new messages