Re: Left & Right Double Quote Marks?

On Jan 1, 12:40 am, darenw <darenscotwil...@...> wrote:
> String literals in Go use the old standard ASCII 0x22 for double
> quotes, as in fmt.Print("hey!").  It has always bothered me that, in
> all languages I've known since 1970s BASIC onward, the exact same
> character is used for the start and end of string literals.
So the observed pattern probably have some reason and it may be not
only rigidity of the language designers.
> I wonder if it could work to use the directional quote marks defined
> in UTF
> 0x201C and 0x201D?   Of course this is easy to tap into an old "hello
> world" source.  The compiler tells me "invalid identifier character
> 0x201c".
The compiler obeys the specs. No surprise it mumbles about invalid
stuff if it's out of the specs.
> Does this idea make sense?
IMO not.
> What are the pros and cons of this?
I'm not aware of pros, but the cons is entering daily hundreds of non-
ASCII Unicode codepoints using a keyboard which doesn't have them
available as a simple shift-key stroke, but only as "magic" sequences
of (a possibly lot) more keystrokes. The later is a bit harder to
enter without looking at the keyboard.
> Are
> all programmers in all languages doomed to be forever confined to old
> ASCII characters?
They're IMO not doomed. Programmers entering daily few thousands
characters (or more) of source code do understandably like them to be
found ready made on a common PC keyboard. Otherwise they will slow
down significantly.
> Who do I bribe to add this feature?

Re: avoiding "math." clutter in expressions

You could also make references to the original functions:

import "math"

var (
    sin = math.Sin
    sqrt = math.Sqrt
    // etc
)

This has the advantage over 'import . "math"' in that it effectively
imports into the local namespace only the functions you need.

-Daniel

On Dec 31, 4:23 pm, darenw <darenscotwil...@...> wrote:
> I'm writing number crunching code, with many lines with expressions
> like
>
> x := math.Sqrt(a)*math.Exp(z)*math.Sin(math.PI*F*t)/math.Sqrt(1+z)
>
> Now some programmers are really nuts gung-ho for having "math." or
> whatever package name in front of every type, function or whatever is
> from that package, but as a physicist I find all the repeating "math."
> prefixes redundant and pointless.    These prefixes are eye clutter,
> and just add viscosity to my reading and thinking process when
> studying and modifying code.   It's not as if I'm going to confuse
> math.Sqrt with someotherpackage.Sqrt.   Maybe Sin() would be ambiguous
> if I were writing church software <g>.
>

Re: Performance problem when reading a large text file

Re: Question about signals

On 29 December 2010 23:00, creack <charmes.guillaume@...> wrote:
> Hello,
>
> I would like to know if it is possible to switch on/off the signal
> handling?
>
> I would like to turn it off on certain part of my program but I need
> it everywhere else.

How can you turn off signals for part of a program? Signals are sent
to a process, the process handles the signal. The os/signal package
gives you the ability to handle those signals manually, or you can
accept the way they're handled by default.

> For now, I am using cgo with call to signal(SIG_IGN) and
> signal(SIG_DEF) but I would like to know if there is a better way.
>
> I read a post about the handling of SIGQUIT which is not handle in
> purpose, but is there anyway to ignore it in Go?

Not at present, no. Out of interest, why do you need to handle it?

Andrew

Re: Question about signals

Re: cgo crash after update

Make sure you 'gomake clean' (and possibly 'gomake nuke') in your
external projects. If there are older object files lying around, they
may hold invalid references to parts of the Go core that have been
changed.

Andrew

