[go-nuts] [ANN] astitodo: a TODO parser written in GO
Hey guys, I'm happy to announce astitodo, a TODO parser written in GO: https://github.com/asticode/go-astitodo I know most IDEs already parse TODOs but they usually have problems with multi line TODOs, can't parse assignees, etc. This is also a good start for people who want to use AST. Cheers -- 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.
[go-nuts] [ANN] astisub: Manipulate subtitles in GO (.srt, .stl, .ttml, .webvtt, etc.)
Hey guys, I'm happy to announce go-astisub, a Golang library to manipulate subtitles : https://github.com/asticode/go-astisub. It allows you to manipulate .srt, .stl, .ttml and .webvtt files for now. Teletext, ssa/ass and .smi will come shortly. Available operations are parsing, writing, syncing, fragmenting, unfragmenting, merging, etc. Let me know what you think. Cheers Quentin -- 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.
[go-nuts] Re: [ANN] astilectron - Build cross platform GUI apps with GO and Electron (HTML/JS/CSS)
I do agree with you regarding the size of the app once everything is setup. Honestly chosing Electron is more a choice by default than anything else. imo the chosen project should: - be cross platform - be well maintained - allow creating non-native looks through HTML/JS/CSS since I think it's the easiest for the most of us Here's a list of what I've tried so far: - https://github.com/andlabs/ui : drawbacks are it has limited features, force you to have a native look and can't do things like capturing the "Enter" key event in an input box - https://github.com/miketheprogrammer/go-thrust : drawback is it's not maintained anymore - https://github.com/alexflint/gallium : drawback is it's not cross-platform (only MacOSX last time I checked) - https://github.com/murlokswarm/app : drawback is it's not cross-platform (only MacOSX too) - https://github.com/arvitaly/gopherjs-electron : drawback is it's not maintained anymore - https://github.com/rrohrer/go-electroncontrol : drawback is it's not maintained anymore - https://github.com/nodekit-io/nodekit : drawback is it's not maintained anymore As you can see none of them meet the 3 requirements. Which leaves us with Electron which is cross platform, well maintained and allow creating non-native looks through HTML/CSS/JS. If there are other projects I've missed, feel free to let me know, once again chosing Electron is more of a choice by default than anything else. PS : if you're only interested in window positioning and decoration, and don't care about dealing with HTML/CSS/JS I recommend using https://github.com/andlabs/ui which is an awesome project! Le jeudi 27 avril 2017 11:33:10 UTC+2, mhh...@gmail.com a écrit : > > I like it too, i'm only worried by the size of the app once everything it > setup. > > I wonder if its not possible to have something smaller, > obviously with less capabilities. > > imho, i m interested mostly in window positioning and decoration. > Communication is less interesting to me as i can work with http apis, or > so. > > any ideas ? > > On Tuesday, April 25, 2017 at 9:54:22 PM UTC+2, Asticode wrote: >> >> Hi everyone, >> >> I'm happy to announce astilectron, a GO library to build cross platform GUI >> apps in HTML/JS/CSS: https://github.com/asticode/go-astilectron >> >> I needed a way to build a cross platform GUI app in GO but none of the >> projects out there were meeting my needs (they were either only >> MacOSX-compatible or not maintained anymore). At the same time, I knew about >> Electron which is cross-platform and well maintained. So I did the maths and >> took a shot at creating a ligthweight library that could rely on Electron >> and be available in GO. >> >> I've started it this week-end so this is still in beta but in a nutshell, >> here's what it already does: >> >> - on start it provisions the necessary dependencies (electron and a custom >> electron app I've made in NodeJS that provides an API over TCP). This means >> that worst case scenario it downloads the distributions and unzips them. >> Best case scenario (and thanks to the possibility of setting your own >> Provisioner) you can embed the distributions in your binary using go-bindata >> and only unzip them if they're not already set up. >> - then you're good to go and can create windows and interact with them: >> move, resive, maximize, close, etc. >> - each window is a browser therefore you can either load static .html files, >> a remote URL or the local GO server you've just started :D >> - you can communicate between your GO app and the javascript in you server >> - did I mention this is cross-platform? :D >> >> Here's the architecture of the project: >> >> +-+TCP+-+IPC >> +-+ >> + your GO app |<->+ custom Electron app +<>+ win1: >> (HTML/JS/CSS) + >> +-+ +-+ | >> +-++ >> | | +>+ win2: >> (HTML/JS/CSS) + >> | +--+|| >> +-++ >> +-+ Electron +++-->+ win3: >> (HTML/JS/CSS) + >> +--+ >> +-+ >> >> I'd like to use this beta version to see if people are interested in that >> sort of project. If so, I'll dedicate more hours to add more features. Let >> me know in the comments section. >> >> Of course I welcome any kind of contributions, may it be finding bugs or >> proposing enhancements. >> >> Long live Golang! >> >> Cheers >> Asticode >> >> -- 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.
[go-nuts] Re: [ANN] astilectron - Build cross platform GUI apps with GO and Electron (HTML/JS/CSS)
Let me add one more project to the list: - https://github.com/therecipe/qt: like https://github.com/andlabs/ui it forces you to have a native look and it seems overly complicated to embed the QT library in the binary Le jeudi 27 avril 2017 14:12:31 UTC+2, Asticode a écrit : > > I do agree with you regarding the size of the app once everything is setup. > > Honestly chosing Electron is more a choice by default than anything else. > > imo the chosen project should: > > - be cross platform > - be well maintained > - allow creating non-native looks through HTML/JS/CSS since I think it's > the easiest for the most of us > > Here's a list of what I've tried so far: > > - https://github.com/andlabs/ui : drawbacks are it has limited features, > force you to have a native look and can't do things like capturing the > "Enter" key event in an input box > - https://github.com/miketheprogrammer/go-thrust : drawback is it's not > maintained anymore > - https://github.com/alexflint/gallium : drawback is it's not > cross-platform (only MacOSX last time I checked) > - https://github.com/murlokswarm/app : drawback is it's not > cross-platform (only MacOSX too) > - https://github.com/arvitaly/gopherjs-electron : drawback is it's not > maintained anymore > - https://github.com/rrohrer/go-electroncontrol : drawback is it's not > maintained anymore > - https://github.com/nodekit-io/nodekit : drawback is it's not maintained > anymore > > As you can see none of them meet the 3 requirements. > > Which leaves us with Electron which is cross platform, well maintained and > allow creating non-native looks through HTML/CSS/JS. > > If there are other projects I've missed, feel free to let me know, once > again chosing Electron is more of a choice by default than anything else. > > PS : if you're only interested in window positioning and decoration, and > don't care about dealing with HTML/CSS/JS I recommend using > https://github.com/andlabs/ui which is an awesome project! > > > Le jeudi 27 avril 2017 11:33:10 UTC+2, mhh...@gmail.com a écrit : >> >> I like it too, i'm only worried by the size of the app once everything it >> setup. >> >> I wonder if its not possible to have something smaller, >> obviously with less capabilities. >> >> imho, i m interested mostly in window positioning and decoration. >> Communication is less interesting to me as i can work with http apis, or >> so. >> >> any ideas ? >> >> On Tuesday, April 25, 2017 at 9:54:22 PM UTC+2, Asticode wrote: >>> >>> Hi everyone, >>> >>> I'm happy to announce astilectron, a GO library to build cross platform GUI >>> apps in HTML/JS/CSS: https://github.com/asticode/go-astilectron >>> >>> I needed a way to build a cross platform GUI app in GO but none of the >>> projects out there were meeting my needs (they were either only >>> MacOSX-compatible or not maintained anymore). At the same time, I knew >>> about Electron which is cross-platform and well maintained. So I did the >>> maths and took a shot at creating a ligthweight library that could rely on >>> Electron and be available in GO. >>> >>> I've started it this week-end so this is still in beta but in a nutshell, >>> here's what it already does: >>> >>> - on start it provisions the necessary dependencies (electron and a custom >>> electron app I've made in NodeJS that provides an API over TCP). This means >>> that worst case scenario it downloads the distributions and unzips them. >>> Best case scenario (and thanks to the possibility of setting your own >>> Provisioner) you can embed the distributions in your binary using >>> go-bindata and only unzip them if they're not already set up. >>> - then you're good to go and can create windows and interact with them: >>> move, resive, maximize, close, etc. >>> - each window is a browser therefore you can either load static .html >>> files, a remote URL or the local GO server you've just started :D >>> - you can communicate between your GO app and the javascript in you server >>> - did I mention this is cross-platform? :D >>> >>> Here's the architecture of the project: >>> >>> +-+TCP+-+IPC >>> +-+ >>> + your GO app |<->+ custom Electron app +<>+ win1: >>> (HTML/JS/CSS) + >>> +-+ +-+ | >>> +-++ >>> |
Re: [go-nuts] Re: [ANN] astilectron - Build cross platform GUI apps with GO and Electron (HTML/JS/CSS)
More often than not the obsessed creator will have the last say and will discard what the trained designer and results of the focus groups tests have to say unless they agree with him/her :D Hence the need for a more flexible solution. But you have a good point. However I still see at least 2 reasons why native looks could be a limit: - This me belief that more developers know what are their options when making some HTML/JS/CSS than when dealing with "native looks" (panels, comboboxes, etc.) since most developers come from a Web background. May it be good or bad is not the point here, but I do think that it's more intuitive and easier for developers to make a UI using HTML/JS/CSS than using native components. That's not true for everyone but I think that's true for the majority. For the ones that feel more comfortable without any HTML/JS/CSS then there are plenty of great options out there and once again I can't recommend enough https://github.com/andlabs/ui - Some simple stuff as simple as capturing the "Enter key was pressed in the input box" event somewhat can't be done using native libs such as https://github.com/andlabs/ui. In my case that was dealbreaker. Le samedi 29 avril 2017 16:17:52 UTC+2, Konstantin Khomoutov a écrit : > > On Sat, 29 Apr 2017 01:49:49 -0700 (PDT) > Asticode <asti...@gmail.com > wrote: > > > - https://github.com/therecipe/qt: like https://github.com/andlabs/ui > > it forces you to have a native look > [...] > > It may be just me, but actually a virtue of "having a native look" is > one of the best selling points of a cross-platform UI toolkits. > > Some developers appear to put much effort into "skinning" their apps > (old farts like me would remember how this plagued media players of the > nineties) completely fogretting about two points: > - Having a greatly-looking UI without the work of a trained designer > and testing it on focus groups is futile, and the end result is almost > always crappy (that is, to everyone except the obsessed creator). > - Most of the time users just do not give any special shi^Wcare about > your program -- instead considering it just a piece in their toolbox, > and quite often using it merely because it sucks less that its > alternatives, not because they love it in any special way. > And in this case, obviously, the principle of the least WTF for the > users is paramount: all the apps in their toolbox should look and > behave in the uniform way -- the way which is native to the user's > platform. > -- 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.
[go-nuts] Re: [ANN] astits: parse and demux MPEG Transport Streams (.ts) natively in GO
Hey guys, A user in Reddit asked a good question and I'm interested in the answer you may have. The question was "Has anyone looked at how this package compares to https://github.com/Comcast/gots?;. Initially I've used this package to parse MPEG transport streams, but I didn't really like the way it was built and above all its API. That's why I've decided to build go-astits. I'm really interested in any feedback you guys may have. Cheers Le lundi 20 novembre 2017 08:53:01 UTC+1, Asticode a écrit : > > Hey guys, > > I'm happy to announce go-astits, a Golang library to parse and demux MPEG > Transport Streams (.ts) natively: https://github.com/asticode/go-astits > > It allows you to either retrieve raw packets or event better retrieve > complex data spanning over multiple packets. > > Let me know what you think! > > Cheers > -- 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.
[go-nuts] [ANN] You can now manipulate .ass/.ssa subtitles alongside .srt, .ttml, .vtt, .stl, etc. in GO
Just to let you guys know I've added support for .ass/.ssa subtitles in go-astisub. <https://github.com/asticode/go-astisub> You can still manipulate .srt, .ttml, .vtt, .stl, etc. and do parsing, writing, syncing, fragmenting, unfragmenting and merging. Support for Teletext coming soon. -- 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.
[go-nuts] [ANN] astits: parse and demux MPEG Transport Streams (.ts) natively in GO
Hey guys, I'm happy to announce go-astits, a Golang library to parse and demux MPEG Transport Streams (.ts) natively: https://github.com/asticode/go-astits It allows you to either retrieve raw packets or event better retrieve complex data spanning over multiple packets. Let me know what you think! Cheers -- 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.
[go-nuts] How to add a GUI to your Golang app in 5 easy steps
Hey guys, I've just written a short article <https://medium.com/@social_57971/how-to-add-a-gui-to-your-golang-app-in-5-easy-steps-c25c99d4d8e0> on how to add a GUI to your Golang app using astilectron <https://github.com/asticode/go-astilectron> and I'm sharing it here: https://medium.com/@social_57971/how-to-add-a-gui-to-your-golang-app-in-5-easy-steps-c25c99d4d8e0. Let me know what you think :) Cheers -- 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.
[go-nuts] [ANN] astideepspeech: Golang bindings for Mozilla's DeepSpeech speech-to-text library
Hey guys, I'm happy to announce astideepspeech <https://github.com/asticode/go-astideepspeech>, Golang bindings for Mozilla's DeepSpeech speech-to-text library. Let me know what you think. Cheers -- 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.
[go-nuts] [ANN] Bob, a framework to create a distributed AI that can learn to understand your voice, speak back, interact with your mouse and keyboard, and anything else you want
Heys guys, I'm happy to announce Bob, a framework to create a distributed AI that can learn to understand your voice, speak back, interact with your mouse and keyboard, and anything else you want: https://github.com/asticode/go-astibob. Let me know what you think. Cheers -- 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.
[go-nuts] Re: [ANN] Bob, a framework to create a distributed AI that can learn to understand your voice, speak back, interact with your mouse and keyboard, and anything else you want
First off, cheers for the code review :)
>> Since type ability is not exported, why not embed sync.Mutex?
I agree.
>> What does o stand for?
I named this variable "isOn" first, but then I named the function to access
it the same way, therefore I had to find another name. I do agree "o"
sucks, I'll try to find another clearer way.
>> I’d say that comments like “// newAbility creates a new ability” are
unnecessary. The identifiers are documentation. There are many unnecessary
comments.
I agree.
>> For read-only methods like *ability.isOn() perhaps a sync.RWMutex may
make sense.
I agree.
>> type brain could have sync.Mutex and *astiws.Client embedded. type
brains, type dispatcher, type interfaces could have sync.Mutex embedded.
type server could have everything besides name embedded. type brainsServer
could have everything embedded. type clientsServer could have everything
besides stopFunc embedded. The sub-packages have more cases like this.
I agree even though I've never thought like this. For my own curiosity,
what gain do you see by embedding structs like this?
>> There are no tests.
I agree :(
>> The horizontal dependency of go-astibob/abilities to go-astibob/brain is
a red flag for me. Why not define the abilities in package astibob?
I can't see any reasons why not, therefore that may be a good idea.
>> I don’t understand the pkg directory, why not have these as regular
sub-packages?
I wanted to keep packages using CGO in a separate place since astibob,
astibrain and abilities use interfaces to interact with features. Having
one root folder for those packages was more convenient for me. But you may
be right.
>> In go-astibob/pkg/portaudio, robotgo, I’m not sure what an alternative
would be, but defining methods on a struct{} type seems unnecessary
compared to just having functions. Elsewhere I’ve suggested defining a
struct type with function fields instead. If this is to satisfy an
interface, perhaps there is another approach where the interface is
unnecessary.
This is to satisfy interfaces indeed. If you have an alternative solution,
I'd be happy to hear it.
>> The godoc is a reasonable size but there are a lot of types without any
functionality
What do you mean by that?
>> The README.md seems long, perhaps examples/demo could contain some of
that information.
Same, what do you mean by that?
Again, cheers for the code review :)
Le lundi 29 janvier 2018 17:39:27 UTC+1, matthe...@gmail.com a écrit :
>
> Hi Quentin, here’s a code review.
>
> Since type ability is not exported, why not embed sync.Mutex? What does o
> stand for?
>
> I’d say that comments like “// newAbility creates a new ability” are
> unnecessary. The identifiers are documentation. There are many unnecessary
> comments.
>
> For read-only methods like *ability.isOn() perhaps a sync.RWMutex may make
> sense.
>
> type brain could have sync.Mutex and *astiws.Client embedded. type brains,
> type dispatcher, type interfaces could have sync.Mutex embedded. type
> server could have everything besides name embedded. type brainsServer could
> have everything embedded. type clientsServer could have everything besides
> stopFunc embedded. The sub-packages have more cases like this.
>
> There are no tests.
>
> The horizontal dependency of go-astibob/abilities to go-astibob/brain is a
> red flag for me. Why not define the abilities in package astibob?
>
> To me the demo examples show a clean interface for interacting with the
> library.
>
> I don’t understand the pkg directory, why not have these as regular
> sub-packages?
>
> In go-astibob/pkg/portaudio, robotgo, I’m not sure what an alternative
> would be, but defining methods on a struct{} type seems unnecessary
> compared to just having functions. Elsewhere I’ve suggested defining a
> struct type with function fields instead. If this is to satisfy an
> interface, perhaps there is another approach where the interface is
> unnecessary.
>
> These are the most complex html templates I’ve seen, I may refer back to
> these sometime.
>
> The godoc is a reasonable size but there are a lot of types without any
> functionality. The README.md seems long, perhaps examples/demo could
> contain some of that information.
>
> Matt
>
> On Monday, January 29, 2018 at 2:13:24 AM UTC-6, Asticode wrote:
>>
>> Heys guys,
>>
>> I'm happy to announce Bob, a framework to create a distributed AI that
>> can learn to understand your voice, speak back, interact with your mouse
>> and keyboard, and anything else you want:
>> https://github.com/asticode/go-astibob.
>>
>> Let me know what you think.
>>
>> Cheers
>>
>
--
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.
[go-nuts] [ANN] Open source video encoder written in GO and based on ffmpeg C bindings
Hey guys, I'm happy to announce go-astiencoder, an open source video encoder written in GO and based on ffmpeg C bindings: https://github.com/asticode/go-astiencoder Its goal is to assemble the full audio/video encoding process in GO for people looking to: - understand how such a process work in detail - integrate their video encoder in a GO ecosystem - visualize their encoding workflow and statuses/stats of nodes in real time - communicate with their encoder through an HTTP API + websocket to tweak behaviours in real time - use native GO subtitle libraries like astisub - build their own video encoder and take control of its workflow Indeed resources to assemble such a thing in GO are scarce and I think the GO community could benefit from this project. Right now I've implemented basic examples of remux, thumbnail extraction and h264/aac encoding. I'm more than welcoming contributions. Cheers PS: the goal of this project is *NOT* to replace ffmpeg :D -- 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.
[go-nuts] [ANN] Open source video encoder written in GO and based on ffmpeg C bindings
Hey guys, I'm happy to announce go-astiencoder, an open source video encoder written in GO and based on ffmpeg C bindings. Its goal is to assemble the full audio/video encoding process in GO for people looking to: - understand how such a process work in detail - integrate their video encoder in a GO ecosystem - visualize their encoding workflow and statuses/stats of nodes in real time - communicate with their encoder through an HTTP API + websocket to tweak behaviours in real time - use native GO subtitle libraries like astisub - build their own video encoder and take control of its workflow Indeed resources to assemble such a thing in GO are scarce and I think the GO community could benefit from this project. Right now I've implemented basic examples of remux, thumbnail extraction and h264/aac encoding. I'm more than welcoming contributions. Cheers PS: the goal of this project is *NOT* to replace ffmpeg :D -- 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.
[go-nuts] [ANN] astiencoder: an open source video encoder written in GO and based on ffmpeg C bindings
Hey guys, I'm happy to announce go-astiencoder, an open source video encoder written in GO and based on ffmpeg C bindings: https://github.com/asticode/go-astiencoder Its goal is to assemble the full audio/video encoding process in GO for people looking to: - understand how such a process work in detail - integrate their video encoder in a GO ecosystem - visualize their encoding workflow and statuses/stats of nodes in real time - communicate with their encoder through an HTTP API + websocket to tweak behaviours in real time - use native GO subtitle libraries like astisub - build their own video encoder and take control of its workflow Indeed resources to assemble such a thing in GO are scarce and I think the GO community could benefit from this project. Right now I've implemented basic examples of remux, thumbnail extraction and h264/aac encoding. I'm more than welcoming contributions. Cheers PS: the goal of this project is *NOT* to replace ffmpeg :D -- 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.
Re: [go-nuts] [ANN] astiencoder: an open source video encoder written in GO and based on ffmpeg C bindings
Yeah sorry about the spam :( I forgot the link the first time and wanted to edit the title the second time. Didn't think there were notifications for every creation. Really sorry about that :( Le mardi 9 octobre 2018 10:47:33 UTC+2, Jan Mercl a écrit : > > On Tue, Oct 9, 2018 at 10:31 AM Asticode > > wrote: > > > I'm happy to announce go-astiencoder, an open source video encoder > written in GO and based on ffmpeg C bindings: > https://github.com/asticode/go-astiencoder > > Three separate announcements of the same thing in cca 20 minutes. > > -- > > -j > -- 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.
