[go-nuts] Re: Recover considered harmful

[Henry]

I do think that panic should be avoided whenever possible. I had a third 
party library that panicked and crashed my application during the 
production run. If it were to return errors instead, I could have 
anticipated the problem and handled the situation with a bit more grace. 
The problem with panic is that it isn't obvious from the method signature 
that there is a possible alternate path. The author does not always 
document it. Thus, this hidden path is often unhandled and crashes the 
application. This may be acceptable during development phase, but not in 
the production run. 

I am pretty sure panic has its uses, but at the moment there are still 
people who use panic as a rare error. An error is an error. If you can 
return an error, you should return an error, even if it is rare or near 
impossible to happen. The fact that panic is used as a rare error makes it 
even dangerous because they represent the corner cases that are often 
unanticipated by the developers.

Nowadays I just wrap any third party library and use recover in case if any 
of them suddenly goes into shock and panic.

On Monday, April 24, 2017 at 4:02:55 PM UTC+7, Sokolov Yura wrote:

> Good day, people.
>
> Title is a bit controversial :-)
>
> I want to ask:
> - how useful `recover` for you?
> - Don't you think it is a bit "dangerous"?
>
> I mean: panic usually means programmer error, so if it happens, then
> program behaves incorrectly, and there is always a chance of serious
> state corruption. So, is there reason to recover at all?
>
> Also, presence of `recover` complicates implementation of `defer`.
> I believe, it could be optimized much harder in absence of `recover`
> (i.e. if program always exits on panic).
>
> I could be mistaken.
>
> Yura.
>

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

Re: [go-nuts] Recover considered harmful

[Kevin Conway]

On Mon, Apr 24, 2017, 21:31 Sam Whited  wrote:

> On Mon, Apr 24, 2017 at 6:31 PM, Dan Kortschak
>  wrote:
> > We (gonum) would extend the security exception to include scientific
> > code; there are far too many peer reviewed works that depend on code
> > that will blithely continue after an error condition that should stop
> > execution or log failure.
>
> Also a great example! The main take away here is that we should always
> design for failure, and sometimes the primary failure mode should be
> "abort at all costs and let the application developer know that
> something catastrophic happened which could lead to worse things
> happening in the future".
>
> —Sam
>

In this example we're considering panic as a mechanism of preventing
otherwise avoidable code bugs. What happens when the same code begins
silencing panics and continuing on? Do we add a new level of panic that
overcomes the normal recovery method? The fundamental assertion being made
by panic advocates is that you know better than I when my program should
end and you want some mechanism to enforce that opinion on me.

I'll argue that sticking to idiomatic errors returned by function calls
combined with static analysis tools, like errcheck, are sufficient in
solving for all scenarios where panic might otherwise be used to signal an
error state. If you want to use panic internally within an API that's
completely acceptable so long as that panic is never exposed beyond the API
boundary. To quote the golang blog on the subject:

The convention in the Go libraries is that even when a package uses panic
internally, its external API still presents explicit error return values.

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

Re: [go-nuts] doubt about sync.NewCond

[Yanchun Ni]

Got it. Thank you.

在 2017年4月22日星期六 UTC+8上午9:52:45，Matt Harden写道：
>
> There is no guarantee that any of your goroutines will execute even 
> Lock(), much less Wait(), before the main goroutine executes Broadcast().
>
> On Thu, Apr 20, 2017 at 8:39 PM Allan  
> wrote:
>
>> I run a demo program to learn sync.NewCond：
>>
>> package main
>>
>> import (
>>"fmt"
>>"sync"
>>"time"
>> )
>>
>> var locker = new(sync.Mutex)
>> var cond = sync.NewCond(locker)
>>
>> func test(x int) {
>>
>>cond.L.Lock() 
>>cond.Wait()   
>>fmt.Println(x)
>>time.Sleep(time.Second * 1)
>>cond.L.Unlock() 
>> }
>> func main() {
>>for i := 0; i < 10; i++ {
>>   go test(i)
>>}
>>fmt.Println("start all")
>>cond.Broadcast() 
>>time.Sleep(time.Second * 60)
>> }
>>
>>
>> When I run this program on Mac(Sierra 10.12.4)，it will print 0~9 
>> randomly. But When I run it on Ubuntu 16.04, its result is not unique, 
>> sometime just print "start all", sometimes print some numbers but not all. 
>> I debug it with dlv, and the stack is as below:
>>
>> (dlv) bt
>> 0  0x00453693 in runtime.futex
>>at /usr/local/go/src/runtime/sys_linux_amd64.s:388
>> 1  0x004238de in runtime.futexsleep
>>at /usr/local/go/src/runtime/os_linux.go:62
>> 2  0x0040c370 in runtime.notetsleep_internal
>>at /usr/local/go/src/runtime/lock_futex.go:174
>> 3  0x0040c4e2 in runtime.notetsleepg
>>at /usr/local/go/src/runtime/lock_futex.go:206
>> 4  0x0043fff8 in runtime.timerproc
>>at /usr/local/go/src/runtime/time.go:209
>> 5  0x004525f0 in runtime.goexit
>>at /usr/local/go/src/runtime/asm_amd64.s:2086
>> (dlv) goroutine
>> Thread 9327 at /usr/local/go/src/runtime/sys_linux_amd64.s:388
>> Goroutine 15:
>> Runtime: /usr/local/go/src/runtime/lock_futex.go:206 runtime.notetsleepg 
>> (0x40c4e2)
>> User: /usr/local/go/src/runtime/lock_futex.go:206 runtime.notetsleepg 
>> (0x40c4e2)
>> Go: /usr/local/go/src/runtime/time.go:97 runtime.addtimerLocked (0x43fc2e)
>> (dlv) goroutines
>> [15 goroutines]
>>   Goroutine 1 - User: /usr/local/go/src/runtime/time.go:59 time.Sleep 
>> (0x43fa55)
>>   Goroutine 2 - User: /usr/local/go/src/runtime/proc.go:260 
>> runtime.gopark (0x4283fa)
>>   Goroutine 3 - User: /usr/local/go/src/runtime/proc.go:260 
>> runtime.gopark (0x4283fa)
>>   Goroutine 4 - User: /usr/local/go/src/runtime/proc.go:260 
>> runtime.gopark (0x4283fa)
>>   Goroutine 5 - User: /usr/local/go/src/runtime/sema.go:267 
>> sync.runtime_notifyListWait (0x436341)
>>   Goroutine 6 - User: /usr/local/go/src/runtime/sema.go:267 
>> sync.runtime_notifyListWait (0x436341)
>>   Goroutine 7 - User: /usr/local/go/src/runtime/sema.go:267 
>> sync.runtime_notifyListWait (0x436341)
>>   Goroutine 8 - User: /usr/local/go/src/runtime/sema.go:267 
>> sync.runtime_notifyListWait (0x436341)
>>   Goroutine 9 - User: /usr/local/go/src/runtime/sema.go:267 
>> sync.runtime_notifyListWait (0x436341)
>>   Goroutine 10 - User: /usr/local/go/src/runtime/sema.go:267 
>> sync.runtime_notifyListWait (0x436341)
>>   Goroutine 11 - User: /usr/local/go/src/runtime/sema.go:267 
>> sync.runtime_notifyListWait (0x436341)
>>   Goroutine 12 - User: /usr/local/go/src/runtime/sema.go:267 
>> sync.runtime_notifyListWait (0x436341)
>>   Goroutine 13 - User: /usr/local/go/src/runtime/sema.go:267 
>> sync.runtime_notifyListWait (0x436341)
>>   Goroutine 14 - User: /usr/local/go/src/runtime/sema.go:267 
>> sync.runtime_notifyListWait (0x436341)
>> * Goroutine 15 - User: /usr/local/go/src/runtime/lock_futex.go:206 
>> runtime.notetsleepg (0x40c4e2) 
>>
>>
>> I'm not familiar to the raw code，can someone give me some help. Thx.
>>
>> BTW: My golang version is go version go1.7.4 linux/amd64.
>>
>> -- 
>> 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.
>>
>

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

Re: [go-nuts] Recover considered harmful

[Sam Whited]

