Hmm, I suppose I imagined having read a deeper reason than syntax :/.
That does seem like an incredibly shallow reason to introduce a whole
new non-orthogonal concept (I see others have attempted to tackle the
syntax issue, including yourself).
There are actually deeper difficulties than syntax
Quoting gary.willoug...@victoriaplumb.com (2018-10-11 10:38:38)
>Add it to this: https://github.com/golang/go/wiki/Go2GenericsFeedback
Already did (before posting to the list); it's at the top.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
Quoting Dean B (2018-10-11 14:58:01)
> Yeah that's why I was about how operators were the primary reason
> interfaces couldn't work out. Your proposal doesn't include operators,
> which was the reason interfaces aren't used. Syntax in Go is pretty
> important, which I imagine is the reason that
Quoting Eric Raymond (2018-10-15 23:32:22)
>Fair enough. I am completely willing to discard the possibility of
>overloading && and || and almost any other operator that doesn't behave
>like a function, because I think we get a rich enough set of contracts
>from those that do. As
Quoting Eric Raymond (2018-10-15 22:24:50)
>The simplest and most effective way to solve the generics problem is to
>embrace operator overloading and the kind of magic method designations
>that go with it.
This matches my intuition as well, though see below.
>Can it even
Cute. I think we're better off without it though; the use cases I can
think of for "generic booleans" are all way too clever.
FWIW, the uses of "generic booleans" I've seen in the wild don't
actually work with your proposal, because they really do need to
overload `and` and `or`, not just `not`.
Quoting Patrick Smith (2018-10-16 19:21:35)
>If overloading [] were disallowed, how would one write a generic
>function taking a single argument of type either []int or a
>user-defined type with similar behavior, and returning the sum of the
>elements? Sort of the marriage of
Quoting Eric Raymond (2018-10-16 13:41:47)
>On Tuesday, October 16, 2018 at 1:23:20 PM UTC-4, Dave MacFarlane
>wrote:
>
> [...]
>
> Would there be any rules defined for relationships between
> operators?
> For instance, if the "<" operator is defined does "<=" come for free
I write this kind of code a lot when working in Elm (whose generics are
in a similar spot to the place you suggest). It's not the worst, and
there various approaches in related languages use to make the "adaptors"
more ergonomic.
I still like the idea of using interfaces to express constraints
Quoting Ian Lance Taylor (2018-10-16 09:44:00)
> It's not clear to me what other aspects of various generic proposals
> you are picking up here. How are you imagining that we would write
> the function that merges two channels? With the current design draft
> that looks something like this:
>
>
Quoting Eric Raymond (2018-10-16 15:57:49)
>I don't undetstand rte q
rte q? I assume this is a typo, but I'm not sure what it was supposed to
be...
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
Quoting Eric Raymond (2018-10-16 16:14:46)
>It's up to the programmer to implement things like commutativity.� I
>don't think the language should pre-specify whether < is a partial or
>total ordering.� Any choice of this kind the language makes will
>inevitably turn out wrong a
Quoting Patrick Smith (2018-10-16 18:04:05)
>One way to avoid this is to supply the adaptor when the Set is created,
>store it in the Set, and thereafter used the stored adaptor instead of
>requiring an adaptor parameter.
This works for insert/member, but what about union, which
Quoting Ian Lance Taylor (2018-10-16 16:02:57)
> On Tue, Oct 16, 2018 at 8:39 AM, Eric Raymond wrote:
> >
> > New rule: A function on variables of undefined formal-argument types
> > compiles to a template (not a textual template - we don't want identifier
> > capture). At each callsite of the
Quoting Dave MacFarlane (2018-10-16 16:40:59)
> (Also, does this mean the compiler wouldn't be able to make any
> optimization assumptions regarding whether an operation is
> commutative/associative/distributive?)
This is true regardless, because we aren't actually *enforcing* these
properties;
Quoting Eric Raymond (2018-10-16 16:37:01)
> you either compile "a < b" using the "implements <" method of the
> concrete type or throw an error.
> This means that a change in the generic function, which happens to
> introduce a new use of the parameter, can cause a failure at the
>
Quoting Patrick Smith (2018-10-16 18:32:48)
>The union function could verify that the two adaptors are the same,
>using the == operator, and panic if not. However, this breaks down if
>the adaptors, instead of being defined as struct{}, are defined as
>types which don't support
Quoting robert engels (2018-10-18 15:22:36)
> Can you explain this a bit more, I must be missing something. Using the
> example:
>
> func F(a,b type T like(int,X)) {
> if a ...
> }
> }
>
> How do you pass a struct to F because < isn’t valid on structs ???
>
> Which is why I proposed that
Quoting Andy Balholm (2018-10-18 14:00:52)
> That would also be a weakness of most of the other proposals,
> including my own to add operators to interfaces. Contracts are more
> powerful, at the expense of extra complexity.
Fwiw, my own proposal for "just using interfaces" covered the graph use
Quoting robert engels (2018-10-22 16:01:18)
> I am sure it has been discussed, but why the aversion to using < > in
> type declarations? I guess I just don’t understand using bracketing
> notations that are already used for something else.
This was mentioned in the draft design, but using `<` at
Quoting Burak Serdar (2018-10-19 12:46:19)
> Where can I read about this "implements"? Link?
This is the thread:
https://groups.google.com/forum/#!search/go-nuts/golang-nuts/pR5pmql5olM/RPDuL2BsCAAJ
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
Quoting Burak Serdar (2018-10-19 12:34:44)
> Re: Ian Denhardt's proposal:
>
> I agree that it handles all the cases in the official proposal,
> but I think the syntax is too verbose and reminds me of
> Java. For instance, the "sorting" example can be written using
> the "like" keyword as:
>
>
Quoting Andy Balholm (2018-10-20 17:34:15)
> It’s just one of probably dozens of types of operations that people
> will want generic types to be able to support, besides method calls and
> operators. Adding support for them wouldn’t be very hard either, but by
> the time you got done, the result
Quoting alan.f...@gmail.com (2018-10-20 16:59:52)
>I haven't checked them all but I did notice one example which your
>paper doesn't appear to cover, namely the add1K example which has been
>a stumbling block for a lot of proposals including my own though I did
>eventually find a
Quoting Eric Raymond (2018-10-19 14:43:51)
>Therefore, as the author of the "implements" proposal, I am declaring
>neutrality on whether an "implements" clause should declare an overload
>at all!
>That is, there is a possible future in which "implements <" on type T�
>does
Quoting Burak Serdar (2018-10-19 14:09:46)
> It is useful in a linked list. You can instantiate a linked list
> template in a package, and use that concrete type in another package
> without access to the internals of the linked list.
Can you provide an example of what some code using this would
Quoting Burak Serdar (2018-10-19 15:13:20)
> Without operator overloading:
>
> type X interface {
>implements <
> }
>
> means that you want a primitive numeric type or a string. So:
This is not quite quite correct; in Eric's proposal, it is possible to
define (for example):
```
// A
First, I find the introduction to this condescending; it amounts to "the
Go developers know what they're doing, stop questioning them plebians!"
It is phrased more politely, but the content is basically there. This
is:
1. Insulting to those of us who also have put serious thought
into the
Quoting Eric S. Raymond (2018-10-19 16:15:25)
> Ian Denhardt :
> > What would code making use of a `Sortable` type look like? If you can't
> > actually use "implements <" to overload `<`, it's not clear to me what
> > it would actually do
I don't think you even need contracts as such at this point; you can do
a cast without them, so you just need to be able to specify a method set
on type parameters. I would be interested to hear your thoughts on the
proposal I wrote up on how to do this:
Quoting alan.f...@gmail.com (2018-10-13 15:39:46)
>Unfortunately, no approach is immune to silly mistakes by yours truly
>but, as it's an area where "Effective Go" could offer some pointers, it
>need not be unduly error prone in practice.
Still, some approaches are more error prone
Quoting alanfo (2018-10-13 13:26:18)
>Suppose we turn this strategy on its head and instead allow types which
>wouldn't otherwise do so support the ordering operators provided they
>satisfy a simple interface. This interface would have a single method
>which returned a string
Quoting Eric Raymond (2018-10-16 17:28:11)
>Fair enough. But is there any way to have a contract system of *any*
>kind that doesn't have the identical problem?�
Linked elsewhere in this thread, but I sketched something that I think
does the trick:
Hey all,
Today I've seen a lot of messages re: concerns about adding new keywords
and breaking backwards compatibility. People have floated a couple
approaches to avoiding breakage. But I feel like all of them that I've
seen so far will make code confusing. I'd like to propose an
alternative,
Quoting Mandolyte (2018-11-01 06:30:30)
> - it uses square brackets instead of (type .. ) for the type parameters
What does it do with `type Foo [T] int`? The draft design cites this
ambiguity (is it a generic type with an unused parameter, or an array of
length T?) as the reason for not using
Quoting Pat Farrell (2018-10-26 21:30:47)
>This leads to my second issue with the OP's ideas. I strongly believe
>that Java has been damaged by its attempt to deliver backward
>compatability. While others have brought up the potential issues with
>keywords, a much more telling
Quoting robert engels (2018-10-26 23:31:46)
>OK, you got me, I'm sucked in - it was a nice balance of yes, BUT no.
>
>First, there is simply no debate, Java += Android, and you have the
>most successful language/platform ever. NO debate.
>Arguing against Java's write-once, run
>Ah, I see. the albrow/fo package is the equivalent of just pasting the
>entire function into the contract.
It's not actually -- the rules seem to be those of the draft design,
with the contracts mechanism simply omitted. So e.g. there's no way to
write a max function; see:
Quoting Andy Balholm (2018-11-03 16:40:39)
> But if a mis-matched type was passed to Less, it would need to panic.
> So this option (using the Self type) would somewhat reduce
> compile-time type safety.
This is why I left `self` out of my own proposal; while I agree it would
be more ergonomic,
t must be a
>constant... so perhaps it can be figured out -
>see� https://play.golang.org/
>On Thursday, November 1, 2018 at 11:54:31 AM UTC-4, Ian Denhardt wrote:
>
> Quoting Mandolyte (2018-11-01 06:30:30)
> > - it uses square brackets instead of (type .. ) for
It's a little unclear to me what exactly you're trying to check; giving
an example might make it easier to advise.
But in any case, Go doesn't have anything quite like static_assert in
C/C++. Depending on what you're trying to do, you could put a call to
panic in an init() function, which would
Quoting Andy Balholm (2018-10-20 13:30:58)
> There are some contracts in the draft design that can’t be expressed with the
> “implements” syntax as it stands. Some would be fairly simple syntax
> extensions, but others describe the relationship between two types rather
> than just the
Quoting alan.f...@gmail.com (2018-10-19 16:19:36)
>Ian D,
>The introduction is certainly not intended to be insulting to those who
>have put serious thought into the problem. If it were, then I'd be
>insulting myself as I've put serious thought into at least two other
>
Quoting Burak Serdar (2018-10-19 17:01:42)
> On Fri, Oct 19, 2018 at 1:09 PM Ian Denhardt wrote:
> >
> > Quoting Burak Serdar (2018-10-19 14:09:46)
> >
> > > It is useful in a linked list. You can instantiate a linked list
> > > template in a package, and us
Quoting robert engels (2018-10-20 12:15:52)
>To be clear, this is only for that "performance case", where I don't
>want LinkedList to allocate internal nodes to hold the elements but the
>reasoning applies when using a simple LinkedList, and I want it to hold
>MyObj (which is not
a frozen package? Interesting ... I didn't know
>they had streams
>
>On Sun, Nov 4, 2018 at 12:20 PM Ian Denhardt <[1]i...@zenhack.net>
>wrote:
>
> What is the functionality that you're not seeing re: how to do file
> downloads over net/rpc?
> T
Quoting Steven Wiley (2018-11-05 22:12:40)
>And let's face it. Templates, operator overloading, and talk of
>generics has swirled around golang since its inception. Separating the
>template/generic/operational overload step from the core language via a
>pre-compile step� is one
What is the functionality that you're not seeing re: how to do file
downloads over net/rpc?
The thing that pops to my mind as likely important is the ability to
stream data, which you indeed cannot do with net/rpc.
If you need that I might suggest using a different rpc system that has
the
Quoting Lucio (2018-10-04 23:19:48)
>On Tuesday, 2 October 2018 15:21:08 UTC+2, Eric Raymond wrote:
>
>Is promised in the thread on pytogo, I have blogged on the general
>topic of rule-swarm attacks in the domain of language transformation.
>[1]http://esr.ibiblio.org/?p=8153
>
>
Worth noting, a related "translator's assistant" approach was taken when
bootstrapping the go compiler to be self-hosting:
* https://talks.golang.org/2014/c2go.slide#1
* https://github.com/rsc/c2go
The output has stood the test of time. The approach is a bit more
automated, at the cost of really
Quoting Ben Lubar (2018-09-29 14:40:28)
>[1]https://play.golang.org/p/iBAii-f84Sq
>vet is complaining because the unsafe.Pointer usage would normally be
>dangerous around the garbage collector, but since I have a finalizer on
>the "real" pointer and there is no way the code could
I've seen a lot of folks expressing the sentiment "we should just use
interfaces instead of this new contract thing." Most of the discussion
I've seen around this jumps right to operator overloading without being
terribly explicit about the general case; I've written a proposal
focusing on the
Yeah, there's no way to do this as such. One thing you could possibly do
instead is define a wrapper around the type and use methods:
type MyWrapper struct {
theSlice []Elem
}
type Index int
func(w MyWrapper) At(i Index) Elem {
return w.theSlice[int(i)]
}
func(w MyWrapper) SetAt(i
Quoting robert engels (2018-09-23 22:50:54)
>I'm often confounded when people discuss Java (at least in comparison
>to Go) as being "heavy". If you read early interviews with Gosling it
>is clear that his design was more about what to leave out, not what to
>include (macros,
Quoting Lucio (2018-09-21 16:15:19)
>The other thought I had, but is very poorly baked, is that the
>"essence" of polymorphism in Go operators is analogous to the informal
>definition of interfaces: it can be determined by the compiler, even
>though it is not expressed in a formal
On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
>
>I think the thing everyone who likes operator overloading like mainly
>is being able to do infix and postfix syntax, instead of only prefix
>(function).
My own reason for wanting this is not really about syntax,
Quoting Robert Engels (2018-09-23 13:38:04)
> I wasn’t suggesting that Go should resemble Java. I was just trying to point
> out that many of the current issues under debate for Go2 have been resolved
> quite well in other languages, and looking to them for direction should not
> be out of
>For example, for packages, variables, constants, functions, struct,
>project names, labels, methods and interfaces.
https://golang.org/doc/effective_go.html#names
That whole document is also worth a read.
-Ian
--
You received this message because you are subscribed to the Google
Quoting Bakul Shah (2019-01-02 03:07:14)
> On Tue, 01 Jan 2019 22:56:06 -0800 Ian Lance Taylor wrote:
> > On Tue, Jan 1, 2019 at 6:42 PM Bakul Shah wrote:
> > >
> > > On Tue, 01 Jan 2019 03:34:34 -0800 =?UTF-8?B?5LyK6Jek5ZKM5Lmf?=
> > > wrote:
> > > >
> > > > What are the reasonable reasons to
Quoting Victor Giordano (2019-01-16 12:44:57)
>"able" describes things in a more "passive way"� (the thing that you
>can "ask it/his/her" to do). Do you find this appreciation correct?
Pretty close, but a subtle point is that "-able" makes something the
indirect object, so for example
> They are not global variables, they are class variables. There's a
> huge difference.
Can you elaborate? I don't see a meaningful difference vs. Go's
package-level var.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
You could just do:
go build ./cmd/...
cp ./cmd/foo/foo ./
cp ./cmd/bar/bar ./
..and wrap it up in a script.
Quoting Tycho Andersen (2019-01-17 17:47:35)
> Hi everyone,
>
> I'm trying to get an existing project which outputs multiple binaries
> to work with go modules. The package follows
I feel like I should stress this a bit more, because it's really
important:
It is under no circumstances reasonable to rely on lack of source code
for security. History has taught us time and time again that security
through obscurity doesn't work, and home grown/custom algorithms are
usually
Quoting Space A. (2019-01-17 16:46:17)
> Go's package-level variables are also not "globals". And you can
> control access with exported/unexported names or exported/unexported
> package-level functions.
Exactly. A namespaced global is still a global, and most of the problems
with them still
Quoting robert engels (2018-12-11 19:39:46)
> I am not sure you can do this at the application layer - you need kernel
> support to drop packets.
One could write a mock implementation of e.g. net.Conn that does this
kind of simulation; have a goroutine that calls time.Sleep at random
intervals
It would be easier to help if you gave us a more concrete picture of
what you're trying to achieve; if there were a nice drop-in alternative
to generics in all circumstances already in the language, we probably
wouldn't be talking about adding them in the first place :P.
Quoting Tharaneedharan
Quoting Bakul Shah (2018-12-14 16:11:51)
> > If a function was labeled as pure ("pure func ...") the compiler
> > would not even need think hard, and if purity were a reflectable
> > attribute, then it is imaginable that compiling a function
> > invocation could be:
>
> This would complicate the
If you pass `-M intel` to objdump it will display intel syntax.
Quoting robert engels (2018-12-14 16:41:39)
>but the operands are backwards according to MOVQ on Intel, it
>should be
>dst,src
>SO, I'm thinking "intermediate code", so different syntax. Fine, but
>then when I use
Quoting Bakul Shah (2018-11-29 22:13:45)
> I doubt go2 will get generics flexible enough for this!
It can actually already pull much of this off, and you don't even need the
contracts part of the draft. E.g:
// Type 'Money' represents a monetary value. The Currency type parameter
// is unused
I believe Jan is talking about bits in the information-theoretic sense.
I.e, asking "how much do I know?", not "how much space does this take
up?"
Quoting robert engels (2018-11-29 17:10:51)
>Would you elaborate? I've read the discussion multiple times, and can't
>see what other bits you
Quoting robert engels (2018-12-02 00:59:31)
>Granted, their package structure seems poor in my opinion, but you
>can't talk bad about k8s.
Of course you don't lose anything by getting rid of the package names if
the package structure doesn't make any sense in the first place.
>And
Quoting Robert Engels (2018-12-01 22:25:06)
> The way to fix it though it just to use dot imports, and encourage it!
> The only time dot imports don't work is when there isn't package
> stutter. Seems like a no brainer and you get the best of both worlds.
My experience in every language I've
Based on your explanation, my original understanding of the semantics
were correct. This:
> import java.util.Collections;
..is not a dot import -- a dot import makes visible every (exported)
identifier in the package. This just exposes the one identifier --
Collections. I don't have a problem
Quoting robert engels (2018-12-02 01:43:45)
> import * + type inference + dynamic language = hell
Can't have type inference without types, so it's just the dynamic bit,
but I basically agree -- combined with the fact that you can do nonsense
black magic with the import machinery at runtime in
Quoting Robert Engels (2018-12-02 00:19:40)
> I know everyone hates it when I reference java but it has had dot
> importsat the package level since day one. I won’t repeat why that
> matters. It’s never been a problem.
>
> I don’t think I ever heard someone complain it was a problem in
> working
Quoting robert engels (2018-12-02 01:55:17)
> added to Go, but I am not sure if the package has a few related types
> (which it should IMO) it is any better than
>
> import . “package”
This also exposes stand-alone functions, constants etc. which doesn't
come up in Java.
I think the stutter
Quoting robert engels (2018-11-24 17:34:34)
> Agreed, but that is why I have a big problem with variable inference as used
> in Go (and now Java 9 with var).
>
> You need to refer to the callee API doc in order to gain understanding of the
> code - as the type information is not readily
Quoting robert engels (2018-11-24 17:06:29)
> I would argue that good code reads in a linear manner - if it doesn’t
> it is a problem with the programmer or the language syntax/grammer.
I think this is true on a small scale, but...
> On Nov 24, 2018, at 3:28 PM, Dan Kortschak
> wrote:
> > An
Quoting robert engels (2018-11-25 00:15:21)
> Contrast that with this actual code from the leading Go application (picked
> at random):
>
> func (p *pruner) prune(namespace string, mapping *meta.RESTMapping,
> includeUninitialized bool) error {
> objList, err :=
Quoting robert engels (2018-11-25 01:39:30)
> You kind of made my point, when you state “it’s either a slice or a
> map”… Well, what if the resource needed to be ordered, which is why the
> previous method has List in its name, but the method was actually
> returning a map.
If the authors of
Quoting roger peppe (2018-11-25 12:01:08)
>On Sun, 25 Nov 2018 at 16:54, 'Axel Wagner' via golang-nuts
><[1]golang-nuts@googlegroups.com> wrote:
>
>I'd suggest simply
>func (b *Binlog) writeArgumentToOutput(writer writer, arg uint64) error
>{ /* do the writing */ }
>and
Quoting 'yinbingjun' via golang-nuts (2018-11-19 22:23:35)
> First go should support generic types.
There's ongoing discussion of this in the context of Go 2; see:
https://blog.golang.org/go2draft
Which also links to the full draft designs, as well as feedback pages
(with *lots* of
Odd that the paper you chose to link to is one specifically addressing a
difficulty integrating the ideas with Java's class hierarchies -- while
the broader subject may be relevant to Go, I don't think that paper is.
Wrt Dan's question of doing static checks, I'll quote the paper:
> In
Quoting Marko Ristin-Kaufmann (2018-11-27 10:29:15)
> if you could call template hacks really dependent types...
You really couldn't, they're entirely different beasts.
>I expect most applications to need wider family of behavioral contracts
>-- and I doubt that Go would ever support
>From an implementation standpoint they are passed by reference (The
representation is actually a pair (pointer to vtable, pointer to
object), but from a semantic standpoint the difference still matters,
because e.g. if the original value was a struct, it still can't be
mutated. There are use
Quoting Robert Engels (2018-11-19 15:13:53)
> But isn’t that just for safety. Meaning the unmarshall could use it as a
> pointer via reflection and mutate it (but that is probably not what the
> caller expects in Go) ?
No, see:
https://play.golang.org/p/MyF0Dx87-1j
If you pass in instead
Possibly it's misleading if you're coming from C++ -- but if that's the
case you probably already know what pointers are. It's compatible with
how I've heard the term "reference" used in every other context. The
fact that they are first class values is an important point, however.
-Ian
Quoting
Quoting Andy Balholm (2019-01-03 18:34:35)
>It's at [1]https://github.com/rsc/c2go. It might be a good starting
>place, but there is one significant difference in approach from what
>Eric is proposing. Russ incorporated all of the manual cleanup into the
>tool (or config files) as
There's actually been a fair amount of conversation on this topic
lately. Most recently it came up in this thread:
https://groups.google.com/forum/#!searchin/golang-nuts/context|sort:date/golang-nuts/Lqoj5bNQxzg/5LUEYGHAGQAJ
My biggest worry about making it implicit is that it becomes hard
In general, after the message send goes through, the two goroutines
involved could start executing again in any order -- so the behavior
you're seeing is expected?
Is there a less toy example that this is supposed to be representative
of? Or were you just expecting it to work differently, and
Quoting Bhagvan Kommadi (2019-04-05 10:28:51)
> #machinelearning #go #fintech #algorithms #datastructures
1. This isn't twitter, it's a mailing list.
2. What on earth does this have to do with machine learning or fintech?
--
You received this message because you are subscribed to the Google
Quoting Robert Engels (2019-04-06 08:00:02)
>But yes, similar to how all recursive functions can be rewritten using
>loops, which are more efficient, that is essentially what tail call
>optimization does - just that the process it automatic.
Not all recursive functions -- just tail
Quoting David Finkel (2019-02-23 16:09:18)
>Not only is fmt.Printf a function call, but it makes a blocking
>syscall
>(write specifically),
>which gives the go runtime license to spin up a new OS thread and
>immediately schedule the other goroutine.
>runtime.GOMAXPROCS(1)
Quoting Space A. (2019-02-26 20:58:40)
> and stdlib only when redistributed separately as a whole in binary
> form. When stdlib is used to compile regular binary, it's not
> "redistributed"
This is not my understanding; in general static linking constitutes
distribution (though you are correct
Quoting Jingguo Yao (2019-02-22 03:17:33)
>Since both goroutines do not make any function calls
fmt.Printf is a function.
--
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
gt;time.Sleep(10 * time.Second)
>}
>Can goroutine 1 or goroutine 2 be preempted? If yes, by which
>mechanism?
>On Friday, February 22, 2019 at 4:20:12 PM UTC+8, Ian Denhardt wrote:
>
> Quoting Jingguo Yao (2019-02-22 03:17:33)
> > � � Since
Quoting Marvin Renich (2019-02-26 07:11:47)
> * Louki Sumirniy [190226 06:22]:
> > Assuming there is bytes in the system's entropy pool, you can also skip the
> > scrambling step, though I don't know what overhead consuming these bytes
> > entails compared to a standard PRNG. Then the biggest
Quoting Lucio (2019-03-12 02:13:00)
>specially in IM, because screenshots are a lot more informative (think
>graphics) and, these days, very easily accomplished.
The context of the discussion was screenshots *of text*, so this doesn't
really apply.
>The CoC should penalise only
Most of what you'd use promises for in Javascript would be better done
with channels & goroutines in Go, e.g:
resultChan := make(chan SomeType, 1)
go func() {
// do stuff
resultChan <- result
} ()
// do other stuff
result := <-resultChan // wait for the result.
This might be more directly what you're after:
https://kaitai.io/
Though disclaimer, I haven't used it myself.
Quoting Wojciech S. Czarnecki (2019-03-19 20:25:08)
> On Mon, 18 Mar 2019 09:59:59 -0700 (PDT)
> R Srinivasan wrote:
>
> > my intial attempts to define the data structures have
1 - 100 of 109 matches
Mail list logo
