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 )
About the documentation, I am still not sure how to generate all other folders shown here: 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) 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) 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 (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] > > 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) >> 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