On 31 December 2010 22:09, gnu.bash <aotto1968@...> wrote:
> Hi,
>
> after a while I start to update an already working "go" project.
> this project is a "go" wrapper for a "C" library.
> First I start to update "go" itself with "hg pull ...." and start to
> recompile the software.
> this end up with the core-dump from the bottom.
> well -> I switch my status of the "go" project to "experimental"
>
> mfg, Andreas Otto (aotto1968)
>
>> make
> CGOPKGPATH= cgo -- -I . -I /home/dev1usr/Project/NHI1/theLink/
> libmsgque -DMQ_IGNORE_EXTERN MqS.go MqSException.go MqBufferS.go
> MqBinary.go send.go read.go link.go config.go service.go slave.go
> factory.go
> panic: runtime error: invalid memory address or nil pointer
> dereference
>
> panic PC=0x2ab53ab5b5e0
> runtime.panic+0xa7 /home/dev1usr/src/go/src/pkg/runtime/proc.c:1032
>        runtime.panic(0x4de0d8, 0x2ab53b27e050)
> runtime.panicstring+0x69 /home/dev1usr/src/go/src/pkg/runtime/
> runtime.c:83
>        runtime.panicstring(0x65a95f, 0x38)
> runtime.sigpanic+0x144 /home/dev1usr/src/go/src/pkg/runtime/linux/
> thread.c:286
>        runtime.sigpanic()
> main.*typeConv·Type+0x175 /home/dev1usr/src/go/src/cmd/cgo/gcc.go:660
>        main.*typeConv·Type(0x2ab53ab587e0, 0x0, 0x0, 0x4, 0x0, ...)
> main.*Package·loadDWARF+0x8ab /home/dev1usr/src/go/src/cmd/cgo/gcc.go:
> 373
>        main.*Package·loadDWARF(0x2ab53ab82ea0, 0x2ab53ab87e40,
> 0x2ab53b1aee70, 0x1600000013, 0x100000001, ...)
> main.*Package·Translate+0x131 /home/dev1usr/src/go/src/cmd/cgo/gcc.go:
> 71
>        main.*Package·Translate(0x2ab53ab82ea0, 0x2ab53ab87e40,
> 0x2ab500000006, 0x100000001)
> main.main+0xd92 /home/dev1usr/src/go/src/cmd/cgo/main.go:198
>        main.main()
> runtime.mainstart+0xf /home/dev1usr/src/go/src/pkg/runtime/amd64/asm.s:
> 77
>        runtime.mainstart()
> runtime.goexit /home/dev1usr/src/go/src/pkg/runtime/proc.c:148
>        runtime.goexit()
> make: *** [_cgo_defun.c] Fehler 2
>

Re: Idea for exceptions in Go

On 31 December 2010 12:35, Nigel Tao <nigel.tao.gnome@...> wrote:
> On 31 December 2010 05:04, WCverfrisser <wcverfrisser@...> wrote:
>> Ok, so error handling is done now by return values right? As I
>> understood, the reason for that was because not every exception has to
>> stop the code, and try-catch-finally blocks are bulky?
>
> http://golang.org/doc/go_faq.html#exceptions says "We believe that
> coupling exceptions to a control structure, as in the
> try-catch-finally idiom, results in convoluted code. It also tends to
> encourage programmers to label too many ordinary errors, such as
> failing to open a file, as exceptional."
>
> For more on Go's philosophy re panics versus exceptions, there is a
> long discussion thread titled "Proposal for an exception-like
> mechanism" that introduced defer / panic / recover:
> https://groups.google.com/group/golang-nuts/browse_thread/thread/1ce5cd050bb973e4?pli=1
>
> For example, Rob Pike's opening paragraph in full is: "This proposal
> differs from the usual model of exceptions as a control structure, but
> that is a deliberate decision. We don't want to encourage the
> conflation of errors and exceptions that occur in languages such as
> Java."
>
>
>> Then, there is the fact that you had to create a new class for every
>> exception that could occur in a function, that is the bad thing about
>> traditional exceptions, so I think if Go were to implement some kind
>> of exceptions, the developer shouldn't have to do something in order
>> to use a certain exception.
>
> In Go you don't need a separate type for each possible exception. For
> example, to return an os.Error based on a string, you can just do:
>
> return os.NewError("epic fail")

To expand on this a little: Go's error values are just that, /values/,
not just codes. The convention is for errors to be returned as a type
of os.Error:

type Error interface {
    String() string
}

That means that /any/ type that implements a String method can be used
as an os.Error value. With this in mind, the scope for what you can do
with this is broad.

Andrew

Re: avoiding "math." clutter in expressions

Ack! I forgot that in my twerpy little test programs I was also toying
around with different data types.  That's an irrelevant side issue to
my question, but a good point nonetheless!