On Mon, Apr 24, 2017 at 6:31 PM, Dan Kortschak
 wrote:
> We (gonum) would extend the security exception to include scientific
> code; there are far too many peer reviewed works that depend on code
> that will blithely continue after an error condition that should stop
> execution or log failure.

Also a great example! The main take away here is that we should always
design for failure, and sometimes the primary failure mode should be
"abort at all costs and let the application developer know that
something catastrophic happened which could lead to worse things
happening in the future".

—Sam

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

Re: [go-nuts] Recover considered harmful

[Dan Kortschak]

We (gonum) would extend the security exception to include scientific
code; there are far too many peer reviewed works that depend on code
that will blithely continue after an error condition that should stop
execution or log failure. These can and do end up contributing to costs
of (mis)development of pharmacuetical and other health-related
technologies and worse in patient health outcome failures (also
probably in other field, but I those are outside my expertise).

For horror, see this talk https://youtu.be/7gYIs7uYbMo?t=523 (time at
point in talk where he talks about the software issues that ultimately
resulted in drug trials based on completely spurious data).

On Mon, 2017-04-24 at 08:41 -0500, Sam Whited wrote:
> While I generally agree with you, panics in libraries should probably
> not bubble up to anythihng outside of the library, the exception is
> security issues. If for some reason I can't get a handle to
> urandom(4)
> I'd probably rather crash the program than risk having another
> developer ignore that error and generate keys with a zeroed IV (or
> whatever the case may be).

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

Re: [go-nuts] Set a SAN otherName using `x509.CertificateRequest`

[Janne Snabb]

Yes, but not as easily as using DNSName. You need to add the extension
"manually".

Put it in ExtraExtensions of the template. See
/usr/local/go/src/crypto/x509/x509.go functions buildExtensions and
marshalSANs to see how to put it there.


Janne Snabb
sn...@epipe.com

On 2017-04-24 18:28, Adam Medziński wrote:
> Is it possible to set a SAN otherName in x509.CertificateRequest
>  structure, so
> it will be present in the DER encoded output
> of x509.CreateCertificateRequest
> ?
> 
> -- 
> 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
> .
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] gopacket.Newpacket does not provide MetaData for the new packet??

[Chun Zhang]

Hi, all,

I am trying to capture a GRE tunneled packet and get rid off the GRE header 
to retrieve the encapsulated packet. 

The code is quite simple, I basically grabs the GRE tunneled packet and 
build a new one from its payload. The problem I have here is the MetaData 
of the packet1 channel is completely empty, even though the decoded layers 
look just fine.

Can anybody help me to figure out where I made the mistake?

Thanks,
Chun

- code snip --
packetSource := gopacket.NewPacketSource(handle, handle.LinkType())
for packet := range packetSource.Packets() {
if packet.Layer(layers.LayerTypeGRE) == nil {
fmt.Println("not gre kets")
//if this is not a GRE tunneled pkt, then this is 
not what we are looking for
continue
}

fmt.Println("find a GRE tunnedl pkt")
packet1 := 
gopacket.NewPacket(packet.Layer(layers.LayerTypeGRE).LayerPayload(), 
layers.LinkTypeEthernet, gopacket.Default)
// shouldn't a channel type of Packet being returned here, with Metadata() 
method implemented?

// Process packet here
fmt.Println(packet1)

fmt.Println("capture lenght:", 
packet1.Metadata().CaptureLength, "timestamp:", 
packet1.Metadata().Timestamp, "capture info:", 
packet1.Metadata().CaptureInfo)
w.WritePacket(packet1.Metadata().CaptureInfo, 
packet1.Data())
packetCount++


-- console print  test.pcap is completely empty since the 
capture length from the metadata is 0

find a GRE tunnedl pkt
PACKET: 64 bytes
- Layer 1 (14 bytes) = Ethernet {Contents=[..14..] Payload=[..50..] 
SrcMAC=00:04:96:6d:49:00 DstMAC=00:50:56:88:4e:2d EthernetType=Dot1Q 
Length=0}
- Layer 2 (04 bytes) = Dot1Q{Contents=[0, 69, 8, 0] Payload=[..46..] 
Priority=0 DropEligible=false VLANIdentifier=69 Type=IPv4}
- Layer 3 (20 bytes) = IPv4 {Contents=[..20..] Payload=[..20..] 
Version=4 IHL=5 TOS=16 Length=40 Id=25729 Flags=DF FragOffset=0 TTL=59 
Protocol=TCP Checksum=6231 SrcIP=10.6.105.21 DstIP=10.68.69.137 Options=[] 
Padding=[]}
- Layer 4 (20 bytes) = TCP  {Contents=[..20..] Payload=[] SrcPort=50507 
DstPort=22(ssh) Seq=3986061698 Ack=2511277766 DataOffset=5 FIN=false 
SYN=false RST=false PSH=false ACK=true URG=false ECE=false CWR=false 
NS=false Window=8039 Checksum=64660 Urgent=0 Options=[] Padding=[]}

capture lenght: 0 timestamp: 0001-01-01 00:00:00 + UTC capture info: 
{0001-01-01 00:00:00 + UTC 0 0 0}

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

[go-nuts] Re: [Help] Seeing an occasional data race on a closed channel

[dwahler]

Hi Owen,


On Monday, April 24, 2017 at 1:23:58 PM UTC-5, Owen Waller wrote:
>
> My understanding is that when a key is pressed that will terminate the 
> program. This closes the quit channel, which causes the deferred 
> closeChans() to be called. That in turn closes the done and the bus 
> channels in that order. Closing the done channel causes the select in 
> simBus() to complete in the <-done case. This causes the bus channel to 
> drain. The next call to writeToBus, which is triggered by the timer going 
> off - should then fail. The cancelled() function should return true at this 
> point so no attempt should be made to write to the bus channel.
>
> As I understand the data race below, this logic is flawed. Attempts are 
> being made to write to the bus channel after it has been closed.
>
>
>
The race detector is correct. When you write "the next call to write to 
us", you're making a faulty assumption -- namely, the assumption that each 
call to writeToBus happens either before closeChans, or after closeChans. 
But the two functions are called by separate goroutines and can execute 
concurrently. So one can write to the bus while the other is trying to 
close it, which is a race condition.

(Similarly, when you write things like "Closing the done causes the select 
in simBus() to complete, you should always remember that each read from a 
channel happens *after* the corresponding write, asynchronously, at a time 
which is not guaranteed.)

This is a fundamental flaw with your approach. The only goroutine that can 
safely close a channel is the one that is writing to it. So your dataPump 
function needs to be the one to listen for the "quit" signal.

Hope this helps!
-- David

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

[go-nuts] [Help] Seeing an occasional data race on a closed channel

[Tamás Gulácsi]

after calling canceled, but before sending on bus, you can close the channels.

Put i in one select:
select {
case <-done:
default:
  select {
case <-done:
case bus<-r:
  }
}

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

Re: [go-nuts] Re: Semicolons in Go

[john . deighan]

Ian, thank you for the thoughtful reply. I realized that my last post might 
have sounded like I was criticizing your post and that definitely wasn't 
the intention. My apologies.

On Monday, April 24, 2017 at 10:48:25 AM UTC-4, Ian Davis wrote:
>
> With respect, you are tilting at windmills. You replied to an 8 year old 
> post from the design phase of the language. It's now 2017 and no-one wants 
> to step back in time to change what has turned out to be a very successful 
> design.
>
> You stated in your first message that you "simply won't use the language" 
> because it doesn't conform to your learned preferences. I hope you 
> reconsider and adapt to what is ultimately a minor part of learning a new 
> language.
>
> Ian
>
>
> On Mon, 24 Apr 2017, at 03:42 PM, john.d...@gmail.com  wrote:
>
> One of the things that I learned early in life is to recognize B.S. when I 
> see it. My B.S. flag went up first when I read where someone claimed that 
> "artifacts" are bad and detract from the readability of code. A compact and 
> well-defined artifact, like the semicolon, makes code *more* readable 
> because the programmer's intent is crystal clear, whereas removing them 
> leaves one guessing exactly where a line ends. The rules are considerably 
> more complex - not to mention vary across languages, than the simple "it 
> ends at the semicolon" rule.
>
> Now I read that the programmer's preference is irrelevant (I hope that we 
> can agree that the programming community consists of individual 
> programmers!). Well, that flag just shot up again. There's no reason that 
> an individual's preference can't be respected when he's editing code, even 
> if way that the code is stored on disk is the same. That's why I 
> exclusively use TAB characters for indentation - some people prefer to see 
> 2 spaces per level of structure, I prefer 3 spaces and someone at my 
> company prefers 8. We get to see what we prefer without requiring any 
> changes to the code itself.
>
> So, here's my current thinking about long lines/continuation lines, take 
> it for what it's worth. There should be no such thing in a language. A long 
> line should just be a long line, without limit, in the source file. After 
> all, it's not the compiler that wants to split long lines so that they are 
> more readable - it's the programmer when using a text editor or code 
> viewer. Think how much simpler a compiler would be if it could just assume 
> that a simple (i.e. non-compound) statement always exists on a single line! 
> It's the editor that should display a single simple statement on multiple 
> lines on the screen. In fact, the editor could provide visual cues that a 
> single statement is being displayed on multiple lines on the screen, such 
> as a light gray background color, underlining, box around it, whatever. The 
> point is that the individual programmer's personal preference would be used 
> without affecting the saved format of the code.
>
> For that to work well, the editor would probably have to understand the 
> syntax of a statement so that the line splitting will result in something 
> that the programmer finds readable. I don't know if a current editor that 
> can do that. But line splitting is something that the compiler should *not* 
> have to deal with. After all, it's the programmer using an editor that 
> cares about making long lines readable, not the compiler.
>
>
> --
> 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.
>
>
>

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

