Re: [go-nuts] Re: [ANN] star-tex: a Go engine for TeX

[Sebastien Binet]

Hi Patrick,

Nice!

Did you manually translated it or was it done with some tooling?

-s

 Original Message 
On Feb 21, 2021, 07:43, Patrick < std...@gmail.com> wrote:
Hi Sebastien,

a few years ago I started with dvitype

https://github.com/speedata/gotex

Patrick

Sebastien Binet schrieb am Dienstag, 16. Februar 2021 um 15:23:41 UTC+1:

hi there,

I'd like to introduce star-tex[1], a (Work In Progress) TeX engine.

it wraps the output of the official texlive tex.w WEB file (ie: C/C++
files) as a CGo package.

the idea is to replace in an adiabatical fashion the C bits with their
Go equivalent.

there's already code that can correctly decode TeX Font metrics files.

$> go get git.sr.ht/~sbinet/star-tex/cmd/star-tex

$> star-tex ./testdata/hello.tex out.div
$> dvipdf out.dvi
$> pdf out.pdf

PR and patches welcomed :)

-s

[1]: https://sr.ht/~sbinet/star-tex

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/53f9b35a-eedd-401c-9b7d-8d1bf7dd9977n%40googlegroups.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/wEGpR9QQXZ2UGjv4BSd5jg3yYo5E5J1dLy06iDjPuWjybN_frSCWeamPcTy7wTN08AQxMCIjPB-euX8e8mWbhne9Mb9xx0HGOSsscm_IIfw%3D%40sbinet.org.

Re: [go-nuts] Code markup in golang-nuts

[Shulhan]

> On 21 Feb 2021, at 14.52, Amnon  wrote:
> 
> Slightly off topic.
> But is there any way to enhance google groups so that it will support 
> Markdown?

Not that I know of. Google groups is mailing list, any thing in and out would 
be by/for email clients, which is not specific to Google groups.

> Or at least provides a simple way to post formatted code without the 
> indentation being destroyed?
> 

My tips is not using HTML for body (maybe the option name is something like 
"disable Rich Text format"), use plain text, and it will formatted as is.

> People often want post code snippets on this group.
> And I have yet to find an easy way to do this.
> 

Most that I have seen use play.golang.org and/or copy-paste the formatted code 
in email content.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8A745206-72D8-450A-9EFE-DF754110B375%40gmail.com.

Re: [go-nuts] [generics] type switches

['Axel Wagner' via golang-nuts]

On Sun, Feb 21, 2021 at 4:44 AM thepud...@gmail.com 
wrote:

> In any event, I am curious about the latest thinking and/or latest status.
> If this has been discussed at length elsewhere since that August thread, I
> would be happy for a pointer if anyone has one.
>

I think for the most part, you found the discussion and the latest status -
it's not clear it's a good idea, so it's left out of the proposal for now.
It might get added later (where "later" most likely means "after generics
have landed and we see how they're used"). There's probably also some
additional discussion in #43651 
and some tangentially related discussion in #41716
 (one consideration is how
type-switches would interact if we ever decided to adopt an extension of
using type-list interfaces as sum-types), though both issues might be hard
to comb through. I'm not aware of a thread more specifically concerned with
this question.


>
> Thanks, and sorry if the answer is I am just confused ;-)
>
> Best regards,
> thepudds
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/dbdc0e64-b41d-4c69-9218-5972dc3b21a3n%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEHSm%2BsN328X2YKbzehWpy4zct8E4YzFv6_n1Db7W-E7w%40mail.gmail.com.

Re: [go-nuts] Re: Unable to find small memory leak

[Miles Hex]

Hi, thanks to everyone for the suggestions,

It seems that there is in fact not a memory leak (still not totally sure), 
but for some reason, the go runtime keeps allocating memory event when is 
not needed, I think the problem is in the interaction from the memory model 
of the go runtime with a Linux system with low ram (128MB).

If I force a low memory situation (by allocating memory in another 
program), the go runtime give back most of his memory (goes from 23 MB to 
6MB),  but before that happen the system become very unstable at the point 
that I'm unable to spawn new process (related to issue #31936), and other 
services start to crash(not yet sure why) or the OOMkiller start killing 
process. go 1.16, should "fix" this, with how it releases memory back to 
the system (not yet tested).

I'm still a bit perplexed by the numbers from runtime. memstat,  I don't 
help that my code does a lot of small, short-lived allocations, which makes 
analysis a lot harder, I will now enable memstat metric even in production 
hoping that will help, and working on reducing allocation in some hot path, 
to make the output less busy.

@Tom Mitchell: yes objects plural, sorry. i will try your suggestions.

a couple of notes:
- I don't use CGO
- I, unfortunately, can't change the environment variable, so I can use 
"GODEBUG=gctrace=1" only on my machine which runs/behave differently in 
virtue of not having the same hardware, and does not present the same 
memory problems/behavior, I also can't launch myself with the new 
variable(for a bunch of reasons that are a bit hard to explain, without 
going in many details), I have a couple of idea on how to fix it but I 
wasn't able to, 
- On this device run other services, that for me are black boxes, some of 
which seem to crash in low memory situation but I don't know yet why (i 
emailed the respective developers and awaiting a response)

I will update, if I find something.
Again thanks to everyone.


On Thursday, February 11, 2021 at 6:27:00 PM UTC+1 ren...@ix.netcom.com 
wrote:

> Are you using CGo or libraries that use CGo? If so, you probably have an 
> off-heap, i.e malloc() leak  
>
> On Feb 11, 2021, at 11:11 AM, Tom Mitchell  wrote:
>
> 
>
>
> On Thu, Feb 11, 2021 at 3:40 AM Uli Kunitz  wrote:
>
>> You are writing: The device crashes with out of memory. What does crash? 
>> The Go program, another program or the kernel? Can you share the error 
>> message? Can you share the log file for one day of GODEBUG=gctrace=1?
>>
>> In bash do:
>>
>> $ export GODEBUG=gctrace=1
>> $  2>error.log
>>
>> On Thursday, February 11, 2021 at 9:01:52 AM UTC+1 Miles Hex wrote:
>>
>>> To be honest, i'm not totally sure, what is see is that memory keep 
>>> raising until the device crash for out of memory, but what does it mean if 
>>> reachable object remain constant, but the " Heap objects" keep raising? 
>>>
 

