On Fri, Nov 8, 2019 at 1:38 PM André Eriksson wrote:
>
> On Friday, November 8, 2019 at 10:27:32 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Fri, Nov 8, 2019 at 11:40 AM André Eriksson wrote:
>> >
>> > On Friday, November 8, 2019 at 7:16:42 PM UTC+1, Ian Lance Taylor wrote:
>> >>
>> >> On Fri, Nov
On Friday, November 8, 2019 at 10:27:32 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Nov 8, 2019 at 11:40 AM André Eriksson > wrote:
> >
> > On Friday, November 8, 2019 at 7:16:42 PM UTC+1, Ian Lance Taylor wrote:
> >>
> >> On Fri, Nov 8, 2019 at 10:06 AM André Eriksson
> wrote:
> >> >
>
On Fri, Nov 8, 2019 at 11:40 AM André Eriksson wrote:
>
> On Friday, November 8, 2019 at 7:16:42 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Fri, Nov 8, 2019 at 10:06 AM André Eriksson wrote:
>> >
>> > Interesting. Do you have a reference to where that happens?
>>
>> The method (*Package).rewriteC
On Friday, November 8, 2019 at 7:16:42 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Nov 8, 2019 at 10:06 AM André Eriksson > wrote:
> >
> > Interesting. Do you have a reference to where that happens?
>
> The method (*Package).rewriteCall in cmd/cgo/gcc.go. But more useful
> might be to exp
There is Massimiliano Ghilardi’s gomacro Github.com/cosmos72/gomacro
Note that in case of untyped constants, there is no need to use temps so your
idea can still work.
>> On Nov 8, 2019, at 9:30 AM, Michael Jones wrote:
>
> Alas. Thus the need for and glory of macros, hold/uneval, and bac
On Fri, Nov 8, 2019 at 10:06 AM André Eriksson wrote:
>
> Interesting. Do you have a reference to where that happens?
The method (*Package).rewriteCall in cmd/cgo/gcc.go. But more useful
might be to experiment with some cgo code and build with `go build
-work` and look in the $WORK directory to
Interesting. Do you have a reference to where that happens?
If i understand you correctly, however, it doesn't appear to solve the case
where the called function fn lives in a different package, and takes an
argument which is a private type. That is:
-- a/a.go --
package a
type myString string
On Fri, Nov 8, 2019 at 9:08 AM André Eriksson wrote:
>
> That works in simple cases, but does not work when the expression is an
> untyped constant, like 1 or nil. In the case of 1 the variable will get a
> concrete type of int, while fn may accept a float32, or even a private type
> that canno
I tried to explain why that does not work in the general case.
Specifically, that coerces expr to take a concrete type. The constant 1
would become int, while fn might take a float32 or even a private type that
cannot be named in the package being rewritten. It would similarly fail if
expr is u
Alas. Thus the need for and glory of macros, hold/uneval, and backtick in
LISP. (Problems solved in the 1970s)
On Fri, Nov 8, 2019 at 9:08 AM André Eriksson wrote:
> That works in simple cases, but does not work when the expression is an
> untyped constant, like 1 or nil. In the case of 1 the va
That works in simple cases, but does not work when the expression is an
untyped constant, like 1 or nil. In the case of 1 the variable will get a
concrete type of int, while fn may accept a float32, or even a private type
that cannot be named in the current package.
On Friday, November 8, 2019
If expr was evaluable in the original code then why not rewrite in place
after assigning temporaries?
go fn(e1,e2)
{
t1,t2 := e1,e2
go func() {
defer instrument()
fn(t1,t2)
}
On Fri, Nov 8, 2019 at 8:38 AM André Eriksson wrote:
> I am working on a type of Go preprocessor that rewrites sou
I am working on a type of Go preprocessor that rewrites source code to add
additional instrumentation to certain types of statements.
One such statement is the go statement. I would like to instrument the
newly created goroutine, injecting some instrumentation code at the start
and finish of th
13 matches
Mail list logo