Aw! I was hoping for an endless stream of Global Starcraft League :(
GSL – a Universal Code Generator
11–20 of 30 posts
Re: GSL – a Universal Code Generator
#12[deleted]
Re: GSL – a Universal Code Generator
#13There is more to GSL than XML processing. GSL was used to write ZeroMQ along with many other pieces of software. GSL can also be used to write FSM (finite state machines) and an earlier variant called Libero, was used to write the very well regarded, Xitami multithreaded web server. I just installed it yesterday so haven't been able to fully suss out how I will use it. Hintjens also wrote the CLASS style guide/ subse…
The ZeroMQ core library does not use gsl. We use it in two projects, zproto and zproject, which are nice examples of what is possible without going too meta. I started explaining zproject in my [Scalable C](http://Scalablec.org) book.
Re: GSL – a Universal Code Generator
#14That readme is a massive intro that doesn't explain very much at all. tldr; Define a model in xml, and a provide it a template script and it'll output some text. Sound like XSLT? yep. With a custom DSL taped on the side for scripting. Also... Template-driven code generators that use symbolic insertion to inject meta- data into a template. This technology makes it much easier to write new ad-hoc templates. Typical exa…
Look, this can be hard to grasp. In zproject we write models of our library APIs. From these we get stuff as exotic as bindings in Java, python, Ruby, node, and all scripts to build them.
Re: GSL – a Universal Code Generator
#15That readme is a massive intro that doesn't explain very much at all. tldr; Define a model in xml, and a provide it a template script and it'll output some text. Sound like XSLT? yep. With a custom DSL taped on the side for scripting. Also... Template-driven code generators that use symbolic insertion to inject meta- data into a template. This technology makes it much easier to write new ad-hoc templates. Typical exa…
"I'm not sure why you'd bother over an existing solution like protocol buffers."
For context, protocol buffers did not exist when GSL was devised in 1995 (3 years before google was founded). So in fact GSL _was_ the existing solution when google came up with protocol buffers.
Given GSL is still going strong 21 years after inception is a pretty solid testament to its utility.
Re: GSL – a Universal Code Generator
#16That readme is a massive intro that doesn't explain very much at all. tldr; Define a model in xml, and a provide it a template script and it'll output some text. Sound like XSLT? yep. With a custom DSL taped on the side for scripting. Also... Template-driven code generators that use symbolic insertion to inject meta- data into a template. This technology makes it much easier to write new ad-hoc templates. Typical exa…
Look, this can be hard to grasp. In zproject we write models of our library APIs. From these we get stuff as exotic as bindings in Java, python, Ruby, node, and all scripts to build them.
How does the system automatically manage differences between various languages when binding?
Re: GSL – a Universal Code Generator
#17Earlier quoted context omitted.
Look, this can be hard to grasp. In zproject we write models of our library APIs. From these we get stuff as exotic as bindings in Java, python, Ruby, node, and all scripts to build them.
How does the system automatically manage differences between various languages when binding?
Thats really the key question here.
As I understand it, you do it by hand.
Re: GSL – a Universal Code Generator
#18That readme is a massive intro that doesn't explain very much at all. tldr; Define a model in xml, and a provide it a template script and it'll output some text. Sound like XSLT? yep. With a custom DSL taped on the side for scripting. Also... Template-driven code generators that use symbolic insertion to inject meta- data into a template. This technology makes it much easier to write new ad-hoc templates. Typical exa…
"I'm not sure why you'd bother over an existing solution like protocol buffers." For context, protocol buffers did not exist when GSL was devised in 1995 (3 years before google was founded). So in fact GSL _was_ the existing solution when google came up with protocol buffers. Given GSL is still going strong 21 years after inception is a pretty solid testament to its utility.
They exist now.
No one is denying this is a tool, a useful one at that... Im just not sure why you use it now, given the alternatives that do now exist.
Re: GSL – a Universal Code Generator
#19Earlier quoted context omitted.
Look, this can be hard to grasp. In zproject we write models of our library APIs. From these we get stuff as exotic as bindings in Java, python, Ruby, node, and all scripts to build them.
How does the system automatically manage differences between various languages when binding?
You write your own backends. These can be trivial to very comolex. See zproto or zproject for examples.
Re: GSL – a Universal Code Generator
#20That readme is a massive intro that doesn't explain very much at all. tldr; Define a model in xml, and a provide it a template script and it'll output some text. Sound like XSLT? yep. With a custom DSL taped on the side for scripting. Also... Template-driven code generators that use symbolic insertion to inject meta- data into a template. This technology makes it much easier to write new ad-hoc templates. Typical exa…
"I'm not sure why you'd bother over an existing solution like protocol buffers." For context, protocol buffers did not exist when GSL was devised in 1995 (3 years before google was founded). So in fact GSL _was_ the existing solution when google came up with protocol buffers. Given GSL is still going strong 21 years after inception is a pretty solid testament to its utility.
protobufs generates code for one model. GSL lets you build infinite generators for infinite models. Its like comparing an apple with a fruit farm.