I've long liked using ragel, but I have to say that with the projects
bus factor and recent removal of Go code generation, it's less
attractive than it used to be.
On Wed, 2017-08-23 at 23:56 -0700, Tamás Gulácsi wrote:
> See ragel for an fsm generator!
--
You received this message because you
On Thu, 24 Aug 2017 07:40:21 BST roger peppe wrote:
> On 24 August 2017 at 06:39, Bakul Shah wrote:
> >
> > Finally, for better performance it may make sense to store the
> > FSM as a vector of vectors or vector of maps so that a slice
> > of inputs may
See ragel for an fsm generator!
--
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
On 24 August 2017 at 06:39, Bakul Shah wrote:
> On Wed, 23 Aug 2017 12:11:41 BST roger peppe wrote:
>> On 23 August 2017 at 11:20, Bakul Shah wrote:
>> >
>> > I find regular functions much cleaner (and a closer analog of
>> > a
On Wed, 23 Aug 2017 12:11:41 BST roger peppe wrote:
> On 23 August 2017 at 11:20, Bakul Shah wrote:
> >
> > I find regular functions much cleaner (and a closer analog of
> > a digital FSM). See for example:
...
> > func stateOne(i inputType)
On Wed, Aug 23, 2017 at 6:20 AM Bakul Shah wrote:
> This is a Mealy machine, where the next state
> depends on the current state and current input (in s/w not
> much use for a Moore machine unless you are driving/simulating
> some regular physical process, in which case you
On 23 August 2017 at 11:20, Bakul Shah wrote:
> On Wed, 23 Aug 2017 09:48:14 BST roger peppe wrote:
>> On 23 August 2017 at 09:40, roger peppe wrote:
>> > On 23 August 2017 at 09:23, MartinG wrote:
>> >> Thanks for
On Wed, 23 Aug 2017 09:48:14 BST roger peppe wrote:
> On 23 August 2017 at 09:40, roger peppe wrote:
> > On 23 August 2017 at 09:23, MartinG wrote:
> >> Thanks for the fantastic explanation folks.
> >>
> >> I wonder if I can ask advice
On 23 August 2017 at 09:40, roger peppe wrote:
> On 23 August 2017 at 09:23, MartinG wrote:
>> Thanks for the fantastic explanation folks.
>>
>> I wonder if I can ask advice on how to improve my use case. I have a struct
>> type that represents a state
On 23 August 2017 at 09:23, MartinG wrote:
> Thanks for the fantastic explanation folks.
>
> I wonder if I can ask advice on how to improve my use case. I have a struct
> type that represents a state machine and each state is handled by a
> different method on that type, each
Thanks for the fantastic explanation folks.
I wonder if I can ask advice on how to improve my use case. I have a
struct type that represents a state machine and each state is handled by a
different method on that type, each with the same signature I use a
function variable to represent the
Yup, that's the one, thanks! (and retrospective thanks for the
suggestion in the first place :-])
On 22 August 2017 at 15:03, Jan Mercl <0xj...@gmail.com> wrote:
> On Tue, Aug 22, 2017 at 3:33 PM roger peppe wrote:
>
>> I *think* that the current implementation was inspired
On Tue, Aug 22, 2017 at 3:33 PM roger peppe wrote:
> I *think* that the current implementation was inspired by Minux's comment
here:
> https://groups.google.com/d/msg/golang-dev/G-uGL-jpOFw/vfazKS47_ckJ
>
> but I can't seem to find a comment from Russ that I seem to remember
This is a consequence of the decision to keep function pointers as
single-word values.
Discussion was here
https://groups.google.com/forum/#!msg/golang-dev/G-uGL-jpOFw/pEFi6tsdkdUJ
https://groups.google.com/d/msg/golang-dev/x328N8hiN5k/i5LJIXGmi_gJ
I *think* that the current implementation was
On Tue, Aug 22, 2017 at 1:35 PM MartinG wrote:
> In the below code example, setting a function variable to a simple
function makes no memory allocation and is very fast (<1ns). The case of
setting the same function variable to a method value is much slower (~30ns)
and it turns
Hi,
In the below code example, setting a function variable to a simple function
makes no memory allocation and is very fast (<1ns). The case of setting
the same function variable to a method value is much slower (~30ns) and it
turns out to be because memory is allocated there. (16 B/op)
I
16 matches
Mail list logo