>>>
> Objects plural?
> What is the size of each heap object.  With garbage collection it can help 
> to have as few sizes as possible. Pad objects so when collected the free 
> leaves a useful size space in the heap.   Linux can allow the VM system to 
> over allocate resources and only discover when written and the page fault 
> has no backing store.  Add swap to file and or tune the VM system.   Limits 
> -- set limits low enough for the program so it cannot dominate system 
> physical resources. 
> Add signal handler code to dump a summary of all your live objects.  
> Recursion? Socket(state)? Events arrive faster than event handling?  
> Locks/Mutex: is housekeeping getting CPU time [phone booth rule, give 
> priority to leaving]?  
>
>
> -- 
>   T o mM i t c h e l l ( o n   N i f t y E g g )
>
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAAMy4UQWV1Gt9UZBpjpAx01mhL5HEr8NCtGX1rnr1Hevui1Eiw%40mail.gmail.com
>  
> 
> .
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0011fc54-869f-4967-9791-2508c382a992n%40googlegroups.com.

Re: [go-nuts] Error handling

[Wojciech S. Czarnecki]

Dnia 2021-02-20, o godz. 16:48:09
Michael MacInnis  napisał(a):

> I can tell you most emphatically that I am not proposing not checking 
> and/or not handling errors.

I did not stated that you won't. Cited piece was directed at "just return err"
code stressing that it is not that common in the production code, mine's.

> I'd like to know if, for functions like the 
> ones just mentioned, a pattern exists for "eliminating 

> much of the boilerplate that arises if every error is checked with a rote if

I said twice that for me it is not "boilerplate" but much appreciated feature
of the language whose creators knew and acknowledged that every piece of
code is written once by one developer but is then being read over and over
by way more people than one.

And I have had not less emphatically told that where there is a function
that just returns with err, even in "many places", the bytewise cost of return
is some 30 bytes usually placed by the IDE with three strokes of mine.

For these three strokes where I just return (now):

As a reader I gained clear information that here something was checked then
function just spilled error up *but* I have the surrounding context at sight.

As an author I gained - now or later:
- A ready space to comment on and/or decorate the error value.
- If I am decorating or creating error value, I am right in scope.
- If this is recoverable failure, I can try to recover it now.

> And further if that pattern can be implemented as a library/package
> with acceptable trade offs.

In this thread it was proven that this antipattern can be implemented
as a library/package - using import, then setup, then a call to obscure
function - all to replace a 26 or 30 bytes long idiom - by Michael Ellis.

> I'd like to know if, for functions like the 
> If … a pattern exists for "eliminating [ these "ifs" ]

Yes it does exist. I once upon a time did a "fail" package and accompanying
generator to implement such "if-less" pattern to use in a cases where cost
of acquiring a resource is high and a bunch (say 8-10) of such resources is
needed to complete the task. It was a waste of time, as new people need to
be taught to read and understand it anyway. So it was abandoned due to
onboarding issues. It really was not worth the time.

``` go
for fail.With(err) { // bind an error type variable,
s, abort := fail.Simple() // set up a single pass loop
abort.Where(err != nil, !ok, z < 0) // set common "failure" condition(s)

  z := z  // test z < 0 (a "checked assignment")
  r, ok := <-ch   // test !ok
  x, y, z, err := f(z, r) // test err != nil, then test z < 0
  abort.If(x > y) // test x > y (a "plain test")
  x, y, err = m(x, y) // test err != nil
  return x, y, z, nil // can be prepended by an optional 'pass:'

abort:
  fmt.Printf("‖ %s: \t( %s )\n", err.Error(), s.Trig)
  return 0, 0, 0, err
}
// output:
‖ failed Test: ( x > y )   // for x > y
‖ failed Assignment: ( !ok )  // for closed ch
‖ failed Assignment: ( z < 0 )   // for z < 0
‖ Whatever err said: ( err != nil )  // for failed f(z, r) and m(x, y)
```

Early iteration (live example) to be seen here: 
https://play.golang.org/p/W35BVsZnZ-q

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20210221171014.2c247c6d%40xmint.

Re: [go-nuts] Code markup in golang-nuts

[Wojciech S. Czarnecki]

Dnia 2021-02-20, o godz. 23:52:04
Amnon  napisał(a):

> Slightly off topic.
> But is there any way to enhance google groups so that it will support 
> Markdown?

GGroups are n web interface to *mailing lists*. Most pros is subscribed
via mail, some (as me) using only MTAs that pass through only plain text.

> Or at least provides a simple way to post formatted code without the 
> indentation being destroyed?

Quick check over my mailboxs tells me that some 10% OP originate in
the web interface; then yet less followups are posted via web.

> People often want post code snippets on this group.
> And I have yet to find an easy way to do this.

Put your code on the playground, press [SHARE] then copy url
and paste in your message. This is the right way to share Go code.

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20210221172231.43cd5a34%40xmint.

Re: [go-nuts] Data Structure in Go

[Rahul kauraiya]

Thanks for the information.

On Fri, 19 Feb, 2021, 11:07 pm Marcin Romaszewicz, 
wrote:

> What are you looking to learn about data structures? Data structures in Go
> work the same as in any other language conceptually, just the language
> syntax to implement the concepts will be different. One of the most
> commonly used books on data structures and algorithms is the Cormen,
> Leiserson, Rivest, Stein book, Introduction to Algorithms
> .
> Section 3, Data Structures, is perhaps the best overview you can find.
>
> -- Marcin
>
> On Fri, Feb 19, 2021 at 8:57 AM Rahul kauraiya 
> wrote:
>
>> Hello Experts,
>> I am completely new to this programming language. I am highly interested
>> in learning data structures in Go.
>> I am not able to find any good resource to learn in deep.
>> Please share valuable resources to this thread.
>>
>> Thanks and  regards,
>> Rahul Kauraiya
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/68cf3ce0-976c-474e-a617-95d54287n%40googlegroups.com
>> 
>> .
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOQCz7GZf1StCuUTuZ3RRKgDerO6480H_oSaJ0%3DaJaAZo7Ezaw%40mail.gmail.com.

