You are ignoring an important situational fact...the serial port is not an
infinite stream to you, but a sequence of serial ports divided by
connection closings. In this situation, the thing to be scanned is
experiencing EOF at close events but this is not being communicated. That
is the problem. N
When reading from a serial port, there is no EOF between data sets. I may
have to use something else besides a scanner to do this. I have a handler
function called by a goroutine that just monitors incoming data in a for
loop and sends that data coming in back through a channel. If the
conne
Scan() returns false when it reaches EOF or an error, so with what you
provided i assume you're missing to check that.
for ns.Scan() {
...
}
or
for {
if !ns.Scan() {
break
}
-wgr
On Sun, Dec 30, 2018 at 10:36 PM Trig wrote:
>
> I'm currently utilizing the bufio.NewScanner to read ASCII dat
I'm currently utilizing the bufio.NewScanner to read ASCII data from a
serial port. I have the following simple code:
ns := bufio.NewScanner(sPort)
for {
ns.Scan()
if ns.Text() != "" { // ignore blank lines
// handle content here
}
}
The problem is ns.Scan() blocks the loop from
Hi,
For anyone still interested in this project but held back by the EFL build
or runtime dependency then I have good news:
* Our new default driver does not rely on additional libraries * :)
We have moved to an OpenGL driver - using go-gl and glfw so all you need is
the system libraries - and no
I wanted to be able to archive the posts from the go.science Google+
community. So I have made a pico tool that will do this, packaging up
the posts and JSON manifest into a zip when given the metadata from
Takeout.
The tools is available here: https://github.com/kortschak/delivery
It requires th
It's easy to use Go on the Raspberry Pi (with or without
cross-compilation), and AFAIK you can gain low-level access to the hardware
in almost the same way than in C.
For example, you can use all the features of the GPIO by mmap-ing the
registers dedicated to its control (under linux the corres
On Sun, Dec 30, 2018 at 12:05 PM Ian Lance Taylor wrote:
> On Sat, Dec 29, 2018 at 11:12 PM Caleb Spare wrote:
> >
> > I noticed the following:
> >
> > package main
> >
> > func main() {
> > x := float64(1 << 3) // fine (constant expression)
> >
> > v := uint(3)
> > x = float64(1 << v) // invali
On Sat, Dec 29, 2018 at 11:12 PM Caleb Spare wrote:
>
> I noticed the following:
>
> package main
>
> func main() {
> x := float64(1 << 3) // fine (constant expression)
>
> v := uint(3)
> x = float64(1 << v) // invalid operation: 1 << uint(v) (shift of type float64)
>
> _ = x
> }
>
> (playground:
On Sat, Dec 29, 2018 at 11:23 PM wrote:
>
> Any example on how I can build cgo code using custom toolchain?
I'm not sure what you are asking. Even with a custom toolchain, can't
you just `go build`?
If you need to run cgo directly, there are some brief docs for that at
the bottom of https://gol
On Sat, Dec 29, 2018 at 8:47 PM Michael Jones
wrote:
> Never use a cannon as a fly swatter.
> A regular expression is heavy artillery.
> A for-loop will do just fine: smaller, simpler, faster, land ess
> dependencies:
>
A +100 to Michael's reply. Before falling in love with Python ~15 years
ago
golangbridge and all subdomains are gone.
Please notify administrators.
--
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.
I woke up at 2am here bugged about my former reply. Here's version 2...
https://play.golang.org/p/lky_W20CKnM
...should have sent this the first time. Sorry!
On Sat, Dec 29, 2018 at 9:09 PM Kurtis Rader wrote:
> On Sat, Dec 29, 2018 at 8:47 PM Michael Jones
> wrote:
>
>> Never use a cannon as
Maybe fmt.Errorf encourages
fmt.Errorf("%v %v", false, 42)
Or worse
fmt.Errorf("error %v %v", false, 42)
:-)
On Sun, Dec 30, 2018, 1:07 AM Jakob Borg I would suggest that an error should start with a descriptive string. The
> existing methods encourage this. A fmt.Error as suggested would n
I would suggest that an error should start with a descriptive string. The
existing methods encourage this. A fmt.Error as suggested would not, instead
implicitly encouraging things like fmt.Error(false, 42) which is user
unfriendly.
//jb
On 30 Dec 2018, at 09:53, Justin Israel
mailto:justinis
On Sun, Dec 30, 2018 at 9:26 PM Liam Breck wrote:
> Justin, see docs for fmt.Print(...interface{})
>
Ah true. I forgot about the whitespace formatting versions. I stand
corrected that a fmt.Error would actually perform formatting and would be
consistent with Sprint and Print. My only guess now i
Justin, see docs for fmt.Print(...interface{})
On Sun, Dec 30, 2018, 12:15 AM Justin Israel
>
> On Sun, Dec 30, 2018, 7:24 PM Liam Breck wrote:
>
>> What's the rationale for omission of:
>> fmt.Error(a ...interface{}) error
>>
>
> What does it mean for this function to accept a variable number
On Sun, Dec 30, 2018, 5:02 PM wrote:
> I'm a beginner in Golang and quite confusing about using packages in a
> program. For example, every non simple software has a bunch of classes and
> interfaces or utility classes which are usually lokated in different
> packages in the same program. So usin
On Sun, Dec 30, 2018, 7:24 PM Liam Breck wrote:
> What's the rationale for omission of:
> fmt.Error(a ...interface{}) error
>
What does it mean for this function to accept a variable number of
arguments when there is no formatting or printing implied by the name of
the function?
> Given that
I will try some of the suggestion in this topic to see what works out.
I will open a feature request in the golang repo for forking support.
On Saturday, December 29, 2018 at 6:56:32 AM UTC+2, Nathan Fisher wrote:
>
> TLDR
>
> > Is it possible to fork a repo and change the import path of the
> r
20 matches
Mail list logo
