That's great news Chris! Is it documented anywhere with some more detail this
pure Go implementation? I'd love to know more about how you overcame the
initial problems such as external code execution that lead you to choose LuaJit
in the first place.
Thanks,
Pablo
--
You received this message
Hi Alex,
Thanks for that. I'll check it out and integrate it in. Will give it a longer
soak test too.
Yes packets do get received out of order. They are to a nanosecond accuracy
from the source and so with transmission times etc they do come ever so
slightly out of order. As I am also compar
just as a warning, you may get unexpected results if you're working
with "compressed" gifs. i.e., file where the next frame is only the
difference between this one and the previous one. there are also
interlaced gifs, etc. i suggest you use "gifsicle" (available on
linux) to expand the gif first an
Wow!
On Sat, Jan 21, 2017 at 9:58 AM, wrote:
> Hi,
>
> I have been working on a package to compile go templates to regular go
> code.
> Today i can announce an early release of it.
>
> Find it here
> https://github.com/mh-cbon/template-compiler
>
> There is still have a lot to test and comment,
If you don't know or care about pagers and process management, you can stop
reading now.
*Background:* I have a program that compile my code each time I modify it.
It produces logs continuously on a terminal.
I'm trying to write a go program to wrap this program so that each compile
log is op
I think the upload has ruined the frames. I'll try another gif tomorrow.
On Saturday, 21 January 2017 16:57:15 UTC, andrey mirtchovski wrote:
>
> I see only a single frame in your source file. I ran your program on
> another gif and got the expected result:
>
> http://i.imgur.com/HOnlU1q.gif
>
In https://play.golang.org/p/fqPXXpNufO you need to protect all channelMap
access with a mutex, in https://play.golang.org/p/88zT7hBLeD you don't. If
you make it a package-level var, `make` it in `init` or check if it is nil
before you `make` in jobDispatcher, as you should assume you have no
c
I see only a single frame in your source file. I ran your program on
another gif and got the expected result:
http://i.imgur.com/HOnlU1q.gif
http://i.imgur.com/GnSUHQ1.gif
On Sat, Jan 21, 2017 at 8:54 AM, kalekold via golang-nuts
wrote:
> Hi,
>
> I'm trying to draw some text on an animated gif a
Thanks all,
Peter Wang, I see the same thing, but Dave Cheney link explain, this is a
fake time on playground.
Thanks team :D
Em sábado, 21 de janeiro de 2017 05:41:54 UTC-4, Dave Cheney escreveu:
>
> The playground fakes time, which may explain what you see.
> https://blog.golang.org/playgro
Hi,
I have been working on a package to compile go templates to regular go code.
Today i can announce an early release of it.
Find it here
https://github.com/mh-cbon/template-compiler
There is still have a lot to test and comment,
and to detect some edge cases.
But the general idea and structu
I just uploaded a working example to https://play.golang.org/p/88zT7hBLeD
It is a long running process so will need running locally on a machine as
the playground kills it. Hopefully this will help get to the bottom of it!
Lee
On Saturday, January 21, 2017 at 8:24:04 AM UTC, l...@pinkfroot.com
Hi,
I did some more tracing and I could narrow down the problem to the call
when writing data synchronously to the sound card.
When the sound card does not receive the data in time, it will cause an
"Underflow". I read that the underlying, platform specific sound card
drivers handle Underflows di
Hello John
Not sure how relevant for the topic, but: there exist a way to "try to
read a channel, in a non-blocking way if no value is ready yet", using
*default* :
select {
case x, ok := <-ch:
if ok {
fmt.Printf("Value %d was read.\n", x)
} else {
On Fri, 20 Jan 2017 09:59:33 -0800 (PST)
"John C." wrote:
> Thank you for the explanations. I also received a helpful note off
> list, put here for posterity:
>>> I suggest a thought experiment. You understand just fine how to
>>> use the select statement, so maybe try to imagine how are you'd
The playground fakes time, which may explain what you see.
https://blog.golang.org/playground
--
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+unsubsc
I run example B both playground and my linux(amd64) node, behavior is
different
At playground, function A, B, C run immediately, then program end
immediately
At my linux node, function A, B, C run immediately, but program end after
wait 5 seconds
I confuse why function A and C never sleep 5 se
if you get into the fmt.println, you will see the output device is
os.Stdout, any println call will direct output into it nodelay
在 2017年1月21日星期六 UTC+8上午11:34:09，Rodolfo Azevedo写道：
>
> Hi all,
>
> I have a question, interesting:
>
> Why the executes is diferente in these both situations?
>
> Exec
Thanks Alex,
I did what I would call a halfway house so to speak...
https://play.golang.org/p/fqPXXpNufO
It ran for much longer before locking on the same line! Trouble is, now I
can't actually see the lock whereas I could before!
I'm wondering if I should keep a global channelMap and lock t
18 matches
Mail list logo