[go-nuts] [Help] Seeing an occasional data race on a closed channel

[Owen Waller]

Hi All,

I am stumped by this one, so I am hoping that someone on the list can
spot the bug in this piece of code.

The code is here:

https://play.golang.org/p/c3356cVtWa

The code occasionally (roughly 1 in 10 to 1 in 5 on my hardware) fails
with the data race shown below.

The code uses a fairly high frequency timer (order of tens of
milliseconds) as a data pump to push runes into a channel. That channel
is then read and displayed to the terminal. This code that the example
is derived from is a simulation of data being written to/read from a
i2c data bus. Hence the high data rate.

My understanding is that when a key is pressed that will terminate the
program. This closes the quit channel, which causes the deferred
closeChans() to be called. That in turn closes the done and the bus
channels in that order. Closing the done channel causes the select in
simBus() to complete in the <-done case. This causes the bus channel to
drain. The next call to writeToBus, which is triggered by the timer
going off - should then fail. The cancelled() function should return
true at this point so no attempt should be made to write to the bus
channel.

As I understand the data race below, this logic is flawed. Attempts are
being made to write to the bus channel after it has been closed.

So far I can't work out why, so I'm hoping someone else can.

Many thanks

Owen

Go version 1.8.1 on Linux/AMD64

==
WARNING: DATA RACE
Write at 0x00c420074060 by main goroutine:
  runtime.closechan()
  /home/owen/golang/go/src/runtime/chan.go:320 +0x0
  main.closeChans()
  /home/owen/go/src/github.com/owenwaller/tcellchanpanic/tcellchanp
anic.go:24 +0x6a
  runtime.call32()
  /home/owen/golang/go/src/runtime/asm_amd64.s:514 +0x47

Previous read at 0x00c420074060 by goroutine 7:
  runtime.chansend()
  /home/owen/golang/go/src/runtime/chan.go:128 +0x0
  main.writeToBus()
  /home/owen/go/src/github.com/owenwaller/tcellchanpanic/tcellchanp
anic.go:49 +0x88
  main.dataPump()
  /home/owen/go/src/github.com/owenwaller/tcellchanpanic/tcellchanp
anic.go:39 +0x11f

Goroutine 7 (running) created at:
  main.main()
  /home/owen/go/src/github.com/owenwaller/tcellchanpanic/tcellchanp
anic.go:87 +0x16e
==
panic: end of program - only one go routine

goroutine 1 [running]:
main.main()
/home/owen/go/src/github.com/owenwaller/tcellchanpanic/tcellcha
npanic.go:91 +0x21b

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

Re: [go-nuts] Recover considered harmful

[roger peppe]

On 24 April 2017 at 14:09, Rob Pike  wrote:
> Your point 3 misses an important practical detail. Packages that use recover
> internally call panic with an identifiable type and the recover code checks
> whether the type is the expected one and, if not, panics again, thus
> behaving like any other unexpected problem.
>
> See encoding/gob/error.go for an example.
>
> More generally, recover is excellent for isolation of errors in multi-client
> servers.

I've certainly used both these techniques in the past, but I'm no longer
entirely sure whether this really is "excellent". It's so easy to have
code that relies on non-deferred cleanup of state that invokes some
code that happens to panic (whether with a known type or not), leading
to hard-to-debug problems that would have been considerably easier if
the whole thing had just crashed.

In general, the only time I'd now consider using the "panic with
identifiable type" technique is in recursive descent parsers and the
like, where the domain is severely constrained and the convenience of
being able to use the results of called functions directly is great.

That said, my most recent use was to exit early from sort.Search when an
unexpected error occurred talking to the network. Useful but arguably
a bit dirty.

  rog.

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

[go-nuts] Extensible markdown library

[Achim Domma]

Hi,

I'm rather new to Go and for a toy project, I would need to extend markdown 
with custom syntax. For example "{key: 123}" should be parsed and handled 
in a special way, so that I can access all occurrences of keys and ids 
after the transformation. I found that there are different markdown 
libraries in Go and would appreciate, if somebody could recommend the most 
"hackable" one.

kind regards,
Achim

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

[go-nuts] [ANN] 2nd Call for Papers: 16th ACM SIGPLAN Erlang Workshop 2017

[Natalia Chechina]

Technical, practice, and application papers related to Go are welcome and 
encouraged!

2nd CALL FOR PAPERS
===

Sixteenth ACM SIGPLAN Erlang Workshop
http://erlang.org/workshop/2017/
---

Oxford, United Kingdom, 8 September 2017
Satellite event of the 22nd ACM SIGPLAN International Conference on
Functional Programming (ICFP 2017)
3 - 9 September, 2017

The Erlang Workshop aims to bring together the open source, academic,
and industrial communities of Erlang, to discuss technologies and
languages related to Erlang. The Erlang model of concurrent programming
has been widely emulated, for example by Akka in Scala, and even new
programming languages were designed atop of the Erlang VM, such as
Elixir. Therefore we would like to broaden the scope of the workshop
to include systems like those mentioned above.

The workshop will enable participants to familiarize themselves with
recent developments on new techniques and tools, novel applications,
draw lessons from users' experiences and identify research problems
and common areas relevant to the practice of Erlang, Erlang-like
languages, functional programming, distribution, concurrency etc.

We invite three types of submissions.

1. Technical papers describing language extensions, critical
discussions of the status quo, formal semantics of language
constructs, program analysis and transformation, virtual machine
extensions and compilation techniques, implementations and interfaces
of Erlang in/with other languages, and new tools (profilers, tracers,
debuggers, testing frameworks, etc.). Submission related to Erlang, 
Elixir, Akka, CloudHaskell, Ocaml, Go, and functional programming are 
welcome and encouraged. The maximum length for technical papers is 
restricted to 12 pages.

2. Practice and application papers describing uses of Erlang in the
"real-world", Erlang libraries for specific tasks, experiences from
using Erlang in specific application domains, reusable programming
idioms and elegant new ways of using Erlang to approach or solve a
particular problem. The maximum length for the practice and
application papers is restricted to 12 pages. Note that this is a
maximum length; we welcome shorter papers also, and the program
committee will evaluate all papers on an equal basis independent of
their lengths.

3. Poster presentations describing topics related to the workshop
goals. Each includes a maximum of 2 pages of the abstract and summary.
Presentations in this category will be given an hour of shared
simultaneous demonstration time.

Workshop Co-Chairs
--
Scott Lystig Fritchie, VMware, USA
Natalia Chechina, Glasgow University, UK