Re: [go-nuts] Re: [ANN] star-tex: a Go engine for TeX

[Patrick]

Hi Sebastien,

that was a manual translation of the web file. My plan was to do more than 
that, ... TeX is such a beast.

Patrick

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/39a23b55-f1c9-49ff-ab52-b6570ea6d095n%40googlegroups.com.

Re: [go-nuts] Re: [ANN] star-tex: a Go engine for TeX

[Sebastien Binet]

On Sun Feb 21, 2021 at 17:46 CET, Patrick wrote:
> Hi Sebastien,
>
> that was a manual translation of the web file.
> My plan was to do more than that, ... TeX is such a beast.

yeah... "how hard would it be to translate ~20k lines of C/C++ code (or
6k lines of obfuscated Pascal code) into a set of nicely structured Go
packages" ? :)

my initial strategy to have something working in a mixture of Go and
C/C++ (I am in the middle of getting rid of the C++ part), is OK to get
some PDFs out of the gate, but I think I need to invest in the tooling
to do the automatic web->Go translation. (either web->Pascal->Go or
web->C->Go.)
tex.web doesn't change too much nor too often, but 3.141592653 was just
"released" after I had started my C/C++->Go migration (bummer), so it
does happen.

-s

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/VLGvnsVd4dixDF0OHPIEfiji2SS4aNV89BnGqiyc4%40cp3-web-020.plabs.ch.

Re: [go-nuts] Re: [ANN] star-tex: a Go engine for TeX

[Patrick]

My problem with the TeX code base was that TeX is mainly spaghetti code 
(once untangled) and has many places where one would rather use Go code 
instead of the 'hacks' DEK has used to ensure compatibility (for example 
the ASCII input/output). So it is really hard to follow the code. 

And from there it is still only possible to read / write 8bit TFM/DVI. So a 
more modern approach would be to translate LuaTeX or PDFTeX, but this aint 
easy either.

Patrick

Sebastien Binet schrieb am Sonntag, 21. Februar 2021 um 18:15:25 UTC+1:

> On Sun Feb 21, 2021 at 17:46 CET, Patrick wrote:
> > Hi Sebastien,
> >
> > that was a manual translation of the web file.
> > My plan was to do more than that, ... TeX is such a beast.
>
> yeah... "how hard would it be to translate ~20k lines of C/C++ code (or
> 6k lines of obfuscated Pascal code) into a set of nicely structured Go
> packages" ? :)
>
> my initial strategy to have something working in a mixture of Go and
> C/C++ (I am in the middle of getting rid of the C++ part), is OK to get
> some PDFs out of the gate, but I think I need to invest in the tooling
> to do the automatic web->Go translation. (either web->Pascal->Go or
> web->C->Go.)
> tex.web doesn't change too much nor too often, but 3.141592653 was just
> "released" after I had started my C/C++->Go migration (bummer), so it
> does happen.
>
> -s
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ed9682d1-f1f6-4eec-9cb3-b5ad78e44586n%40googlegroups.com.

Re: [go-nuts] Error handling

[robert engels]

Can someone please explain the benefit of ‘error return’ over ‘checked 
exceptions’ ? I have made the point a few times and it goes to crickets - I 
have to believe that is because there is none, or it is difficult to 
communicate.

The ‘handle where they occur claim’ is weak, as you can handle exceptions at 
the call site with similar LOC and constructs - but why when in most cases (of 
non-trivial software) the error value is just returned up. No offense to 
Wojciech - the rpc transport layer doesn’t do the retires, it passes up an 
error, and a higher level performs retry logic, if all retries fail, it will 
pass up another error that the rpc failed, etc. This pattern is used throughout 
well designed software. If you hard using this pattern you are creating very 
hard to maintain software.

Checked exceptions are ‘error values’ with more information (e.g stack traces, 
causes, etc.), and can be enforced by the compiler (declared) and inspected by 
modern IDE’s for code complete. ‘error returns’ have none of these features. 
The only valid claim is that they are more expensive than error values, BUT you 
should not be using exceptions - or error values - for flow control. This is 
the fundamental problem to me with Go’s error handling - the flow control and 
errors are mixed leading to very difficult code to read & validate that all 
potential paths are handled now and in the future.



> On Feb 21, 2021, at 10:10 AM, Wojciech S. Czarnecki  wrote:
> 
> Dnia 2021-02-20, o godz. 16:48:09
> Michael MacInnis  napisał(a):
> 
>> I can tell you most emphatically that I am not proposing not checking 
>> and/or not handling errors.
> 
> I did not stated that you won't. Cited piece was directed at "just return err"
> code stressing that it is not that common in the production code, mine's.
> 
>> I'd like to know if, for functions like the 
>> ones just mentioned, a pattern exists for "eliminating 
> 
>> much of the boilerplate that arises if every error is checked with a rote if
> 
> I said twice that for me it is not "boilerplate" but much appreciated feature
> of the language whose creators knew and acknowledged that every piece of
> code is written once by one developer but is then being read over and over
> by way more people than one.
> 
> And I have had not less emphatically told that where there is a function
> that just returns with err, even in "many places", the bytewise cost of return
> is some 30 bytes usually placed by the IDE with three strokes of mine.
> 
> For these three strokes where I just return (now):
> 
> As a reader I gained clear information that here something was checked then
> function just spilled error up *but* I have the surrounding context at sight.
> 
> As an author I gained - now or later:
> - A ready space to comment on and/or decorate the error value.
> - If I am decorating or creating error value, I am right in scope.
> - If this is recoverable failure, I can try to recover it now.
> 
>> And further if that pattern can be implemented as a library/package
>> with acceptable trade offs.
> 
> In this thread it was proven that this antipattern can be implemented
> as a library/package - using import, then setup, then a call to obscure
> function - all to replace a 26 or 30 bytes long idiom - by Michael Ellis.
> 
>> I'd like to know if, for functions like the 
>> If … a pattern exists for "eliminating [ these "ifs" ]
> 
> Yes it does exist. I once upon a time did a "fail" package and accompanying
> generator to implement such "if-less" pattern to use in a cases where cost
> of acquiring a resource is high and a bunch (say 8-10) of such resources is
> needed to complete the task. It was a waste of time, as new people need to
> be taught to read and understand it anyway. So it was abandoned due to
> onboarding issues. It really was not worth the time.
> 
> ``` go
> for fail.With(err) { // bind an error type variable,
>s, abort := fail.Simple() // set up a single pass loop
>abort.Where(err != nil, !ok, z < 0) // set common "failure" condition(s)
> 
>  z := z  // test z < 0 (a "checked assignment")
>  r, ok := <-ch   // test !ok
>  x, y, z, err := f(z, r) // test err != nil, then test z < 0
>  abort.If(x > y) // test x > y (a "plain test")
>  x, y, err = m(x, y) // test err != nil
>  return x, y, z, nil // can be prepended by an optional 'pass:'
> 
> abort:
>  fmt.Printf("‖ %s: \t( %s )\n", err.Error(), s.Trig)
>  return 0, 0, 0, err
> }
> // output:
> ‖ failed Test: ( x > y )   // for x > y
> ‖ failed Assignment: ( !ok )  // for closed ch
> ‖ failed Assignment: ( z < 0 )   // for z < 0
> ‖ Whatever err said: ( err != nil )  // for failed f(z, r) and m(x, y)
> ```
> 
> Early iteration (live example) to be seen here: 
> https://play.golang.org/p/W35BVsZnZ-q
> 
> Hope this helps,
> 
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
> 
> -- 
> You received this message because you are subscribed to the Google Gr

