I don't know if there is still interest in this project, but I continue to
be interested. Recently I note that Apple's Swift might reasonably be a
good target.
Consider:
a. swift already provides a repl, with debugger. quite possibly easy access
to existing scientific C/C++ codebase, which Seb
I would like to propose a cloture vote to abrogate the need to entable a
veto to the de facto habeas corpus motion that is de jure blocking progress
on this endeavor.
Or else just get on with it.
-rob
On Sun, Aug 7, 2016 at 4:24 AM, Peter Bourgon wrote:
> Ah! Ha. All good.
>
> On Sat, Aug 6,
Those benchmarks don't iterate over b.N (which will be zero in your example) so
are not going to give reliable results.
--
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 em
Cgo is not in use; thank you for the quick response!
On Saturday, August 6, 2016 at 11:49:22 AM UTC-7, Ian Lance Taylor wrote:
>
> On Sat, Aug 6, 2016 at 10:08 AM, Carl Mastrangelo
> > wrote:
> > TL;DR: Is the uintptr slice returned from runtime.Callers always valid?
> >
> > Reading the docs*
On Sat, Aug 6, 2016 at 10:08 AM, Carl Mastrangelo
wrote:
> TL;DR: Is the uintptr slice returned from runtime.Callers always valid?
>
> Reading the docs* for runtime.Callers says: "Callers fills the slice pc with
> the return program counters of function invocations on the calling
> goroutine's st
Ah! Ha. All good.
On Sat, Aug 6, 2016 at 17:51 'Jessica Frazelle' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Sorry Peter that got stuck in moderation I wrote it before your other
> message
>
> On Saturday, August 6, 2016, Peter Bourgon wrote:
>
>> Again, there is no nomination proce
TL;DR: Is the uintptr slice returned from runtime.Callers always valid?
Reading the docs* for runtime.Callers says: "Callers fills the slice pc
with the return program counters of function invocations on the calling
goroutine's stack. " Does this imply that once the goroutine is gone, or
all
Ah, simple
func main() {
b := &testing.B{}
BenchmarkSqliteLsh128(b)
}
On Saturday, August 6, 2016 at 11:12:56 AM UTC-4, Tong Sun wrote:
>
> I know that golang test/benchmark code are invoked by `go test`, but I'm
> wondering how I can invoke them explicitly in my own main() function?
>
> Th
Hi
I am interested. Pls share me full details.
Regards
Sundar
On Monday, May 27, 2013 at 4:55:28 AM UTC-4, Vikrant Rathore wrote:
>
> Dear All,
>
> I am looking for either full-time or part-time golang programmers. If you
> are located in Shanghai it will be better. Please contact me directly
Sorry Peter that got stuck in moderation I wrote it before your other
message
On Saturday, August 6, 2016, Peter Bourgon wrote:
> Again, there is no nomination process for the committee right now. Please
> don't propose yourself or others.
> On Sat, Aug 6, 2016 at 17:11 'Jessica Frazelle' via go
On Sat, Aug 6, 2016 at 5:50 AM, GoNutter wrote:
>
> I have a number of cases where I have to handle typed errors. I have been
> doing this previoiusly
>
> err :=SomeFunctionCall()
> if err != nil{
> switch e := err.(type){
> case sometype:
>//do something
> case someothertype:
>
On Sat, Aug 6, 2016 at 4:08 AM, T L wrote:
>
> If you carelessly change the value of a global variable in std lib, some
> hard found bugs will be created.
This is what you really want, and it is the reason I was talking about
immutable variables earlier.
In Go, a constant is created at compile t
Again, there is no nomination process for the committee right now. Please
don't propose yourself or others.
On Sat, Aug 6, 2016 at 17:11 'Jessica Frazelle' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> +1 to Dave Cheney.
>
> I agree we need as simple a solution as possible.
>
> I propos
I know that golang test/benchmark code are invoked by `go test`, but I'm
wondering how I can invoke them explicitly in my own main() function?
The reason I'm asking is that for those packages that don't provide any
sample code, their test code is the closest thing I can dipped into to turn
them
+1 to Dave Cheney.
I agree we need as simple a solution as possible.
I propose myself for the working group. I have dealt with the vendoring in the
docker project as well as medium to small sized projects and most currently in
kubernetes.
If elected, my platform will fight to make vendoring a
Hi,
I have a number of cases where I have to handle typed errors. I have been
doing this previoiusly
err :=SomeFunctionCall()
if err != nil{
switch e := err.(type){
case sometype:
//do something
case someothertype:
//do something else
default:
//do default
}
On the other hand, I would like to see introduced some variant of slices
with immutable backing arrays (it will allocate a lot though to modify a
variable of that type) that would be comparable. That's a whole other topic
however. slices are a much more delicate concept.
On Saturday, August 6,
If you carelessly do anything, you can introduce bugs.
Also note that it is fairly easy in Go to construct immutable "values".
The only thing we do not have is immutable value holders (let in other
languages) which is a form of static single assignment at the language
level.
The concept of vari
On Saturday, August 6, 2016 at 6:04:00 PM UTC+8, atd...@gmail.com wrote:
>
>
>
> On Saturday, August 6, 2016 at 11:53:42 AM UTC+2, T L wrote:
>>
>>
>>
>> On Saturday, August 6, 2016 at 5:45:50 PM UTC+8, atd...@gmail.com wrote:
>>>
>>> No, I'm saying that the current implementation is two pointers
On Saturday, August 6, 2016 at 11:53:42 AM UTC+2, T L wrote:
>
>
>
> On Saturday, August 6, 2016 at 5:45:50 PM UTC+8, atd...@gmail.com wrote:
>>
>> No, I'm saying that the current implementation is two pointers.
>> The value is addressed by the second pointer. So you cannot really put a
>> const
On Saturday, August 6, 2016 at 5:39:51 PM UTC+8, Dave Cheney wrote:
>
> Interfaces don't describe data, they describe behaviour. If you don't want
> the behaviour to be changeable, use a concrete type.
>
There is the need to define many constant interface values of one special
interface type,
On Saturday, August 6, 2016 at 5:45:50 PM UTC+8, atd...@gmail.com wrote:
>
> No, I'm saying that the current implementation is two pointers.
> The value is addressed by the second pointer. So you cannot really put a
> const in an interface. (thought experiment)
>
> Of course, in the specific cas
No, I'm saying that the current implementation is two pointers.
The value is addressed by the second pointer. So you cannot really put a
const in an interface. (thought experiment)
Of course, in the specific case of boxing a value type, that could work. If
you accept that the *typ never changes
Interfaces don't describe data, they describe behaviour. If you don't want
the behaviour to be changeable, use a concrete type.
On Saturday, 6 August 2016 19:30:22 UTC+10, T L wrote:
>
>
>
> On Saturday, August 6, 2016 at 5:19:08 PM UTC+8, Dave Cheney wrote:
>>
>> Because an interface is a run ti
On Saturday, August 6, 2016 at 5:19:08 PM UTC+8, Dave Cheney wrote:
>
> Because an interface is a run time data structure, it cannot contain
> constants because they don't exist at run time.
>
I think an interface is not essential to be always a run time data
structure. If compiler thinks it i
Because an interface is a run time data structure, it cannot contain
constants because they don't exist at run time.
On Saturday, 6 August 2016 19:14:26 UTC+10, T L wrote:
>
>
>
> On Saturday, August 6, 2016 at 3:58:52 PM UTC+8, Dave Cheney wrote:
>>
>> It is not possible. Constants only exist at
On Saturday, August 6, 2016 at 3:58:52 PM UTC+8, Dave Cheney wrote:
>
> It is not possible. Constants only exist at compile time.
yes, but why constant interface values can't exist at compile time?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" g
On Saturday, August 6, 2016 at 4:06:07 PM UTC+8, atd...@gmail.com wrote:
>
> Possibily, if you freeze the type of things that can be boxed by the
> interface. But what would it be useful for ?
> That would just mean that an interface is constant. Not even that the
> value it wraps can't be chan
Having read the question yet again, I think my answer is as wrong as the
others. Sorry about that.
He's already decided to use the Revel framework to build his web service.
What he appears to want is a piece of software that will create the web
service for him.
Is that correct, Kritika?
O
Actually, I think the word IDE in the question is a red herring. Kritka is
asking how to create web services that follow the MVC model. All of the
answers are about somebody's favourite IDE.
Kritika: if you search Google for "golang web service mvc framework" you
will find information about
On Saturday, August 6, 2016 at 4:06:07 PM UTC+8, atd...@gmail.com wrote:
>
> Possibily, if you freeze the type of things that can be boxed by the
> interface. But what would it be useful for ?
> That would just mean that an interface is constant. Not even that the
> value it wraps can't be chan
To be clear, there is no self-nomination or seconding/voting process
in place at this time. Thanks for bearing with me as I iron out the
final details of the process.
On Sat, Aug 6, 2016 at 7:16 AM, James Pirruccello
wrote:
> I'd be happy to second your nomination.
>
>
> On Saturday, August 6, 20
Possibily, if you freeze the type of things that can be boxed by the
interface. But what would it be useful for ?
That would just mean that an interface is constant. Not even that the value
it wraps can't be changed (because with the current implementation, the
values an interface wraps need to
It is not possible. Constants only exist at compile time.
--
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 optio
Is it possible to make an interface constant if its concrete value type is
bool/number/string?
On Saturday, August 6, 2016 at 3:48:17 AM UTC+8, Ian Lance Taylor wrote:
>
> On Fri, Aug 5, 2016 at 11:21 AM, T L >
> wrote:
> >
> > For an interface value, its internal values will never change.
>
35 matches
Mail list logo