Program Committee
-
(Note: the Workshop Co-Chairs are also committee members)

Clara Benac Earle, Universidad Politecnica de Madrid, Spain
Richard Carlsson, Klarna, Sweden
Laura M. Castro, University of A Coruna, Spain
Viktoria Fördős, Klarna, Sweden
James S. Larson, Google, USA

Important Dates
---
Submission deadline: Fri May 26, 2017
Author notification: Fri June 23, 2017
Final submission for the publisher: Sat July 15, 2017
Workshop date: Fri September 8, 2017

Instructions to authors

Papers must be submitted online via EasyChair (via the "Erlang2017"
event). The submission page is
https://www.easychair.org/conferences/?conf=erlang2017

Submitted papers should be in portable document format (PDF),
formatted using the ACM SIGPLAN style guidelines.

Each submission must adhere to SIGPLAN's republication policy.
Violation risks summary rejection of the offending submission.
Accepted papers will be published by the ACM and will appear in the
ACM Digital Library.

The proceedings will be freely available for download from the ACM Digital
Library from one week before the start of the conference until two weeks 
after the conference.

Paper submissions will be considered for poster submission in the case
they are not accepted as full papers.

Venue & Registration Details
--
For registration, please see the ICFP 2017 web site at:
http://icfp17.sigplan.org/

Related Links

ICFP 2017 web site: http://icfp17.sigplan.org/
Past ACM SIGPLAN Erlang workshops: http://www.erlang.org/workshop/
Open Source Erlang: http://www.erlang.org/
EasyChair submission site:
https://www.easychair.org/conferences/?conf=erlang2017
Author Information for SIGPLAN Conferences:
http://www.sigplan.org/authorInformation.htm
Atendee Information for SIGPLAN Events:
http://www.sigplan.org/Resources/Policies/CodeOfConduct/

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

[go-nuts] Set a SAN otherName using `x509.CertificateRequest`

[Adam Medziński]

Is it possible to set a SAN otherName in x509.CertificateRequest 
 structure, so it 
will be present in the DER encoded output of x509.CreateCertificateRequest 
?

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

[go-nuts] Dynamic type assertion for interface

[Rajesh kumar]

Please do note that the structs in this example is a sample.My struct is 
complex than this.
https://play.golang.org/p/_t7gx3javb 
Here I have a function where i will be using lot of times.Each time i will 
be passing object of different struct types.So i use the parameter 
arguments as interface{}. So to solve the error i need to do type 
assertion.But here the interface can be of any struct type.So i am looking 
if there is any possible way to do the dynamic type assertion based on the 
reflect.TypeOf value.

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

Re: [go-nuts] https://go-proverbs.github.io/ what do you think of this one ?

[Jan Mercl]

On Mon, Apr 24, 2017 at 4:39 PM  wrote:

> Any thoughts?

Yes. In the second version there is something that can be withdrawn. The
special case of handling an error value, which is just an interface value
like many other interface values. Getting rid of that special case and the
special syntax for handling it results in the current language
specification.


-- 

-j

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

Re: [go-nuts] Re: Semicolons in Go

[David Peacock]

Please don't feed this troll.

On Mon, Apr 24, 2017 at 10:42 AM,  wrote:

> One of the things that I learned early in life is to recognize B.S. when I
> see it. My B.S. flag went up first when I read where someone claimed that
> "artifacts" are bad and detract from the readability of code. A compact and
> well-defined artifact, like the semicolon, makes code *more* readable
> because the programmer's intent is crystal clear, whereas removing them
> leaves one guessing exactly where a line ends. The rules are considerably
> more complex - not to mention vary across languages, than the simple "it
> ends at the semicolon" rule.
>
> Now I read that the programmer's preference is irrelevant (I hope that we
> can agree that the programming community consists of individual
> programmers!). Well, that flag just shot up again. There's no reason that
> an individual's preference can't be respected when he's editing code, even
> if way that the code is stored on disk is the same. That's why I
> exclusively use TAB characters for indentation - some people prefer to see
> 2 spaces per level of structure, I prefer 3 spaces and someone at my
> company prefers 8. We get to see what we prefer without requiring any
> changes to the code itself.
>
> So, here's my current thinking about long lines/continuation lines, take
> it for what it's worth. There should be no such thing in a language. A long
> line should just be a long line, without limit, in the source file. After
> all, it's not the compiler that wants to split long lines so that they are
> more readable - it's the programmer when using a text editor or code
> viewer. Think how much simpler a compiler would be if it could just assume
> that a simple (i.e. non-compound) statement always exists on a single line!
> It's the editor that should display a single simple statement on multiple
> lines on the screen. In fact, the editor could provide visual cues that a
> single statement is being displayed on multiple lines on the screen, such
> as a light gray background color, underlining, box around it, whatever. The
> point is that the individual programmer's personal preference would be used
> without affecting the saved format of the code.
>
> For that to work well, the editor would probably have to understand the
> syntax of a statement so that the line splitting will result in something
> that the programmer finds readable. I don't know if a current editor that
> can do that. But line splitting is something that the compiler should *not*
> have to deal with. After all, it's the programmer using an editor that
> cares about making long lines readable, not the compiler.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Recover considered harmful

[Sam Whited]

On Mon, Apr 24, 2017 at 9:30 AM, Юрий Соколов  wrote:
> :-)
> Does os.Exit(1) prints backtrace of all goroutines like unrecovered panic
> does?

import "runtime/debug"
fmt.Fprintf(os.Stderr, "it's full of stars!\n")
debug.PrintStack()
os.Exit(1)

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

Re: [go-nuts] Re: Semicolons in Go

[John Deighan]

I won't. I'm done with this thread.

On Mon, Apr 24, 2017 at 10:52 AM David Peacock 
wrote:

> Please don't feed this troll.
>
> On Mon, Apr 24, 2017 at 10:42 AM,  wrote:
>
>> One of the things that I learned early in life is to recognize B.S. when
>> I see it. My B.S. flag went up first when I read where someone claimed that
>> "artifacts" are bad and detract from the readability of code. A compact and
>> well-defined artifact, like the semicolon, makes code *more* readable
>> because the programmer's intent is crystal clear, whereas removing them
>> leaves one guessing exactly where a line ends. The rules are considerably
>> more complex - not to mention vary across languages, than the simple "it
>> ends at the semicolon" rule.
>>
>> Now I read that the programmer's preference is irrelevant (I hope that we
>> can agree that the programming community consists of individual
>> programmers!). Well, that flag just shot up again. There's no reason that
>> an individual's preference can't be respected when he's editing code, even
>> if way that the code is stored on disk is the same. That's why I
>> exclusively use TAB characters for indentation - some people prefer to see
>> 2 spaces per level of structure, I prefer 3 spaces and someone at my
>> company prefers 8. We get to see what we prefer without requiring any
>> changes to the code itself.
>>
>> So, here's my current thinking about long lines/continuation lines, take
>> it for what it's worth. There should be no such thing in a language. A long
>> line should just be a long line, without limit, in the source file. After
>> all, it's not the compiler that wants to split long lines so that they are
>> more readable - it's the programmer when using a text editor or code
>> viewer. Think how much simpler a compiler would be if it could just assume
>> that a simple (i.e. non-compound) statement always exists on a single line!
>> It's the editor that should display a single simple statement on multiple
>> lines on the screen. In fact, the editor could provide visual cues that a
>> single statement is being displayed on multiple lines on the screen, such
>> as a light gray background color, underlining, box around it, whatever. The
>> point is that the individual programmer's personal preference would be used
>> without affecting the saved format of the code.
>>
>> For that to work well, the editor would probably have to understand the
>> syntax of a statement so that the line splitting will result in something
>> that the programmer finds readable. I don't know if a current editor that
>> can do that. But line splitting is something that the compiler should *not*
>> have to deal with. After all, it's the programmer using an editor that
>> cares about making long lines readable, not the compiler.
>>
> --
>>
> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [go-nuts] Re: Semicolons in Go

[Ian Davis]