Re: [go-nuts] Re: [ANN] star-tex: a Go engine for TeX

[Sebastien Binet]

On Sun Feb 21, 2021 at 18:19 CET, Patrick wrote:
> My problem with the TeX code base was that TeX is mainly spaghetti code
> (once untangled) and has many places where one would rather use Go code
> instead of the 'hacks' DEK has used to ensure compatibility (for example the
> ASCII input/output). So it is really hard to follow the code.
>
> And from there it is still only possible to read / write 8bit TFM/DVI.
> So a more modern approach would be to translate LuaTeX or PDFTeX,
> but this aint easy either.

right. it's also (at least for LuaTeX) not written in a BSD friendly
license.

I agree, it's a long journey.

-s

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/jgsCSxMVH2hYHbuz8jdiJxNQsFl2wpbcVORkz8TVi8%40cp7-web-039.plabs.ch.

Re: [go-nuts] [ANN] star-tex: a Go engine for TeX

[Bakul Shah]

On Feb 21, 2021, at 9:14 AM, Sebastien Binet  wrote:
> 
> On Sun Feb 21, 2021 at 17:46 CET, Patrick wrote:
>> Hi Sebastien,
>> 
>> that was a manual translation of the web file.
>> My plan was to do more than that, ... TeX is such a beast.
> 
> yeah... "how hard would it be to translate ~20k lines of C/C++ code (or
> 6k lines of obfuscated Pascal code) into a set of nicely structured Go
> packages" ? :)


Aren't you supposed to read Knuth's TeX: The Program book instead of
the 6k lines of Pascal?! 

Also, I don't understand why anyone would want to do that.

> 
> my initial strategy to have something working in a mixture of Go and
> C/C++ (I am in the middle of getting rid of the C++ part), is OK to get
> some PDFs out of the gate, but I think I need to invest in the tooling
> to do the automatic web->Go translation. (either web->Pascal->Go or
> web->C->Go.)

Doesn't web2c directly translate the web sources to C? 

> tex.web doesn't change too much nor too often, but 3.141592653 was just
> "released" after I had started my C/C++->Go migration (bummer), so it
> does happen.


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/B8226003-585A-454C-8712-E150FB3D04DF%40iitbombay.org.

[go-nuts] Link Go againsta a static 32 bit 3rd party library

[Luis Furquim]

Hello gophers,


I am reposting here the question I just made on Stack Overflow at
https://stackoverflow.com/questions/66305363/link-go-against-a-static-32-bit-3rd-party-library
I don't know if it is acceptable posting there and here. I saw that
sometimes people ask here and in the Golang developer list and get advised
to not post on both lists.
But there is a focus difference between the two lists. So, I think that
posting here and on Stack Overflow is not the same case.
If I misunderstood things, just let me know and this will not happen again.

So, about my question, I am using the flags below:

```
#cgo CFLAGS: -I.
#cgo LDFLAGS: -L. -lcluto

#include 
#include "cluto.h"
```

and when I compile with
```
go build clutod.go
```

The compiler fails with error
```
/usr/bin/ld: pulando
../../../../gopkg/src/dawn/plugins/cluto/clutobot/libcluto.a incompatível
ao pesquisar para -lcluto
/usr/bin/ld: não foi possível localizar -lcluto
collect2: error: ld returned 1 exit status
```

Which means that it finds that libcluto.a is incompatible because it is a
32 bit library and my system is compiling Go to amd64 architecture.

But when I compile with
```
GOARCH=386 go build clutod.go
```

The method defined in the same source file where 'import "C"' is defined is
simply ignored.