On Dec 31, 6:23 pm, darenw <darenscotwil...@...> wrote:
> I'm writing number crunching code, with many lines with expressions
> like
>
> x := math.Sqrt(a)*math.Exp(z)*math.Sin(math.PI*F*t)/math.Sqrt(1+z)
>
> Now some programmers are really nuts gung-ho for having "math." or
> whatever package name in front of every type, function or whatever is
> from that package, but as a physicist I find all the repeating "math."
> prefixes redundant and pointless.    These prefixes are eye clutter,
> and just add viscosity to my reading and thinking process when
> studying and modifying code.   It's not as if I'm going to confuse
> math.Sqrt with someotherpackage.Sqrt.   Maybe Sin() would be ambiguous
> if I were writing church software <g>.
>
> What is the best, officially recommended way to avoid those
> prefixes?
>
> For the time being, I'm doing this:
>
> func sqrt(x float) float   {
>         return float( math.Sqrt( float64(x) ))
>
> }
>
> and similar for exp(), sin(), etc. allowing me to write sweetly
> readable expressions like
>
> x:= sqrt(a)*exp(z)*sin(π*F*t) /sqrt(1+z)
>
> (Yay for UTF8 allowing greek letters for variable names!)
>
> BTW, as a physicist and digital artist using plenty of advanced math,
> I like Go for its fresh take on advanced features, go routines, and so
> on, knowing that parallel processing and multicore are important to
> the near future of scientific software.  I'm currently being paid to
> fix a nasty behemoth C++ app that, I hypothesize, could be so much
> more readable, maintainable and reliable if it were written in Go.  Go
> has compile to opcode appeal, no massive runtime, and is just pretty
> marvelous in a variety of ways.  But we physicists demand number-
> crunch-friendly features too!

Re: avoiding "math." clutter in expressions

Interesting.  Looks tedious, though.  Could the compiler be made to
hallucinate that stuff?

On Dec 31, 7:21 pm, Ostsol <ost...@...> wrote:
> You could also make references to the original functions:
>
> import "math"
>
> var (
>     sin = math.Sin
>     sqrt = math.Sqrt
>     // etc
> )
>
> This has the advantage over 'import . "math"' in that it effectively
> imports into the local namespace only the functions you need.
>
> -Daniel
>
> On Dec 31, 4:23 pm, darenw <darenscotwil...@...> wrote:
>
> > I'm writing number crunching code, with many lines with expressions
> > like
>
> > x := math.Sqrt(a)*math.Exp(z)*math.Sin(math.PI*F*t)/math.Sqrt(1+z)
>
> > Now some programmers are really nuts gung-ho for having "math." or
> > whatever package name in front of every type, function or whatever is
> > from that package, but as a physicist I find all the repeating "math."
> > prefixes redundant and pointless.    These prefixes are eye clutter,
> > and just add viscosity to my reading and thinking process when
> > studying and modifying code.   It's not as if I'm going to confuse
> > math.Sqrt with someotherpackage.Sqrt.   Maybe Sin() would be ambiguous
> > if I were writing church software <g>.
>
> > What is the best, officially recommended way to avoid those
> > prefixes?
>
> > For the time being, I'm doing this:
>
> > func sqrt(x float) float   {
> >         return float( math.Sqrt( float64(x) ))
>
> > }
>
> > and similar for exp(), sin(), etc. allowing me to write sweetly
> > readable expressions like
>
> > x:= sqrt(a)*exp(z)*sin(π*F*t) /sqrt(1+z)
>
> > (Yay for UTF8 allowing greek letters for variable names!)
>
> > BTW, as a physicist and digital artist using plenty of advanced math,
> > I like Go for its fresh take on advanced features, go routines, and so
> > on, knowing that parallel processing and multicore are important to
> > the near future of scientific software.  I'm currently being paid to
> > fix a nasty behemoth C++ app that, I hypothesize, could be so much
> > more readable, maintainable and reliable if it were written in Go.  Go
> > has compile to opcode appeal, no massive runtime, and is just pretty
> > marvelous in a variety of ways.  But we physicists demand number-
> > crunch-friendly features too!

Re: Left & Right Double Quote Marks?

That thread is a good read.  It does retreat old ground, that we are
now avoiding re-retreading.  These discussions have occured before
with other languages in past years.

We *are* doomed to ASCII only forever!  At least until keyboards with
nice unicode characters built-in easy to use are in widespread use,
and grep & co. are smart enough to identify <- with (arrow character)
automatically... someday...

There is the Fortress language, though, for an aternative take on the
issue of glyphs to use.  It is rather specialized for scientists &
engineers, who routinely are willing to put up with inconveniences for
power,  and probably not going to influence Go or any other current
language with wider ambitions.

On Dec 31, 6:57 pm, Evan Shaw <chicken...@...> wrote:
> On Sat, Jan 1, 2011 at 12:40 PM, darenw <darenscotwil...@...> wrote:
> > Does this idea make sense?  What are the pros and cons of this?  Are
> > all programmers in all languages doomed to be forever confined to old
> > ASCII characters?  Who do I bribe to add this feature?
>
> See this thread for a similar proposal and the long discussion that
> ensued:http://groups.google.com/group/golang-nuts/browse_thread/thread/502a7...
>
> I'd really love to avoid retreading. (My opinion is included somewhere
> in there.)
>
> - Evan