With respect, you are tilting at windmills. You replied to an 8 year old
post from the design phase of the language. It's now 2017 and no-one
wants to step back in time to change what has turned out to be a very
successful design.
You stated in your first message that you "simply won't use the
language" because it doesn't conform to your learned preferences. I hope
you reconsider and adapt to what is ultimately a minor part of learning
a new language.
Ian


On Mon, 24 Apr 2017, at 03:42 PM, john.deig...@gmail.com wrote:
> One of the things that I learned early in life is to recognize B.S.
> when I see it. My B.S. flag went up first when I read where someone
> claimed that "artifacts" are bad and detract from the readability of
> code. A compact and well-defined artifact, like the semicolon, makes
> code *more* readable because the programmer's intent is crystal clear,
> whereas removing them leaves one guessing exactly where a line ends.
> The rules are considerably more complex - not to mention vary across
> languages, than the simple "it ends at the semicolon" rule.> 
> Now I read that the programmer's preference is irrelevant (I hope that
> we can agree that the programming community consists of individual
> programmers!). Well, that flag just shot up again. There's no reason
> that an individual's preference can't be respected when he's editing
> code, even if way that the code is stored on disk is the same. That's
> why I exclusively use TAB characters for indentation - some people
> prefer to see 2 spaces per level of structure, I prefer 3 spaces and
> someone at my company prefers 8. We get to see what we prefer without
> requiring any changes to the code itself.> 
> So, here's my current thinking about long lines/continuation lines,
> take it for what it's worth. There should be no such thing in a
> language. A long line should just be a long line, without limit, in
> the source file. After all, it's not the compiler that wants to split
> long lines so that they are more readable - it's the programmer when
> using a text editor or code viewer. Think how much simpler a compiler
> would be if it could just assume that a simple (i.e. non-compound)
> statement always exists on a single line! It's the editor that should
> display a single simple statement on multiple lines on the screen. In
> fact, the editor could provide visual cues that a single statement is
> being displayed on multiple lines on the screen, such as a light gray
> background color, underlining, box around it, whatever. The point is
> that the individual programmer's personal preference would be used
> without affecting the saved format of the code.> 
> For that to work well, the editor would probably have to understand
> the syntax of a statement so that the line splitting will result in
> something that the programmer finds readable. I don't know if a
> current editor that can do that. But line splitting is something that
> the compiler should *not* have to deal with. After all, it's the
> programmer using an editor that cares about making long lines
> readable, not the compiler.> 


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

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

Re: [go-nuts] Re: Semicolons in Go

[john . deighan]

One of the things that I learned early in life is to recognize B.S. when I 
see it. My B.S. flag went up first when I read where someone claimed that 
"artifacts" are bad and detract from the readability of code. A compact and 
well-defined artifact, like the semicolon, makes code *more* readable 
because the programmer's intent is crystal clear, whereas removing them 
leaves one guessing exactly where a line ends. The rules are considerably 
more complex - not to mention vary across languages, than the simple "it 
ends at the semicolon" rule.

Now I read that the programmer's preference is irrelevant (I hope that we 
can agree that the programming community consists of individual 
programmers!). Well, that flag just shot up again. There's no reason that 
an individual's preference can't be respected when he's editing code, even 
if way that the code is stored on disk is the same. That's why I 
exclusively use TAB characters for indentation - some people prefer to see 
2 spaces per level of structure, I prefer 3 spaces and someone at my 
company prefers 8. We get to see what we prefer without requiring any 
changes to the code itself.

So, here's my current thinking about long lines/continuation lines, take it 
for what it's worth. There should be no such thing in a language. A long 
line should just be a long line, without limit, in the source file. After 
all, it's not the compiler that wants to split long lines so that they are 
more readable - it's the programmer when using a text editor or code 
viewer. Think how much simpler a compiler would be if it could just assume 
that a simple (i.e. non-compound) statement always exists on a single line! 
It's the editor that should display a single simple statement on multiple 
lines on the screen. In fact, the editor could provide visual cues that a 
single statement is being displayed on multiple lines on the screen, such 
as a light gray background color, underlining, box around it, whatever. The 
point is that the individual programmer's personal preference would be used 
without affecting the saved format of the code.

For that to work well, the editor would probably have to understand the 
syntax of a statement so that the line splitting will result in something 
that the programmer finds readable. I don't know if a current editor that 
can do that. But line splitting is something that the compiler should *not* 
have to deal with. After all, it's the programmer using an editor that 
cares about making long lines readable, not the compiler.

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

[go-nuts] https://go-proverbs.github.io/ what do you think of this one ?

[mhhcbon]

Perfection is attained, not when there is nothing more to add, but when 
there is nothing more to be withdrawn.


somehow relates to https://www.youtube.com/watch?v=rFejpH_tAHM

If i just try to think to apply it to this code sample


func getCwd() (string, error) {
cwd, err := os.Getwd()
if err != nil {
return "", fmt.Errorf("Failed to determmine cwd: %v", err)
}
// for those who uses symlinks to relocate their code,
// the path must be evaluated.
cwd, err = filepath.EvalSymlinks(cwd)
if err != nil {
return "", fmt.Errorf("Failed to determmine eval path: %v", err)
}
return cwd, nil
}


There are few things that might be considered fatty


func getCwd() (string, error) {

cwd, err := os.Getwd() or 
return ...fmt.Errorf("Failed to determmine cwd: %v", err)

// for those who uses symlinks to relocate their code,
// the path must be evaluated.
cwd, err = filepath.EvalSymlinks(cwd) or 
return ...fmt.Errorf("Failed to eval cwd: %v", err)

return cwd...
}


Any thoughts?

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

Re: [go-nuts] Recover considered harmful

[Юрий Соколов]

:-)
Does os.Exit(1) prints backtrace of all goroutines like unrecovered panic
does?

2017-04-24 16:53 GMT+03:00 Jan Mercl <0xj...@gmail.com>:

> On Mon, Apr 24, 2017 at 3:19 PM Sokolov Yura 
> wrote:
>
> > And what about unrecoverable panic? C-style `assert`?
>
> fmt.Fprintf(os.Stderr, "it's full of stars!\n")
> os.Exit(1)
>
> --
>
> -j
>

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

Re: [go-nuts] Recover considered harmful

[Jan Mercl]

On Mon, Apr 24, 2017 at 3:19 PM Sokolov Yura  wrote:

> And what about unrecoverable panic? C-style `assert`?

fmt.Fprintf(os.Stderr, "it's full of stars!\n")
os.Exit(1)

-- 

-j

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

Re: [go-nuts] Recover considered harmful

[Sam Whited]

On Mon, Apr 24, 2017 at 7:39 AM, Kevin Conway
 wrote:
> I've yet to find a panic that would not be better served as a returned
> error.

While I generally agree with you, panics in libraries should probably
not bubble up to anythihng outside of the library, the exception is
security issues. If for some reason I can't get a handle to urandom(4)
I'd probably rather crash the program than risk having another
developer ignore that error and generate keys with a zeroed IV (or
whatever the case may be).

—Sam

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

Re: [go-nuts] Recover considered harmful

[Sokolov Yura]

понедельник, 24 апреля 2017 г., 16:09:56 UTC+3 пользователь Rob 'Commander' 
Pike написал:
>
> Your point 3 misses an important practical detail. Packages that use 
> recover internally call panic with an identifiable type and the recover 
> code checks whether the type is the expected one and, if not, panics again, 
> thus behaving like any other unexpected problem.
>
> See encoding/gob/error.go for an example.
>
> More generally, recover is excellent for isolation of errors in 
> multi-client servers.
>
> Even more generally, blanket statements about what to do or not do with 
> the features of a programming language are too often taken as strict rules 
> rather than thoughtful guidelines. "Don't use panic or recover" is an 
> example. Panic and recover are the perfect tools for some problem and 
> prohibiting them outright eliminates some powerful designs.
>
> -rob
>

Rob, you just described panic as an generic exception mechanism.
Then why Go has no convenient exceptions?

And what about unrecoverable panic? C-style `assert`?
`net/http` recovers from all panics currently, and it is clear design flaw.
There should be distinction between "safe to recover" errors/panics and
"have to stop execution" panics/asserts.
 