I checked with reflect and the method does not exist:
```
Goose.New.Logf(5,"|methods|=%d",typ.NumMethod())
Goose.New.Logf(5,"type=%s.%s",typ.PkgPath(),typ.Name())
for j=0; j(296): |methods|=10
2021/02/21 14:33:50 {stonelizard}[New.go](297):
type=dawn/plugins/cluto/clutobot.ServiceT
2021/02/21 14:33:50 {stonelizard}[New.go](300): 0: CRLListenAddress
2021/02/21 14:33:50 {stonelizard}[New.go](300): 1: CertKit
2021/02/21 14:33:50 {stonelizard}[New.go](300): 2: GetConfig
2021/02/21 14:33:50 {stonelizard}[New.go](300): 3: GetHost
2021/02/21 14:33:50 {stonelizard}[New.go](300): 4: GetMasterConfig
2021/02/21 14:33:50 {stonelizard}[New.go](300): 5: HttpsClient
2021/02/21 14:33:50 {stonelizard}[New.go](300): 6: ListenAddress
2021/02/21 14:33:50 {stonelizard}[New.go](300): 7: PageNotFound
2021/02/21 14:33:50 {stonelizard}[New.go](300): 8: SavePending
2021/02/21 14:33:50 {stonelizard}[New.go](300): 9: Stop
2021/02/21 14:33:50 {stonelizard}[New.go](303): *|methods|=21
2021/02/21 14:33:50 {stonelizard}[New.go](304): *type=.
2021/02/21 14:33:50 {stonelizard}[New.go](307): 0: *CRLListenAddress
2021/02/21 14:33:50 {stonelizard}[New.go](307): 1: *CertKit
2021/02/21 14:33:50 {stonelizard}[New.go](307): 2: *GetConfig
2021/02/21 14:33:50 {stonelizard}[New.go](307): 3: *GetHost
2021/02/21 14:33:50 {stonelizard}[New.go](307): 4: *GetId
2021/02/21 14:33:50 {stonelizard}[New.go](307): 5: *GetMasterConfig
2021/02/21 14:33:50 {stonelizard}[New.go](307): 6: *GetRest
2021/02/21 14:33:50 {stonelizard}[New.go](307): 7: *HttpsClient
2021/02/21 14:33:50 {stonelizard}[New.go](307): 8: *InitConn
2021/02/21 14:33:50 {stonelizard}[New.go](307): 9: *ListenAddress
2021/02/21 14:33:50 {stonelizard}[New.go](307): 10: *LoadClientCert
2021/02/21 14:33:50 {stonelizard}[New.go](307): 11: *LoadConfig
2021/02/21 14:33:50 {stonelizard}[New.go](307): 12: *NewCK
2021/02/21 14:33:50 {stonelizard}[New.go](307): 13: *NewSshClientConfig
2021/02/21 14:33:50 {stonelizard}[New.go](307): 14: *PageNotFound
2021/02/21 14:33:50 {stonelizard}[New.go](307): 15: *PingAt
2021/02/21 14:33:50 {stonelizard}[New.go](307): 16: *SavePending
2021/02/21 14:33:50 {stonelizard}[New.go](307): 17: *SetRest
2021/02/21 14:33:50 {stonelizard}[New.go](307): 18: *Start
2021/02/21 14:33:50 {stonelizard}[New.go](307): 19: *Stop
2021/02/21 14:33:50 {stonelizard}[New.go](307): 20: *Version
2021/02/21 14:33:50 {stonelizard}[New.go](310): Method not found:
VP_ClusterDirect, Data: &reflect.rtype{size:0x100, ptrdata:0x100,
hash:0xcfbeab05, tflag:0x7, align:0x4, fieldAlign:0x4, kind:0x19,
equal:(func(unsafe.Pointer, unsafe.Pointer) bool)(nil),
gcdata:(*uint8)(0x86467d8), str:85076, ptrToThis:937664}
```

That seems to me that when I set GOARCH=386 it disables CGO, silently
ignoring any code that references to C symbols.

So, how can I statically link Go against a 32 bit (.a) library?



-- 
Luis Otavio de Colla Furquim

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACyQ4W7oh2NgcqCSM9y6dmt_%2BM-H2SW-JhNsUyaQHtRpUmL9iA%40mail.gmail.com.

[go-nuts] How to version a module that's not providing a stable API?

[Juliusz Chroboczek]

Hi,

I'm working on an application (a thing with a "main" function) that has
a user-visible version.  Since the internal modules of the project do
not have any backwards compatibility between versions, I've been tagging
releases with versions that the Go tools won't recognise (galene-0.3
instead of v0.3).

How would I tag the versions so that people can depend on my code in
their projects without implying any form of backwards compatibility when
the user-visible version goes beyond 1.0?  I'm thinking of shifting the
user-visible version number one position to the right, e.g.

  galene-0.4 -> v0.0.4
  galene-1.0 -> v0.1.0

Is that the recommended usage, or are there better ways to achieve that?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/87mtvx47dw.fsf%40pirx.irif.fr.

[go-nuts] Re: Link Go againsta a static 32 bit 3rd party library

[ma...@eliasnaur.com]

On Sunday, 21 February 2021 at 19:08:16 UTC+1 Luis Furquim wrote:

>
> That seems to me that when I set GOARCH=386 it disables CGO, silently 
> ignoring any code that references to C symbols.
>
>
>
Go disables Cgo when cross-compiling (GOARCH is different from your native 
GOARCH). You can enable Cgo manually with CGO_ENABLED=1.

Elias
 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c18776f4-191e-47cf-83cf-f8a2e350c1c5n%40googlegroups.com.

[go-nuts] Couldn't able to establish Web Socket connection when server and client running as containers in different hosts

[thatipelli santhosh]

Hi Everyone,

Server and client both are developed in go. I am using
*github.com/gorilla/websocket
 *library to establish a web socket
connection.
My server is running on port 8080 as docker container and my client (cli
tool) is running as docker container in another host. When the client
requests the server with "WS://domain_name:8080/api/connect" to establish
ws connection, nothing is happening even an error also not occurred at both
ends. It is working good in localhost but when the server and client are
running as containers, it is not working as expected.

If anyone has any idea to solve this issue,please let me know.

Any help is appreciated. Thank you!!

Sample server code:
var upgrader = websocket.Upgrader{} // use default options
func echo(w http.ResponseWriter, r *http.Request) {
c, err := upgrader.Upgrade(w, r, nil)
if err != nil {
log.Print("upgrade:", err)
return
}
defer c.Close()
for {
mt, message, err := c.ReadMessage()
if err != nil {
log.Println("read:", err)
break
}
log.Printf("recv: %s", message)
err = c.WriteMessage(mt, message)
if err != nil {
log.Println("write:", err)
break
}
}
}





Sample client code:

