FYI, since I've mentioned I would have written something about GJS, here my first contribution: https://www.webreflection.co.uk/blog/2015/12/08/writing-native-apps-with-javascript
Best Regards On Tue, Dec 8, 2015 at 10:28 AM, Andrea Giammarchi < [email protected]> wrote: > Wow, I will stick with node.js like API but there are many things to learn > for me in that code (and something for me to fix) ... thanks! > > On Tue, Dec 8, 2015 at 10:15 AM, Alan Knowles <[email protected]> wrote: > >> ah sorry, should have given you the public version... >> >> >> http://git.roojs.org/?p=gitlive;a=blob;f=Spawn.js;h=4d9f202373cb111b47cb3c2eac0db4de405e0deb;hb=HEAD >> >> Sorry, can't help on the gjs-documentation, >> >> Regards >> Alan >> >> >> On Tuesday, December 08, 2015 06:06 PM, Andrea Giammarchi wrote: >> >> Hi Alan, >> I can't check your last link ( requires login ) but I'm using >> `GLib.spawn_async_with_pipes` creating stdin/out/err channels via >> `GLib.IOChannel.unix_new`, creating either readable or writable sources via >> `GLib.io_add_watch` and replicating through "Streams" the exact same API >> nodejs has, which is events based and to me more familiar ( >> <https://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options> >> https://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options >> ) >> >> About the documentation, I am still not sure how to generate all other >> folders shown here: <https://people.gnome.org/%7Egcampagna/docs/> >> https://people.gnome.org/~gcampagna/docs/ >> >> Using the official gjs-documentation repository, the `make` there works >> only for the content in the static folder which is a list of .page file per >> each sub-folder (GLib-2.0, GObject-2.0, Gio-2.0). How can I obtain a >> similar structure for the `generated` sub-folder? >> >> This is the repository with current documentation that works only for >> those 3 static folders: >> https://github.com/GNOME/gjs-documentation >> >> I don't care much about the output, I care about having same file >> structures with same naming convention used in those 3 static folders >> (.page files) so that I can parse that folder and retrieve all known info >> at runtime via JS itself. >> >> Regards >> >> >> >> >> >> On Tue, Dec 8, 2015 at 9:26 AM, Alan Knowles <[email protected]> wrote: >> >>> Hi, >>> most of this code parsers the introspection data, >>> https://git.gnome.org/browse/introspection-doc-generator/tree/Introspect >>> >>> it's used to generate the documentation here (it's getting quite old >>> though now) >>> http://www.roojs.com/seed/gir-1.2-gtk-3.0/gjs/WebKit.html >>> >>> The seed documentation is slightly better than gjs (as that is what I >>> used first) - from what i remember it does not document return values that >>> well for gjs. >>> >>> If you are spawning... - I did wrap that up at one point here >>> >>> http://git.roojs.com/?p=gitlive;a=blob;f=Spawn.js;h=4d9f202373cb111b47cb3c2eac0db4de405e0deb;hb=HEAD >>> >>> Gives out quite a few features like tracking the io, backgrounding etc... >>> >>> I'm not sure if the gir modifications in that file are relivant - I've >>> actually ported most of my seed code to vala now. >>> >>> Regards >>> Alan >>> >>> >>> >>> >>> On Tuesday, December 08, 2015 05:17 PM, Andrea Giammarchi wrote: >>> >>> Now that's what I call a welcome email, full of info: Thank You!!! >>> >>> I'd love to know more about Jasper St. Pierre idea. I'm playing with an >>> experimental distro (on github, if interested I'll drop a link) based on >>> ArchLinux that bootstraps into Weston on Wayland backend and GTK3 (GJS >>> based) in 8 seconds, on a Raspberry PI, and it also launches node.js so the >>> stack is 100% JavaScript (who would have bet years ago?!) >>> >>> About the documentation, I don't actually parse it: I just read all file >>> names ( >>> <https://github.com/WebReflection/jsgtk/blob/master/python-to.js> >>> https://github.com/WebReflection/jsgtk/blob/master/python-to.js) and >>> based on these I create the file that will optionally make the API camel >>> case. >>> As far as I have used JavaScript (15+ years at this point) in both Web >>> or Rhino/Nashorn/node/Server projects, methods and properties have always >>> been camelCase. >>> >>> I found it convenient to have it like it is now (I guess simpler to >>> document and "Google | grep" with its PyGTK counterpart) but I'm used too >>> much to camelCase and having a lightweight opt-in that does not compromise >>> internals seemed like a good choice to me. >>> >>> However, I'd like to generate Gtk and WebKit namespace too (or all >>> others different from GObject, GLib, and Gio in this link >>> <https://people.gnome.org/%7Egcampagna/docs/> >>> https://people.gnome.org/~gcampagna/docs/ which is mentioned in this >>> page <https://wiki.gnome.org/Projects/Gjs/Documentation> >>> https://wiki.gnome.org/Projects/Gjs/Documentation) for both reading >>> files and also to document myself locally instead of bothering some GNOME >>> or Github server ;-) >>> >>> Would this procedure via Ruby you've mentioned make it possible to have >>> all those files generated as well? Right now as soon as I make it stops >>> after static folder is parsed with anything in the generated list. >>> >>> >>> About node.js >>> >>> For me it wasn't a love or hate story on its API, it's rather the entry >>> point to npm. >>> As example, now that I have a working `require` function instead of >>> needing to re-polyfill again Promises for js24, I can simply do this: >>> >>> ```js >>> const Promise = require('es6-promise').Promise; >>> new Promise(function (res, rej) { >>> setTimeout(res, 500, 'it worked!'); >>> }).then(log); >>> ``` >>> That just worked via jsgtk. And please note jsgtk is not just a couple >>> of helpers, core functionalities ( >>> <https://github.com/WebReflection/jsgtk/tree/master/jsgtk> >>> https://github.com/WebReflection/jsgtk/tree/master/jsgtk) make it >>> already compatible with a wide range of modules. >>> >>> For instance, my last push from yesterday introduced Readable and >>> Writable streams so that I can now communicate asynchronously within >>> separate channels via spawn and, let's say, sqlite3 (or module based on >>> this such dblite in npm, which now works too) >>> >>> ```js >>> let sqlite3 = require('child_process').spawn('sqlite3'); >>> sqlite3.stdin.write('SELECT 123;\n'); >>> sqlite3.stdout.on('data', (data) => { >>> log(data); >>> sqlite3.disconnect(); >>> }); >>> ``` >>> Thanks to this simplified spawn, where I couldn't find documentation, I >>> could workaround interacting directly with nodejs like I've done for the os >>> module: <https://github.com/WebReflection/jsgtk/blob/master/jsgtk/os.js> >>> https://github.com/WebReflection/jsgtk/blob/master/jsgtk/os.js (I had >>> hard time finding out how to retrieve valid network interfaces and their >>> info via GJS) >>> >>> Not ideal, but it works. jsgtk is also far away from perfect or complete >>> ... but it kinda works already. >>> >>> As final point about node.js, its documentation is superior for the >>> simple reason that every module, constructor, or event, is described with >>> examples too while the best documentation I could find about GJS and its >>> most basic functionalities is in Japanese (I guess) >>> http://foreachsam.github.io/book-lang-javascript-gjs/book/index.html >>> >>> I'm willing to help improving GJS documentation, least through my blog, >>> but regarding `jsgtk` ... well, contributors are **more** than welcome >>> so please have a look if you're interested and ping me whenever you want. >>> >>> >>> Best Regards >>> >>> >>> >>> >>> >>> On Tue, Dec 8, 2015 at 6:02 AM, Philip Chimento < >>> <[email protected]>[email protected]> wrote: >>> >>>> On Mon, Dec 7, 2015 at 1:26 AM, Andrea Giammarchi < >>>> <[email protected]>[email protected]> wrote: >>>> >>>>> First of all, I'd like to say hello to everyone. I've been using GNOME >>>>> on ArchLinux for more than a year now and I love pretty much everything >>>>> about it. >>>>> Recently I've found GJS project and I've started playing with it >>>>> making it more "JSish" than "Pythonic" and implementing partially some >>>>> node.js core API and functionalities such require, fs, path, os, with some >>>>> synchronous and asynchhronous API too. >>>>> >>>> >>>> Hello, welcome. >>>> >>>> You might want to check in with Jasper St. Pierre (Jasper on IRC), he >>>> has been interested in bootstrapping the Gnome stack onto Node.js. >>>> >>>> >>>>> So far, so good ... however, there are 2 main questions I'd like to >>>>> ask about GJS: >>>>> >>>>> 1. is this project still alive? It works like a charm but >>>>> repositories look untouched for long time >>>>> >>>> >>>> Yes, there was a 1.44.0 release just last month. It's not the most >>>> active GNOME project though. >>>> >>>> >>>>> 2. is it posible to know how to generate the Giovanni's >>>>> documentation? I've talked with him directly and apprently he's not >>>>> working >>>>> on that branch anymore but beside static assets that are present in such >>>>> branch, all generated content fails to build (tried in ArchLinux, Ubuntu) >>>>> and I've no idea what I should do in order to generate the documentation >>>>> for Gtk-3.0 or Gdk and others that are not Gio, GObject, and GLib. >>>>> >>>>> The result of the parsing of such documentation gives me the ability >>>>> to create files like the following one: >>>>> <https://github.com/WebReflection/jsgtk/blob/master/jsgtk/gi.js> >>>>> https://github.com/WebReflection/jsgtk/blob/master/jsgtk/gi.js >>>>> >>>>> Since the Proxy implemented in js24 seems to fail if used directly as >>>>> Gtk instance, that's the way to tarnsform all accessors and methods from >>>>> lower_case to camelCase but this is only one part of the project, the rest >>>>> will be at some point documented as long as I understand it's worth keep >>>>> improving it. >>>>> >>>> >>>> I would strongly recommend that you not parse the documentation but >>>> instead parse the GIR files directly. >>>> >>>> Even better would be, in my opinion, to write some code on the C side >>>> of things to handle both underscored and camelcased methods. Here's where >>>> it's done for GObject property names: >>>> <https://git.gnome.org/browse/gjs/tree/gi/object.cpp#n282> >>>> https://git.gnome.org/browse/gjs/tree/gi/object.cpp#n282 >>>> >>>> (I suspect a change like this would be controversial, though; I'm not >>>> sure of the reason why it was originally done for GObject properties and >>>> not methods, but hardly any existing GJS code that I've seen takes >>>> advantage of camelcased properties.) >>>> >>>> Coincidentally I've been working off and on, on getting the GJS >>>> documentation into a local instance of devdocs.io. If you want to try >>>> it out, build this branch of gobject-introspection ( >>>> <https://github.com/ptomato/gobject-introspection/tree/wip/ptomato/devdocs> >>>> https://github.com/ptomato/gobject-introspection/tree/wip/ptomato/devdocs) >>>> and check out this branch of devdocs ( >>>> <https://github.com/ptomato/devdocs/tree/gir-redux> >>>> https://github.com/ptomato/devdocs/tree/gir-redux). In your Ruby >>>> environment run "thor gir:generate_all" then "thor gir:generate gio >>>> --force" (repeat the last one for whichever GIR documentation you want to >>>> generate), then "rackup" to start the webapp. >>>> >>>> >>>>> Right now the quick demo I can provide is that if you `npm install >>>>> jsgtk` in a folder that contains a `node_modules` directory and you create >>>>> a `hello-world` like the following >>>>> >>>>> ``` >>>>> #!/usr/bin/env sh >>>>> imports=imports// "exec" "gjs" "-I" "$(dirname >>>>> $0)/node_modules/jsgtk/" "$0" "$@" >>>>> >>>>> let {console} = imports.jsgtk; >>>>> console.info('Hello jsgtk!'); >>>>> ``` >>>>> >>>>> and you `chmod +x hello-world` and run it or simply `sh hello-world` >>>>> you should see the message in console. >>>>> >>>>> Thanks for any sort of info or comment or clarification. >>>>> >>>> >>>> Personally I'm not a fan of Node.js's API, rather see something with >>>> promises than more callback hell, but it would indeed be nice to have some >>>> sort of standard module that lowers the barrier of entry for people new to >>>> Gnome who are used to web development. But that's my opinion and I'm not a >>>> GJS maintainer, just a heavy user. >>>> >>>> Satyajit Sahoo who I think reads this list, also has something similar: >>>> <https://github.com/satya164/gjs-helpers> >>>> https://github.com/satya164/gjs-helpers >>>> >>>> Regards, >>>> -- >>>> Philip >>>> >>> >>> >>> >>> _______________________________________________ >>> javascript-list mailing >>> [email protected]https://mail.gnome.org/mailman/listinfo/javascript-list >>> >>> >>> >> >> >
_______________________________________________ javascript-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/javascript-list