>
> On Mon, Apr 24, 2017 at 5:40 AM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com > wrote:
>
>> My 2¢:
>> 1. panic if an API is clearly used wrongly. If a dev chose to not read 
>> the docs for this one function and ignore how it's supposed to be called, 
>> then what else have they not read the docs of? If you can detect that a 
>> program is incorrect, failing loudly seems the right thing to do
>> 2. Do not panic, if an API is used correctly; this includes failing 
>> syscalls that you'd expect to be correct if the API is correctly - your 
>> expectations might be wrong. Return an error on non-code related problems.
>> 3. Don't recover, pretty much universally. Even using it as a 
>> control-flow mechanism seems broken to me; it would hide actual programming 
>> errors that *should* crash
>> 4. If you are using a library that panics and you dislike that, I see two 
>> possible root-causes; a) you are using a library that badly coded 
>> (according to 2) or b) your program is buggy. In either case, the correct 
>> solution doesn't seem to paper over either bug, but to complain loudly so 
>> it gets fixed.
>> 5. Be prepared for your stuff crashing, from a dev-induced panic or a 
>> runtime-induced panic.
>>
>> And as a preventative measure: I say this as a person who was oncall 
>> while a large service, written in a memory safe language, crashed globally 
>> and took our service out. I know it's hard to be prepared for these things 
>> and to recover from them, but I *still* believe that crashing is the 
>> right thing to do. You can not prevent crashes, even globally synchronized 
>> ones, to happen. Because programmers are just humans and humans are 
>> fallible and stuff happens. You need to be prepared to deal with human 
>> failures.
>>
>> On Mon, Apr 24, 2017 at 2:24 PM, Sokolov Yura > > wrote:
>>
>>>
>>> > Notice that real unrecoverable errors are not subject to 
>>> defer/recover() at all.
>>>
>>> If so, then how should I raise unrecoverable error, if I really know 
>>> that it is unrecoverable?

 Something like C style assert(): "guy, something goes completely wrong, 
>>> and it is
>>> much better to stop functioning than corrupt your data further" 
>>>
>>> > It's sometimes a perfectly valid and quite reasonable approach to 
>>> defer a recover() in an API function and panic(forWhateverReason) somewhere 
>>> down the call chain.
>>> > A recursive descent parser may get much simpler and easier to code, 
>>> for example.
>>>
>>> I don't agree. I call it "abusing". In absence of other comfortable 
>>> ways, panic is abused to unwind stack fast (upto recover).
>>> I could be mistaken.
>>>
>>> -- 
>>> 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.
>>>
>>
>> -- 
>> 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.
>>
>
>

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

Re: [go-nuts] Recover considered harmful

['Axel Wagner' via golang-nuts]

True, I genuinely missed that possibility (I always forget that panic is
perfectly well-behaved when re-panicing).

On Mon, Apr 24, 2017 at 3:09 PM, Rob Pike  wrote:

> Your point 3 misses an important practical detail. Packages that use
> recover internally call panic with an identifiable type and the recover
> code checks whether the type is the expected one and, if not, panics again,
> thus behaving like any other unexpected problem.
>
> See encoding/gob/error.go for an example.
>
> More generally, recover is excellent for isolation of errors in
> multi-client servers.
>
> Even more generally, blanket statements about what to do or not do with
> the features of a programming language are too often taken as strict rules
> rather than thoughtful guidelines. "Don't use panic or recover" is an
> example. Panic and recover are the perfect tools for some problem and
> prohibiting them outright eliminates some powerful designs.
>
> -rob
>
>
> On Mon, Apr 24, 2017 at 5:40 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> My 2¢:
>> 1. panic if an API is clearly used wrongly. If a dev chose to not read
>> the docs for this one function and ignore how it's supposed to be called,
>> then what else have they not read the docs of? If you can detect that a
>> program is incorrect, failing loudly seems the right thing to do
>> 2. Do not panic, if an API is used correctly; this includes failing
>> syscalls that you'd expect to be correct if the API is correctly - your
>> expectations might be wrong. Return an error on non-code related problems.
>> 3. Don't recover, pretty much universally. Even using it as a
>> control-flow mechanism seems broken to me; it would hide actual programming
>> errors that *should* crash
>> 4. If you are using a library that panics and you dislike that, I see two
>> possible root-causes; a) you are using a library that badly coded
>> (according to 2) or b) your program is buggy. In either case, the correct
>> solution doesn't seem to paper over either bug, but to complain loudly so
>> it gets fixed.
>> 5. Be prepared for your stuff crashing, from a dev-induced panic or a
>> runtime-induced panic.
>>
>> And as a preventative measure: I say this as a person who was oncall
>> while a large service, written in a memory safe language, crashed globally
>> and took our service out. I know it's hard to be prepared for these things
>> and to recover from them, but I *still* believe that crashing is the
>> right thing to do. You can not prevent crashes, even globally synchronized
>> ones, to happen. Because programmers are just humans and humans are
>> fallible and stuff happens. You need to be prepared to deal with human
>> failures.
>>
>> On Mon, Apr 24, 2017 at 2:24 PM, Sokolov Yura 
>> wrote:
>>
>>>
>>> > Notice that real unrecoverable errors are not subject to
>>> defer/recover() at all.
>>>
>>> If so, then how should I raise unrecoverable error, if I really know
>>> that it is unrecoverable?

 Something like C style assert(): "guy, something goes completely wrong,
>>> and it is
>>> much better to stop functioning than corrupt your data further"
>>>
>>> > It's sometimes a perfectly valid and quite reasonable approach to
>>> defer a recover() in an API function and panic(forWhateverReason) somewhere
>>> down the call chain.
>>> > A recursive descent parser may get much simpler and easier to code,
>>> for example.
>>>
>>> I don't agree. I call it "abusing". In absence of other comfortable
>>> ways, panic is abused to unwind stack fast (upto recover).
>>> I could be mistaken.
>>>
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [go-nuts] Recover considered harmful

[Rob Pike]

Your point 3 misses an important practical detail. Packages that use
recover internally call panic with an identifiable type and the recover
code checks whether the type is the expected one and, if not, panics again,
thus behaving like any other unexpected problem.

See encoding/gob/error.go for an example.

More generally, recover is excellent for isolation of errors in
multi-client servers.

Even more generally, blanket statements about what to do or not do with the
features of a programming language are too often taken as strict rules
rather than thoughtful guidelines. "Don't use panic or recover" is an
example. Panic and recover are the perfect tools for some problem and
prohibiting them outright eliminates some powerful designs.

-rob


On Mon, Apr 24, 2017 at 5:40 AM, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> My 2¢:
> 1. panic if an API is clearly used wrongly. If a dev chose to not read the
> docs for this one function and ignore how it's supposed to be called, then
> what else have they not read the docs of? If you can detect that a program
> is incorrect, failing loudly seems the right thing to do
> 2. Do not panic, if an API is used correctly; this includes failing
> syscalls that you'd expect to be correct if the API is correctly - your
> expectations might be wrong. Return an error on non-code related problems.
> 3. Don't recover, pretty much universally. Even using it as a control-flow
> mechanism seems broken to me; it would hide actual programming errors that
> *should* crash
> 4. If you are using a library that panics and you dislike that, I see two
> possible root-causes; a) you are using a library that badly coded
> (according to 2) or b) your program is buggy. In either case, the correct
> solution doesn't seem to paper over either bug, but to complain loudly so
> it gets fixed.
> 5. Be prepared for your stuff crashing, from a dev-induced panic or a
> runtime-induced panic.
>
> And as a preventative measure: I say this as a person who was oncall while
> a large service, written in a memory safe language, crashed globally and
> took our service out. I know it's hard to be prepared for these things and
> to recover from them, but I *still* believe that crashing is the right
> thing to do. You can not prevent crashes, even globally synchronized ones,
> to happen. Because programmers are just humans and humans are fallible and
> stuff happens. You need to be prepared to deal with human failures.
>
> On Mon, Apr 24, 2017 at 2:24 PM, Sokolov Yura 
> wrote:
>
>>
>> > Notice that real unrecoverable errors are not subject to
>> defer/recover() at all.
>>
>> If so, then how should I raise unrecoverable error, if I really know that
>> it is unrecoverable?
>>>
>>> Something like C style assert(): "guy, something goes completely wrong,
>> and it is
>> much better to stop functioning than corrupt your data further"
>>
>> > It's sometimes a perfectly valid and quite reasonable approach to defer
>> a recover() in an API function and panic(forWhateverReason) somewhere down
>> the call chain.
>> > A recursive descent parser may get much simpler and easier to code, for
>> example.
>>
>> I don't agree. I call it "abusing". In absence of other comfortable ways,
>> panic is abused to unwind stack fast (upto recover).
>> I could be mistaken.
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Recover considered harmful