var addr = flag.String("addr", "localhost:8080", "http service address")
func main() {
flag.Parse()
log.SetFlags(0)
interrupt := make(chan os.Signal, 1)
signal.Notify(interrupt, os.Interrupt)
u := url.URL{Scheme: "ws", Host: *addr, Path: "/echo"}
log.Printf("connecting to %s", u.String())
c, _, err := websocket.DefaultDialer.Dial(u.String(), nil)
if err != nil {
log.Fatal("dial:", err)
}
defer c.Close()

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN1Sb7wnQHgotLADWdeKn7QT9hUP0frqML4zL4uT-H%3DMGkiLCQ%40mail.gmail.com.

[go-nuts] no generic ?

[alex-coder]

Hi all !
I'm just a beginner in Golang and I see a discussion in regards to 
introduce generics into Go.
But is it possible to provide an example where it is impossible to use 
interface instead of generic ?
Thank you in advance.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e0139450-f753-4921-ba6f-fd0b252c525cn%40googlegroups.com.

Re: [go-nuts] Re: go get not working in Go 1.16

[Richard Grosman]

Please refer to this blog post https://blog.golang.org/using-go-modules to 
get to know why go modules are better than using GOPATH (primarly for not 
messing with the import paths).

You are free to setup a local repository (localhost) by issuing the 
following commands in your project directory outside the GOPATH:
`go mod init localhost.repository` (not matching an existing domain.tld; 
creates a go.mod file)
`go mod tidy` (maintains and cleans up dependencies)

Now `go get -u` downloads and upgrades packages appropriately.
ohir schrieb am Mittwoch, 17. Februar 2021 um 13:47:58 UTC+1:

> Dnia 2021-02-16, o godz. 13:57:06
> Peter Kleiweg  napisał(a):
>
> > So why would you ever want to *not* set `GO111MODULE=auto` ?
> > 
>
> Because GOPATH mode is gonna to be slayed soon.
> It is better to use it less and less to avoid future disruption.
>
> Hope this helps,
>
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/253715c5-d5da-4c61-84b4-d860ad0fe4c5n%40googlegroups.com.

[go-nuts] [ANN] New Go video course on YouTube

[Matt KØDVB]

I've just completed my project to make a recording of my Go class and the 
videos are all now available (ad-free) on YouTube:

https://www.youtube.com/playlist?list=PLoILbKo9rG3skRCj37Kn5Zj803hhiuRK6

This class is suitable for folks who already know how to program in another 
language.It covers the basics and then some, as well as a good bit of the 
toolchain [44 segments totaling about 21 hours]. The class roughly follows *The 
Go Programming Language* and works through a few of the exercises from it. 
In the later parts I also toss in a few thoughts about software development 
& testing.

Slides and a lot of the code available on Github, referenced from the video 
segments. Some code repos have a "run on repl.it" button so you can try 
them out immediately.

I also have a repo of learning resources (references to books, videos, 
blogs, etc.) at https://github.com/matt4biz/go-resources

Constructive feedback welcome (there are already a couple of known bugs and 
one or two senior moments ;-). Enjoy!

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e0230440-ebd5-40b9-abf9-035d1cb09fa7n%40googlegroups.com.

[go-nuts] Re: Link Go againsta a static 32 bit 3rd party library

[Luis Furquim]

Great! It works!
May I post your answer (also giving the credits) on stack overflow?

Thank you!
Luis Otavio
Em domingo, 21 de fevereiro de 2021 às 15:32:47 UTC-3, ma...@eliasnaur.com 
escreveu:

> On Sunday, 21 February 2021 at 19:08:16 UTC+1 Luis Furquim wrote:
>
>>
>> That seems to me that when I set GOARCH=386 it disables CGO, silently 
>> ignoring any code that references to C symbols.
>>
>>
>>
> Go disables Cgo when cross-compiling (GOARCH is different from your native 
> GOARCH). You can enable Cgo manually with CGO_ENABLED=1.
>
> Elias
>  
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/43d1616c-af57-4ca9-ab17-ba2ca698185bn%40googlegroups.com.

Re: [go-nuts] no generic ?

[Ian Lance Taylor]

On Sun, Feb 21, 2021 at 1:02 PM alex-coder  wrote:
>
> I'm just a beginner in Golang and I see a discussion in regards to introduce 
> generics into Go.
> But is it possible to provide an example where it is impossible to use 
> interface instead of generic ?

Please see https://blog.golang.org/why-generics.

Ian

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWKX9i84OcEcRmGsv%3DrdBfqyzY54aAMA4OMSSKFLM-FZA%40mail.gmail.com.

Re: [go-nuts] Re: Link Go againsta a static 32 bit 3rd party library

[Elias Naur]

On Sun, Feb 21, 2021, 22:03 Luis Furquim  wrote:

> Great! It works!
> May I post your answer (also giving the credits) on stack overflow?
>


Sure. No credit necessary, you're doing the work of posting it :)

Elias

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMAFT9V%3D7aTaHZ-jLTcjZQVkA-wix1mJ6iC-AUaxkjKVzNoVTQ%40mail.gmail.com.

Re: [go-nuts] Error handling

[Ian Lance Taylor]

On Sun, Feb 21, 2021 at 9:23 AM robert engels  wrote:
>
> Can someone please explain the benefit of ‘error return’ over ‘checked 
> exceptions’ ? I have made the point a few times and it goes to crickets - I 
> have to believe that is because there is none, or it is difficult to 
> communicate.

As I wrote earlier, I believe that experience shows that it is
extremely difficult to write a large scale program with multiple
maintainers that uses checked exceptions.  In practice, programs
always fall back to unchecked exceptions.  So I would say that one
benefit of error return over checked exceptions is simply that error
returns scale to large programs and many maintainers.

Another benefit is described by Rob's blog post, which I'm sure you've
seen: Errors are values (https://blog.golang.org/errors-are-values).

More generally, errors are not exceptional conditions.  They are part
and parcel of how programs work.  They are part of the normal program
flow, and they should be part of that flow.  They shouldn't be
regarded as exceptional and unusual flow.

I'm not going to claim that any of these benefits are slam dunks.  If
there were obvious solutions to how to handle errors, nobody would
still be discussing different approaches.  But I am claiming that Go's
approach to error handling has real benefits.


> The ‘handle where they occur claim’ is weak, as you can handle exceptions at 
> the call site with similar LOC and constructs - but why when in most cases 
> (of non-trivial software) the error value is just returned up. No offense to 
> Wojciech - the rpc transport layer doesn’t do the retires, it passes up an 
> error, and a higher level performs retry logic, if all retries fail, it will 
> pass up another error that the rpc failed, etc. This pattern is used 
> throughout well designed software. If you hard using this pattern you are 
> creating very hard to maintain software.

I can't agree that in most cases the error is just returned up.  I
would agree that within a single package an error is often (but not
always) returned up without change.  But in large Go programs that
I've seen, when error values cross package boundaries, they are almost
always annotated with additional information.


> Checked exceptions are ‘error values’ with more information (e.g stack 
> traces, causes, etc.), and can be enforced by the compiler (declared) and 
> inspected by modern IDE’s for code complete. ‘error returns’ have none of 
> these features. The only valid claim is that they are more expensive than 
> error values, BUT you should not be using exceptions - or error values - for 
> flow control. This is the fundamental problem to me with Go’s error handling 
> - the flow control and errors are mixed leading to very difficult code to 
> read & validate that all potential paths are handled now and in the future.

My opinion, which contradicts yours, is that when the flow control is
written down on the page, as it is in Go, the flow is easy to read,
and it is much easier to check that all potential paths are handled.
With exceptions the control flow is not written down, so it is easier
to miss cases where an exception can arise.  With exceptions the
normal control flow is easier to see, but the error control flow is
harder.  And since the error control flow happens less frequently,
it's more important to make it clearly visible to the original
programmer and, more importantly, to the future maintainer.

Again, no slam dunks here.  Reasonable people can disagree.  But I
think the Go position is entirely defensible for large scale programs
with many programmers.

Ian

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW2uhrVv%2Br9Z1AdQdzGZN9JnRBWsZ6CoAQ0dg46RZGpCA%40mail.gmail.com.

Re: [go-nuts] Error handling

[robert engels]

See below:

> On Feb 21, 2021, at 3:17 PM, Ian Lance Taylor  wrote:
> 
> On Sun, Feb 21, 2021 at 9:23 AM robert engels  wrote:
>> 
>> Can someone please explain the benefit of ‘error return’ over ‘checked 
>> exceptions’ ? I have made the point a few times and it goes to crickets - I 
>> have to believe that is because there is none, or it is difficult to 
>> communicate.
> 
> As I wrote earlier, I believe that experience shows that it is
> extremely difficult to write a large scale program with multiple
> maintainers that uses checked exceptions.  In practice, programs
> always fall back to unchecked exceptions.  So I would say that one
> benefit of error return over checked exceptions is simply that error
> returns scale to large programs and many maintainers.
> 
I don’t think answering, “people fall back to unchecked exceptions” is an 
answer to “how do error returns and checked exceptions differ”.

> Another benefit is described by Rob's blog post, which I'm sure you've
> seen: Errors are values (https://blog.golang.org/errors-are-values).
> 
> More generally, errors are not exceptional conditions.  They are part
> and parcel of how programs work.  They are part of the normal program
> flow, and they should be part of that flow.  They shouldn't be
> regarded as exceptional and unusual flow.
> 
Yes, with all due respect to Rob, we'll probably disagree on that blog post. 
Take the Scan() example. This is a justification of how to write code that 
isn’t painful when you don't have exceptions - instead it puts the burden on 
the writer of Scan() to set a boolean internally to ‘don’t do anything’, write 
an additional method Err(), check the boolean on all other methods, etc., then 
the caller needs to remember to call Err() after all processing - and the code 
might loop through a billion elements doing nothing - potentially creating huge 
inefficiencies. Lastly, a reader of the code where the developer had failed to 
call Err() would not know unless they were intimately aware of the particular 
API - this is not good for long term maintenance. 

I can provide examples for each case in the blog as to why it seems more 
'defensive justification’ rather than evidence of being better.

> I'm not going to claim that any of these benefits are slam dunks.  If
> there were obvious solutions to how to handle errors, nobody would
> still be discussing different approaches.  But I am claiming that Go's
> approach to error handling has real benefits.
> 
> 
>> The ‘handle where they occur claim’ is weak, as you can handle exceptions at 
>> the call site with similar LOC and constructs - but why when in most cases 
>> (of non-trivial software) the error value is just returned up. No offense to 
>> Wojciech - the rpc transport layer doesn’t do the retires, it passes up an 
>> error, and a higher level performs retry logic, if all retries fail, it will 
>> pass up another error that the rpc failed, etc. This pattern is used 
>> throughout well designed software. If you hard using this pattern you are 
>> creating very hard to maintain software.
> 
> I can't agree that in most cases the error is just returned up.  I
> would agree that within a single package an error is often (but not
> always) returned up without change.  But in large Go programs that
> I've seen, when error values cross package boundaries, they are almost
> always annotated with additional information.
> 
> 

There is no difference between

if err != nil {
return someWrappingMethod(err)
}

and

catch (SomeException e) {
throw SomeOtherException(e);
}

but, if you don’t want or can’t provide additional information you don’t need 
to do anything, BUT you still have to declare that your method throws the 
exception - this is an important benefit.

and if you have several methods or loops that throw the exception you can move 
the handler to outside - in Go this is plain tiresome and ugly - the blog post 
tries to handle this with the Scan() and ErrWriter() - again - not handling the 
errors as they occur (so no, Go code doesn’t ‘read’ linearly - many of the LOC 
may become noops interspersed with other non-noop code which is a nightmare).

Exceptions as advanced error values as more benefits:

   1. the developer needs to declare what exceptions the method throws if any
   - this is unbelievably valuable for efficient development and 
maintenance - rather than trying to read through documentation (hopefully up to 
date) or code to try and figure out all of the possible errors a method will 
return and what they mean
   2. the ‘value’ of an exception contains a lot more information by default
- often no need to wrap, as the stack trace provides sufficient 
information, and a ‘developer label’ can easily become out of date


>> Checked exceptions are ‘error values’ with more information (e.g stack 
>> traces, causes, etc.), and can be enforced by the compiler (declared) and 
>> inspected by modern IDE’s for code complete. 

Re: [go-nuts] Error handling

[Ian Lance Taylor]

On Sun, Feb 21, 2021 at 3:01 PM robert engels  wrote:
>
> > On Feb 21, 2021, at 3:17 PM, Ian Lance Taylor  wrote:
> >
> > On Sun, Feb 21, 2021 at 9:23 AM robert engels  wrote:
> >>
> >> Can someone please explain the benefit of ‘error return’ over ‘checked 
> >> exceptions’ ? I have made the point a few times and it goes to crickets - 
> >> I have to believe that is because there is none, or it is difficult to 
> >> communicate.
> >
> > As I wrote earlier, I believe that experience shows that it is
> > extremely difficult to write a large scale program with multiple
> > maintainers that uses checked exceptions.  In practice, programs
> > always fall back to unchecked exceptions.  So I would say that one
> > benefit of error return over checked exceptions is simply that error
> > returns scale to large programs and many maintainers.
> >
> I don’t think answering, “people fall back to unchecked exceptions” is an 
> answer to “how do error returns and checked exceptions differ”.

But that isn't the question you asked.  I was trying to answer the
question quoted above: "Can someone please explain the benefit of
‘error return’ over ‘checked exceptions’ ?"

My answer to this new question "how do error returns and checked
exceptions differ” would be one about visible control flow.


> I can provide examples for each case in the blog as to why it seems more 
> 'defensive justification’ rather than evidence of being better.

We disagree.


> Exceptions as advanced error values as more benefits:
>
>1. the developer needs to declare what exceptions the method throws if any
>- this is unbelievably valuable for efficient development and 
> maintenance - rather than trying to read through documentation (hopefully up 
> to date) or code to try and figure out all of the possible errors a method 
> will return and what they mean

As I've said a couple of times, I don't think this works in actual
practice for large programs with multiple authors.  Those programs
wind up falling back to unchecked exceptions, and this advantage is
lost.  I don't consider this to be a controversial opinion; a number
of people have pointed this out.

>2. the ‘value’ of an exception contains a lot more information by default
> - often no need to wrap, as the stack trace provides sufficient 
> information, and a ‘developer label’ can easily become out of date

Sure, that is both an advantage and a disadvantage (a disadvantage
because it means that you pay a cost for every error, and that cost
may not be appropriate in all cases).

Ian

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcURf_mBRO0isfh-i-x0ch24eBG7Q-nMGMtk32%3DgkOsqEA%40mail.gmail.com.

Re: [go-nuts] Error handling

[Ian Davis]

On Sun, 21 Feb 2021, at 5:23 PM, robert engels wrote:
> Can someone please explain the benefit of ‘error return’ over ‘checked 
> exceptions’ ? I have made the point a few times and it goes to crickets 
> - I have to believe that is because there is none, or it is difficult 
> to communicate.
> 

I think since this is a Go list, the onus is on advocates of exceptions to 
demonstrate the benefit of checked exceptions over error return values.

Here are a couple of scenarios that I encountered recently that had logical 
linear flow with error returns. I'm curious how they would be improved with 
checked exceptions:

1) open three files for writing, closing the earlier ones if a subsequent one 
fails to open

2) open a file for append, falling back to creating a new writeable file if the 
original is read-only or doesn't exist. The new file creation may also fail due 
to disk errors or permissions.

I can envisage how to write them with exceptions but I'm struggling to see 
where it would be more succinct or easier to read.


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9f3cf023-5bb4-49da-a842-0be97904d21a%40www.fastmail.com.

Re: [go-nuts] Error handling

[Robert Engels]

That’s a very fair ask. I will work up some code and it will be interesting to 
see how much they actually differ. 

I do think that the differences will be more apparent in the handling of errors 
during processing - eg Scan() - than during resource 
acquisition/initialization. 

> On Feb 21, 2021, at 8:52 PM, Ian Davis  wrote:
> 
> On Sun, 21 Feb 2021, at 5:23 PM, robert engels wrote:
>> Can someone please explain the benefit of ‘error return’ over ‘checked 
>> exceptions’ ? I have made the point a few times and it goes to crickets 
>> - I have to believe that is because there is none, or it is difficult 
>> to communicate.
>> 
> 
> I think since this is a Go list, the onus is on advocates of exceptions to 
> demonstrate the benefit of checked exceptions over error return values.
> 
> Here are a couple of scenarios that I encountered recently that had logical 
> linear flow with error returns. I'm curious how they would be improved with 
> checked exceptions:
> 
> 1) open three files for writing, closing the earlier ones if a subsequent one 
> fails to open
> 
> 2) open a file for append, falling back to creating a new writeable file if 
> the original is read-only or doesn't exist. The new file creation may also 
> fail due to disk errors or permissions.
> 
> I can envisage how to write them with exceptions but I'm struggling to see 
> where it would be more succinct or easier to read.
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/9f3cf023-5bb4-49da-a842-0be97904d21a%40www.fastmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/D4D23F5D-E685-4873-BEA1-6F0179F0347D%40ix.netcom.com.

