On Tuesday, 4 October 2016 16:23:05 UTC+3, mhh...@gmail.com wrote:
>
> On Tuesday, October 4, 2016 at 1:55:56 PM UTC+2, Egon wrote:
>>
>> On Tuesday, 4 October 2016 14:11:03 UTC+3, mhh...@gmail.com wrote:
>>>
>>> Hi!
>>>
>>> I m not sure to get why you say 2-4 is not worthy.
>>>
>>> Is it because it seems there is no generic implementation of such 
>>> behavior ? 
>>>
>>
>> I've written 3-6 hot reloaders, and I've yet to stumble on a "great 
>> general purpose implementation".
>>
>
> I m interested to know more about this, 
> if you d agree to share. I m sure it is valuable.
>

With varying quality:

category 0: (internally uses category 4)
https://github.com/loov/watchrun/
https://github.com/loov/watchrun/blob/master/watch/monitor.go

category 1:
https://github.com/loov/spaceshift/blob/master/main.go#L122
https://github.com/loov/timeclock/blob/master/main.go#L92

category 3:
https://github.com/raintreeinc/knowledgebase/blob/master/module/dita/module.go#L139

*batching buffer for fsnotify*
*https://github.com/spf13/hugo/blob/master/watcher/batcher.go*

category 4:
https://github.com/raintreeinc/livepkg
(handles JS/CSS reloading, but expects some conventions to be followed)

I had more, but dropped most of them in favor of using watchrun or category 
4. And probably some which I don't even remember.

I've also had some networking programs that watched changes on one computer 
and automatically rebuilt program, download to another computer and start.
 

> Besides that i want to put emphasis i did not mean to make you angry, 
> that really was not my intent at all, if that ever happened.
>

No worries... :D, I just tend to write directly and avoid all the "IMHO"-s 
because I think it harms text readability; which might come across as 
"agressive".

Generally, very happy to discuss things >^.^<
 

>
> I m not very interested into arguing about non technical concerns.
> Said differently, don t tell me how to behave, instead, 
>

The reasons I outlined weren't meant to tell how to behave, but rather 
where I see the value and what has been useful to me. Of course, I 
understand situations vary and therefore the "best solution" will also vary 
*(hence 
the several categories of possible solutions)*.
 

> participate, if you d like to, into producing correct/better algorithms. 
>

> This said, two quick notes,
>
> In my concern i do see the immediate benefits, 
> and while i agree the end user does not care, 
> my clients does.
>

Sure, then go ahead. :)


> Lastly, regarding the use of go fmt, for a non officially published source 
> code,
> I feel like my indentation is correct. And, yes, to me, two spaces is 
> tasty.
>

gofmt as usual:

*Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.*

 
I don't like all the decisions that gofmt did, but it helps others to read 
my code -- and after getting used to it (~2 week), I rarely notice the 
issues anymore. The convenience from automatic formatting after saving is 
much nicer than the "perfect style" -- and yes, I also use two spaces in 
some languages and in some four spaces... but automatically formatted to 
the language-s "standard formatter", if there is one... if there isn't a 
standard, I'll use the formatter that is easiest to setup.

*But, as usual, you are free to do with your source as you please. :)*


> The day I ll publish such source code, give it a name and a version, 
> so you may depend on it, 
> I ll setup a bump script to make sure it always happen, 
> so everyone s always happy.
> It will even do the test, vet, changelog etc...
>
> Anyways, 
> thanks again for your interest, sharing and proposals, 
> it s sincerely appreciated.
>

-- 
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 https://groups.google.com/d/optout.

Reply via email to