[Sokolov Yura]

Fully agree with Axel Wagner.

- I may make mistake in my library, ie my code found that some invariant is 
broken.
  If library is a "shared state manager" (for example, in-memory db, or on 
disk db),
  then I clearly have to stop whole process instead of continue to corrupt 
data
  (same as Axel's example)
- I may give to programmer "low level" interface with access to internals 
(for performance).
  If programmer uses it in a wrong way, and my library's code detected that 
(but too late
  to return error, probably, by founding broken invariants), then it is 
clearly better to stop
  functioning.

In both cases I need a way stop process, and `panic` is a most clear way to 
do that...
if no one calls `recover`.

понедельник, 24 апреля 2017 г., 15:40:36 UTC+3 пользователь Kevin Conway 
написал:
>
> > If so, then how should I raise unrecoverable error, if I really know 
> that it is unrecoverable?
>
> I don't believe you can ever know whether an error in your library is 
> truly unrecoverable by the process executing the code. As a someone writing 
> and operating the process, I'd expect a library to provide me all the tools 
> necessary to make the right decision (such as custom error references or 
> types) but never to make the decision for me.
>
> I've yet to find a panic that would not be better served as a returned 
> error.
>
> On Mon, Apr 24, 2017 at 7:24 AM Sokolov Yura  > wrote:
>
>>
>> > Notice that real unrecoverable errors are not subject to 
>> defer/recover() at all.
>>
>> If so, then how should I raise unrecoverable error, if I really know that 
>> it is unrecoverable?
>>>
>>> Something like C style assert(): "guy, something goes completely wrong, 
>> and it is
>> much better to stop functioning than corrupt your data further" 
>>
>> > It's sometimes a perfectly valid and quite reasonable approach to defer 
>> a recover() in an API function and panic(forWhateverReason) somewhere down 
>> the call chain.
>> > A recursive descent parser may get much simpler and easier to code, for 
>> example.
>>
>> I don't agree. I call it "abusing". In absence of other comfortable ways, 
>> panic is abused to unwind stack fast (upto recover).
>> I could be mistaken.
>>
>

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

Re: [go-nuts] Recover considered harmful

['Axel Wagner' via golang-nuts]

My 2¢:
1. panic if an API is clearly used wrongly. If a dev chose to not read the
docs for this one function and ignore how it's supposed to be called, then
what else have they not read the docs of? If you can detect that a program
is incorrect, failing loudly seems the right thing to do
2. Do not panic, if an API is used correctly; this includes failing
syscalls that you'd expect to be correct if the API is correctly - your
expectations might be wrong. Return an error on non-code related problems.
3. Don't recover, pretty much universally. Even using it as a control-flow
mechanism seems broken to me; it would hide actual programming errors that
*should* crash
4. If you are using a library that panics and you dislike that, I see two
possible root-causes; a) you are using a library that badly coded
(according to 2) or b) your program is buggy. In either case, the correct
solution doesn't seem to paper over either bug, but to complain loudly so
it gets fixed.
5. Be prepared for your stuff crashing, from a dev-induced panic or a
runtime-induced panic.

And as a preventative measure: I say this as a person who was oncall while
a large service, written in a memory safe language, crashed globally and
took our service out. I know it's hard to be prepared for these things and
to recover from them, but I *still* believe that crashing is the right
thing to do. You can not prevent crashes, even globally synchronized ones,
to happen. Because programmers are just humans and humans are fallible and
stuff happens. You need to be prepared to deal with human failures.

On Mon, Apr 24, 2017 at 2:24 PM, Sokolov Yura 
wrote:

>
> > Notice that real unrecoverable errors are not subject to defer/recover()
> at all.
>
> If so, then how should I raise unrecoverable error, if I really know that
> it is unrecoverable?
>>
>> Something like C style assert(): "guy, something goes completely wrong,
> and it is
> much better to stop functioning than corrupt your data further"
>
> > It's sometimes a perfectly valid and quite reasonable approach to defer
> a recover() in an API function and panic(forWhateverReason) somewhere down
> the call chain.
> > A recursive descent parser may get much simpler and easier to code, for
> example.
>
> I don't agree. I call it "abusing". In absence of other comfortable ways,
> panic is abused to unwind stack fast (upto recover).
> I could be mistaken.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Recover considered harmful

[Ian Davis]

On Mon, 24 Apr 2017, at 12:06 PM, Kevin Conway wrote:
> I'd say that recover() is not a problem but, instead, a symptom of
> panic() being available to developers. I'd flip the title and say
> panic() should be considered harmful. To quote from
> https://blog.golang.org/defer-panic-and-recover :> > The process continues up 
> the stack until all functions in the
> > current goroutine have returned, at which point the program crashes

The standard library uses panic in a couple of places to exit from
deeply nested function calls, e.g.
https://github.com/golang/go/blob/master/src/encoding/json/decode.go#L167
A while ago I wrote this usage up as a recipe:
https://github.com/iand/gocookbook/blob/master/recipes/panic-for-deep-errors.md
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Kevin Conway]

I'd say that recover() is not a problem but, instead, a symptom of panic()
being available to developers. I'd flip the title and say panic() should be
considered harmful. To quote from
https://blog.golang.org/defer-panic-and-recover :
> The process continues up the stack until all functions in the current
goroutine have returned, at which point the program crashes

Any code that invokes panic is very clearly stating that an error has
occurred that is completely unrecoverable and the _only_ choice of action
that could possibly be taken is to end the program. The recover() builtin
must exist to account for the fact that _all_ uses of panic in user space
are, in fact, recoverable errors.

As someone developing in go, it is infuriating when external libraries
(whether 3rd party or std lib) make decisions about when my program should
stop. Code related bugs, such as nil pointer dereferences or invalid
interface conversions, should result in a process failure just like a
segfault in any other runtime. However, some library using the same process
ending mechanism to let me know that it doesn't like the format of my
string input is unacceptable.

On Mon, Apr 24, 2017 at 5:41 AM Christian von Pentz 
wrote:

> On 04/24/2017 11:02 AM, Sokolov Yura wrote:
> > I mean: panic usually means programmer error, so if it happens, then
> > program behaves incorrectly, and there is always a chance of serious
> > state corruption. So, is there reason to recover at all?
>
> I encountered many cases of panics when using external tools/libraries
> which were completely "fine" to recover from. magicmime was such a
> package that had a few "hiccups" when used in a multi-threaded
> environment mostly due to the underlying libmagic. That being said, very
> easy and convenient to recover from, so yeah, I would say recover is a
> perfectly valid strategy sometimes.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Recover considered harmful

[Christian von Pentz]

On 04/24/2017 11:02 AM, Sokolov Yura wrote:
> I mean: panic usually means programmer error, so if it happens, then
> program behaves incorrectly, and there is always a chance of serious
> state corruption. So, is there reason to recover at all?

I encountered many cases of panics when using external tools/libraries
which were completely "fine" to recover from. magicmime was such a
package that had a few "hiccups" when used in a multi-threaded
environment mostly due to the underlying libmagic. That being said, very
easy and convenient to recover from, so yeah, I would say recover is a
perfectly valid strategy sometimes.

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

[go-nuts] Re: Turning unicode code string to rune

[gary . willoughby]

See: https://golang.org/pkg/unicode/utf8/#DecodeRuneInString

On Saturday, 22 April 2017 19:51:09 UTC+1, Tong Sun wrote:
>
> Hi, 
>
> Given a unicode code string, be it "4e16", or "0x4e16", or "u4e16", how to 
> turn it into a single char rune?
>
> You can finish the code at https://play.golang.org/p/AFIEz3eJVz
>
> Thanks. 
>
>

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