Re: [go-nuts] Go Documentation for private github projects

[Sankar]

On Saturday, 20 February 2021 at 15:58:30 UTC+5:30 mb0 wrote:

> Hi, 
> this January a fork of gddo was was announced to this list. Take a look 
> https://godocs.io/ 
>

Thanks a lot. This seems handy.
 

>
> Best regards 
>
> On 20.02.21 08:13, Sankar P wrote: 
> > Hi 
> > 
> > We have a bunch of private repos in github with Go sources. We want to 
> > see the documentation for these repository sources in an easy to click 
> URL. 
> > 
> > We are comfortable with deploying a FOSS binary/service, which can 
> > authenticate to github as a dedicated user and get the repositories. Now 
> > I want to see the docs for this. What is the way to achieve this ? 
> > 
> > In the past, I have used `godoc.org/github.com/ 
> > / ` for public repos. I 
> > want to do similarly for private repos with the `godoc.org 
> > ` replaced by our custom domain. 
> > 
> > https://github.com/golang/gddo  project 
> > is archived and I do not know what is the recommended way now. 
> > 
> > Also, we are in GCP and so if there is some easy hack to get this 
> > deployed in GCP via a single click or some such, that will also be good. 
> > Any pointers ? 
> > 
> > -- 
> > Sankar P 
> > http://psankar.blogspot.com  
> > 
> > -- 
> > 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 
> > . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/golang-nuts/CAMSEaH6OiuqY4Gx_pfbReBDE3JbdQNnUK8sovg_Q33ma45-9zQ%40mail.gmail.com
>  
> > <
> https://groups.google.com/d/msgid/golang-nuts/CAMSEaH6OiuqY4Gx_pfbReBDE3JbdQNnUK8sovg_Q33ma45-9zQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>  
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c1d9df2c-7380-4474-951b-d3660f99c208n%40googlegroups.com.