[go-nuts] Re: Update to generics proposal

2021-04-03 Thread Eltjon Metko
I was fully expecting for floodgates of comments to open again but it seems 
we have reached a point of maturity in the generics proposal. 
The new proposal really makes the intent much clearer both on the exact vs 
underlying type match front  and the syntax gives us a more familiar union 
intent. 
So in that light this proposal is a welcome change by itself. 

If this would allow us then later to switch on the matched type (preferably 
without type assertion, along the lines of the comment in 
https://github.com/golang/go/issues/45346#issuecomment-812557199 ) 
than it would make this implementation of  generics much more useful.  
On Friday, April 2, 2021 at 1:00:06 AM UTC+2 Ian Lance Taylor wrote:

> We've just posted a potential update to the generics proposal at
> https://golang.org/issue/45346. This clarifies and simplifies the
> type lists that appear in interfaces, and let's us drop the "type"
> keyword used to mark such lists.
>
> Ian
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f6cf4e9f-5d8c-44cc-92de-aaa3915f155fn%40googlegroups.com.


Re: [go-nuts] Sending Escape codes to printer

2021-04-03 Thread Hugh Myrie
Awesome, thanks!

On Sat, Apr 3, 2021 at 5:15 PM Kurtis Rader  wrote:

> Start here: https://golang.org/ref/spec#Rune_literals. Then read the next
> section about string literals and note that rune escape sequences are
> recognized inside double-quoted strings. For example, your feed paper
> command could be written "\033J\004" or "\x1bJ\x04". There are other ways,
> of course, to construct such strings that may be more readable by using
> constant declarations such as `const Esc '\x1b'`.
>
> On Sat, Apr 3, 2021 at 2:55 PM Hugh Myrie  wrote:
>
>> Given the following, how do I send escape codes to print?
>>
>> for _, line := range lines {
>> fmt.Fprintf(p, "%s\r\n", line)
>> }
>>
>> How do I send escape sequences using the above print command?
>>
>> Below is a C# example:
>>
>> output = Chr() & "V" & Chr(66) & Chr(0);
>>
>> I want to send the escape codes to a receipt printer to control the
>> perform cetrain functions.
>>
>> Some commands include:
>> ESC "J" 4  <--Feed paper
>>
>>  GS "!" 0x11  <-- change character size
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/b420e7fc-55c4-452c-822e-e84a3b96da85n%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>


-- 
http://www.jaxtr.com/blessed_hope

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN-X3%3DZkwmbhhKiS6CVCmuAGzbzvGOLgqJT5%2BwFCjn8zLwv7Rw%40mail.gmail.com.


Re: [go-nuts] Sending Escape codes to printer

2021-04-03 Thread Kurtis Rader
Start here: https://golang.org/ref/spec#Rune_literals. Then read the next
section about string literals and note that rune escape sequences are
recognized inside double-quoted strings. For example, your feed paper
command could be written "\033J\004" or "\x1bJ\x04". There are other ways,
of course, to construct such strings that may be more readable by using
constant declarations such as `const Esc '\x1b'`.

On Sat, Apr 3, 2021 at 2:55 PM Hugh Myrie  wrote:

> Given the following, how do I send escape codes to print?
>
> for _, line := range lines {
> fmt.Fprintf(p, "%s\r\n", line)
> }
>
> How do I send escape sequences using the above print command?
>
> Below is a C# example:
>
> output = Chr() & "V" & Chr(66) & Chr(0);
>
> I want to send the escape codes to a receipt printer to control the
> perform cetrain functions.
>
> Some commands include:
> ESC "J" 4  <--Feed paper
>
>  GS "!" 0x11  <-- change character size
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b420e7fc-55c4-452c-822e-e84a3b96da85n%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD-UGZvQYjicETENUf4oubxGb-miHxeLqN1_%2BhwfDUi__A%40mail.gmail.com.


[go-nuts] Sending Escape codes to printer

2021-04-03 Thread Hugh Myrie
Given the following, how do I send escape codes to print?

for _, line := range lines {
fmt.Fprintf(p, "%s\r\n", line)
}

How do I send escape sequences using the above print command?

Below is a C# example:

output = Chr() & "V" & Chr(66) & Chr(0);

I want to send the escape codes to a receipt printer to control the perform 
cetrain functions.

Some commands include:
ESC "J" 4  <--Feed paper 

 GS "!" 0x11  <-- change character size

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b420e7fc-55c4-452c-822e-e84a3b96da85n%40googlegroups.com.


[go-nuts] Re: Data Sharing with Non go application

2021-04-03 Thread R Srinivasan
Great suggestions. Thanks. I will investigate the options. srini

On Saturday, April 3, 2021 at 11:20:35 AM UTC-4 Brian Candler wrote:

> Have a look at nanomsg.   This should abstract away some of the underlying 
> complexity and let you switch between TCP, IPC and other transports.
>
> Also look at serialization formats where the data can be consumed without 
> unpacking it: flatbuffers / flexbuffers, capnproto
>
> (These suggestions are on the assumption that you expect the overhead of 
> message passing to be significant compared to the processing done on each 
> message.  If that's not true, then you might as well just stick to gRPC)
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/eb3d489b-dc3d-45eb-9bf8-a7af5dae680en%40googlegroups.com.


Re: [go-nuts] Re: Alternate implementations of regular expression matching?

2021-04-03 Thread Artur Vianna
Oops sorry, Powerset algo is actually O(n*2^n) time complexity

On Sat, 3 Apr 2021, 13:49 Artur Vianna,  wrote:

> An interesting approach would be the implementation of a regex engine that
> has optimizations just like a compiler (i think the stdlib one does that to
> an extent). Using powerset and hopcroft's where it can be used and leaving
> backtracks where it can't.
>
> That would be fun to implement but very confusing for the user and has the
> same security problems of a NFA backtracking regex, but the user would be
> able to choose the backtracking features, being aware that they pose
> security problems.
>
> Powerset algorithm is O(n²) too, so while converting the NFA to DFA some
> strings like (a*b*)^n can take forever basically, a possible security
> problem if your regex came from user input.
>
> On Sat, 3 Apr 2021, 13:31 bobj...@gmail.com,  wrote:
>
>> In *my* ideal world, both O(n) and backtracking implementations would be
>> available in the standard library.
>>
>> Most popular languages have only backtracking versions in their standard
>> libraries (Java, Python, Ruby). It's nice that Go has an O(n)
>> implementation. But, some regexes that can be written in the modern
>> backtracking implementations that support "atomic groups", etc. just cannot
>> be rewritten for O(n) implementations, sometimes resulting in having to
>> write a lot of code to achieve the equivalent result. The reason that O(n)
>> implementations lack those features is that they simply can't be done
>> without violating O(n). So why not let the programmer exercise the choice
>> -- O(n) where possible for denial-of-service safety or maybe better
>> performance, and backtracking when O(n) can't be done or maximum
>> performance is not important, and regexes incoming from the wild do not
>> happen.
>>
>> And... I suspect that well written regexes for backtracking can be nearly
>> as performant if backtracking is kept under control via skillful use of
>> those atomic features. It's the sloppy ones that are the problem.
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/7afca073-a3ff-464c-8de4-8b2ba7c4d214n%40googlegroups.com
>> 
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAE%3DAWBUE4fFWWFOVzhF-WpMZZL6L15XCd-L3yAWj9k_CtkFr7Q%40mail.gmail.com.


Re: [go-nuts] Re: Alternate implementations of regular expression matching?

2021-04-03 Thread Artur Vianna
An interesting approach would be the implementation of a regex engine that
has optimizations just like a compiler (i think the stdlib one does that to
an extent). Using powerset and hopcroft's where it can be used and leaving
backtracks where it can't.

That would be fun to implement but very confusing for the user and has the
same security problems of a NFA backtracking regex, but the user would be
able to choose the backtracking features, being aware that they pose
security problems.

Powerset algorithm is O(n²) too, so while converting the NFA to DFA some
strings like (a*b*)^n can take forever basically, a possible security
problem if your regex came from user input.

On Sat, 3 Apr 2021, 13:31 bobj...@gmail.com,  wrote:

> In *my* ideal world, both O(n) and backtracking implementations would be
> available in the standard library.
>
> Most popular languages have only backtracking versions in their standard
> libraries (Java, Python, Ruby). It's nice that Go has an O(n)
> implementation. But, some regexes that can be written in the modern
> backtracking implementations that support "atomic groups", etc. just cannot
> be rewritten for O(n) implementations, sometimes resulting in having to
> write a lot of code to achieve the equivalent result. The reason that O(n)
> implementations lack those features is that they simply can't be done
> without violating O(n). So why not let the programmer exercise the choice
> -- O(n) where possible for denial-of-service safety or maybe better
> performance, and backtracking when O(n) can't be done or maximum
> performance is not important, and regexes incoming from the wild do not
> happen.
>
> And... I suspect that well written regexes for backtracking can be nearly
> as performant if backtracking is kept under control via skillful use of
> those atomic features. It's the sloppy ones that are the problem.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7afca073-a3ff-464c-8de4-8b2ba7c4d214n%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAE%3DAWBW9PaP%2BA%2BnKsBfGQgDWLJ73y%3DBpHyP%2B_r%2BPHrOvODDwqA%40mail.gmail.com.


[go-nuts] Re: Alternate implementations of regular expression matching?

2021-04-03 Thread bobj...@gmail.com
In *my* ideal world, both O(n) and backtracking implementations would be 
available in the standard library.

Most popular languages have only backtracking versions in their standard 
libraries (Java, Python, Ruby). It's nice that Go has an O(n) 
implementation. But, some regexes that can be written in the modern 
backtracking implementations that support "atomic groups", etc. just cannot 
be rewritten for O(n) implementations, sometimes resulting in having to 
write a lot of code to achieve the equivalent result. The reason that O(n) 
implementations lack those features is that they simply can't be done 
without violating O(n). So why not let the programmer exercise the choice 
-- O(n) where possible for denial-of-service safety or maybe better 
performance, and backtracking when O(n) can't be done or maximum 
performance is not important, and regexes incoming from the wild do not 
happen.

And... I suspect that well written regexes for backtracking can be nearly 
as performant if backtracking is kept under control via skillful use of 
those atomic features. It's the sloppy ones that are the problem.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7afca073-a3ff-464c-8de4-8b2ba7c4d214n%40googlegroups.com.


Re: [go-nuts] Data Sharing with Non go application

2021-04-03 Thread Shulhan
On Sat, 3 Apr 2021 03:42:03 -0700 (PDT)
R Srinivasan  wrote:

> In my app, I would like to use golang for a data aggregator
> subsystem. Would like a fast and efficient way of sharing this data
> with a consumer subsystem developed in C++. (Both running in the same
> system).
> 
> Solution I am pursuing is a shared memory but I am stuck at a
> somewhat platform independent way of controlling access to this
> shared memory. Semaphores, Mutexes that I search for in the go world
> lead to intra process examples.
> 

You should not pursue that, it may be possible, but it will lead to
complicated code and hard-to-debug program.  My suggestion is put the
message bus/broker in between the producer (Go program) and consumer(s)
(C++), even thought both running in the same system.  It will ease
your mind, now and later.  My preference for message bus/broker is Nats
[1].

> Platforms of interest - Linux and Windows.
> 
> Looking for ideas.
> 
> Thanks, srini
> 

[1] https://nats.io

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20210403191007.7f936764%40inspiro.shul.localdomain.


pgpURHrcw3tWz.pgp
Description: OpenPGP digital signature


Re: [go-nuts] Re: Design patterns. builder ?

2021-04-03 Thread alex-coder
Hi, 
thank you for  everyone!

The main point here is: "generally isn't needed", but sometimes structure 
does not come described properly in some kind of string representation. :-)
the pair Func / funchandler - just excellent ! 
But what about other GO-4 patterns, I mean "isn't needed in go" ?
Where take a look at ?

Thank you.

On Thursday, April 1, 2021 at 4:29:14 PM UTC+3 ren...@ix.netcom.com wrote:

> The Go protobufs impl uses the builder pattern. 
>
> On Apr 1, 2021, at 2:21 AM, Brian Candler  wrote:
>
> The builder pattern generally isn't needed in go, because go has flexible 
> struct literals where you can omit any members you don't want. 
>
>
> You can implement it if you like, but it just adds a layer of boilerplate:
> https://gist.github.com/vaskoz/10073335
>
> Some people are drawn to functional options instead:
> https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis
>
> https://www.calhoun.io/using-functional-options-instead-of-method-chaining-in-go/
>
> But if you look at the standard library as a source of inspiration and 
> good practice, complex configuration is typically done via structs.  See 
> for example http.Server 
>
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/39e38cd7-93ee-4084-89e4-a22bcd1baaa6n%40googlegroups.com
>  
> 
> .
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cd0d77b4-f86e-4244-8e60-70ee07b96ad4n%40googlegroups.com.


[go-nuts] Data Sharing with Non go application

2021-04-03 Thread R Srinivasan
In my app, I would like to use golang for a data aggregator subsystem. 
Would like a fast and efficient way of sharing this data with a consumer 
subsystem developed in C++. (Both running in the same system).

Solution I am pursuing is a shared memory but I am stuck at a somewhat 
platform independent way of controlling access to this shared memory. 
Semaphores, Mutexes that I search for in the go world lead to intra process 
examples.

Platforms of interest - Linux and Windows.

Looking for ideas.

Thanks, srini

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cb5f0db1-5cd6-49c7-92a1-cdb85f90d9bcn%40googlegroups.com.