[go-nuts] Recover considered harmful

[Sokolov Yura]

Good day, people.

Title is a bit controversial :-)

I want to ask:
- how useful `recover` for you?
- Don't you think it is a bit "dangerous"?

I mean: panic usually means programmer error, so if it happens, then
program behaves incorrectly, and there is always a chance of serious
state corruption. So, is there reason to recover at all?

Also, presence of `recover` complicates implementation of `defer`.
I believe, it could be optimized much harder in absence of `recover`
(i.e. if program always exits on panic).

I could be mistaken.

Yura.

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

Re: [go-nuts] What's the recommended way to determine if a type.Type is exported?

[Kevin Conway]

Alternatively, if you are walking an AST and only interested in the
exported names then you can use
https://golang.org/pkg/go/ast/#PackageExports . It will filter your tree to
only elements that are exported before you begin traversal.

As to your specific case of determining if a type used in a method
signature is exported, I'd ask: Does it matter if the source package is the
same one where the method is defined or is it any non-builtin, exported
types used in the signature?

I believe the case of "exported name used in a method within the same
package" can be determined by iterating of the 'Params.List' attribute of
the ast.FuncType and looking for elements of the slice that are of type
'*ast.Ident' and checking the corresponding 'IsExported' method call
results. For complete coverage, you'd also need to check for
*ast.ArrayType, *ast.ChanType, *ast.MapType, *ast.Ellipsis (for uses of the
type as a variadic), *ast.FuncType (and its corresponding arguments and
return types), and *ast.StarExpr (for uses of the type as a pointer).

The case of "any non-builtin, exported type from any package" would use the
previous logic but also add in checking for elements of 'Params.List' that
are of type '*ast.SelectorExpr'. While I'm sure there is a case where this
is not true, the elements of type *ast.SelectorExpr in the parameter list
of an *ast.FuncType are usually references to a type exported by another
package (think "http.Handler"). The 'X' attribute can be converted to
*ast.Ident for the source package name and the 'Sel' attribute contains the
name of the referenced type. Note that the package name might actually be a
local alias when the file imports with ' import myname "net/http" '.

https://play.golang.org/p/yNKAQe_YSV

PS the implementation of 'IsExported' used by everything checks the
capitalisation of the first letter to make its choice:
https://golang.org/src/go/ast/ast.go?s=16357:16390#L516

On Mon, Apr 24, 2017 at 2:49 AM Tejas Manohar  wrote:

> Agreed! I ended up casting to types.NamedType (or pointer then elem())...
> I'll try your method too!
> On Sun, Apr 23, 2017 at 11:11 PM Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> I'd say, probably type-asserting to a *types.TypeName
>>  and then use Exported()
>>  (the code of which
>> also leads to ast.IsExported 
>> ).
>>
>> Side-note: You probably shouldn't rely on parsing the output of String()
>> of any value, just as you shouldn't rely on parsing the output of
>> error.Error().
>>
>> On Mon, Apr 24, 2017 at 7:06 AM,  wrote:
>>
>>> https://golang.org/pkg/go/types/#Type
>>>
>>> Is there a helper function to determine whether a *types.Type* is
>>> exported? It seems like I can do some string parsing like
>>>
>>> t := something.Type()
>>> parts := strings.Split(t.String(), ".") // go/ast.Node => ["go/ast",
>>> "Node"]
>>> ident := parts[len(parts)-1] // "Node"
>>> exported := strings.IsUpper(ident[0])
>>>
>>> but I imagine there's a simpler, more robust way. The end goal is to
>>> find out whether a type of a method argument is exported-- e.g.
>>> namedType := obj.Type().(*types.Named)
>>> method := namedType.Method(0)
>>> signature := method.Type().(*types.Signature)
>>> signature.Params().At(0).Type() // is this exported?
>>>
>>> And, for some context, all of this is from walking go/ast
>>>
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>
> Best regards,
>
> Tejas Manohar
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] What's the recommended way to determine if a type.Type is exported?

[Tejas Manohar]

Agreed! I ended up casting to types.NamedType (or pointer then elem())...
I'll try your method too!
On Sun, Apr 23, 2017 at 11:11 PM Axel Wagner 
wrote:

> I'd say, probably type-asserting to a *types.TypeName
>  and then use Exported()
>  (the code of which
> also leads to ast.IsExported ).
>
> Side-note: You probably shouldn't rely on parsing the output of String()
> of any value, just as you shouldn't rely on parsing the output of
> error.Error().
>
> On Mon, Apr 24, 2017 at 7:06 AM,  wrote:
>
>> https://golang.org/pkg/go/types/#Type
>>
>> Is there a helper function to determine whether a *types.Type* is
>> exported? It seems like I can do some string parsing like
>>
>> t := something.Type()
>> parts := strings.Split(t.String(), ".") // go/ast.Node => ["go/ast",
>> "Node"]
>> ident := parts[len(parts)-1] // "Node"
>> exported := strings.IsUpper(ident[0])
>>
>> but I imagine there's a simpler, more robust way. The end goal is to find
>> out whether a type of a method argument is exported-- e.g.
>> namedType := obj.Type().(*types.Named)
>> method := namedType.Method(0)
>> signature := method.Type().(*types.Signature)
>> signature.Params().At(0).Type() // is this exported?
>>
>> And, for some context, all of this is from walking go/ast
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --

Best regards,

Tejas Manohar

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

Re: [go-nuts] Re: Semicolons in Go

[roger peppe]

On 22 April 2017 at 02:59, Matt Harden  wrote:
> a = ( b
>   + c
>   + d
>   * e
>   )

That doesn't work:
https://play.golang.org/p/z6HFDK3XRT

The usual Go idiom is to leave the operators at the end of the lines:

a = b +
c +
d*
e

Note that extra-level of identation at the end - the original
expression is misleading - at a casual glance, you might
think that b+c+d is multiplied by e, but precedence rules means that
it doesn't.

a = b +
c +
d +
e

It's still almost as easy to add or remove a single line - with the exception
of the first and last lines.

It's kind of a pity that Go produces this an extra level of indent on
this though:

  a =
b +
c +
d +
e

It would be nice if it produced:

a =
b +
c +
d +
e

There's probably a good reason why it doesn't though, and
you can always work around it:

a = 0 +
b +
c +
d +
e

  cheers,
rog.

>
> On Thu, Apr 20, 2017 at 1:24 PM John McKown 
> wrote:
>>
>> On Thu, Apr 20, 2017 at 12:20 PM, Michael Jones 
>> wrote:
>>>
>>>
>>> On Thu, Apr 20, 2017 at 8:27 AM,  wrote:

 If I can't format my programs the way I want, and I much prefer putting
 operators at the beginning of continuation lines for reasons mentioned on
 this page, and "Perl Best Practices", I simply won't use the language - at
 least not without implementing a pre-processor. Automatic semicolon
 inserting is the worst thing about JavaScript. Please make it optional in
 some way.
>>>
>>>
>>> The die has been cast. It usually takes two weeks for personal preference
>>> here to be forgotten. Hope you give it a good chance, as you'll have many
>>> positive benefits.
>>>
>>
>> I understand that it is oft-time better to approach a new language on its
>> own merits. Just like with a "human" language. You'll never learn language
>> ABC if you keep thinking in language DEF. I.e. think in DEF then translate
>> to ABC. You'll always end up doing something wrong because each language has
>> a different "mind set" or "world view".
>>
>> Having said the above, this "auto insertion" of a semi-colon is a bother
>> to me too. Mainly because I like to write C code something like:
>>
>> a = b
>>  + c
>>  + d
>>  * e
>>  ;
>>
>> So that I can easily insert or remove a single line. This may well be due
>> to my advanced age (64!) and the fact that my original language was FORTRAN
>> which was punched onto 80 column card stock. The above did waste cards, but
>> made program changes very easy. In today's world of "full screen" editors
>> which can reformat and even refactor code upon demand, it is a relic of a
>> bygone era.
>>
>>
>>
>> --
>> "Irrigation of the land with seawater desalinated by fusion power is
>> ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
>>
>> Maranatha! <><
>> John McKown
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

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