If you're parsing the GIR, there's an "abstract" attribute for abstract classes.
If you're using the GIRepository API, you can use `g_object_info_get_abstract()` to know if a type is abstract. Ciao, Emmanuele. On 8 November 2017 at 16:40, Sam Jansen <sam.jan...@starleaf.com> wrote: > Perhaps you can check whether any methods are constructors? This is > effectively the information I look at when parsing GIR files for my TS > definitions... > > http://devdocs.baznga.org/girepository20~2.0_api/girepository.functioninfoflags#default-is_constructor > > On 8 November 2017 at 12:37, Andrea Giammarchi <andrea.giammar...@gmail.com> > wrote: >> >> the documentation doesn't say if I can instantiate those classes, or does >> it? >> >> if I could understand via GIRepository.Repository if a class could be >> extended/instantiated I could improve cgjs-about to show that right away. >> >> So far I thought that `objects` where all usable as `new Class` but that's >> not the case at all. Maybe I should check for an `is_abstract_object` ? >> >> Not sure there is anything like that though. >> >> Thanks. >> >> >> On Wed, Nov 8, 2017 at 3:41 AM, <philip.chime...@gmail.com> wrote: >>> >>> This comes a bit too late to help you, sorry, but the C docs will tell >>> you which classes extend a base class, e.g. for GInputStream >>> (Gio.InputStream in GJS): >>> https://developer.gnome.org/gio/stable/GInputStream.html#GInputStream.object-hierarchy >>> >>> On Tue, Nov 7, 2017 at 2:36 PM Andrea Giammarchi >>> <andrea.giammar...@gmail.com> wrote: >>>> >>>> so, just FYI ... >>>> >>>> Buffered, Converter, Data, File, Memory and Unix InputStream are >>>> available. >>>> >>>> Buffered, Converter, and Data need a base_stream to work ... not a >>>> primitive. >>>> >>>> File and Unix need attributes or fd pointers >>>> >>>> The Memory seems to be the "base/primitive" I was looking for together >>>> with its MemoryOutputStream counterpart. >>>> >>>> Regards >>>> >>>> >>>> >>>> On Tue, Nov 7, 2017 at 7:28 PM, Andrea Giammarchi >>>> <andrea.giammar...@gmail.com> wrote: >>>>> >>>>> oh gosh, my own utility ... that is less useful in pretty print for >>>>> these kind of things .... although the list has many non-usable streams >>>>> but >>>>> now I want to know which one is usable. >>>>> >>>>> P.S. for namespaces you don't' need gi prefix ... cgjs-about Gio would >>>>> do the same ;-) >>>>> >>>>> Thanks again >>>>> >>>>> On Tue, Nov 7, 2017 at 7:09 PM, Sam Jansen <sam.jan...@starleaf.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 7 November 2017 at 21:55, Andrea Giammarchi >>>>>> <andrea.giammar...@gmail.com> wrote: >>>>>>> >>>>>>> this is gold, thank you!!! >>>>>>> >>>>>>> do you know if MemoryInputStream is the only one usable? is there any >>>>>>> list of available GJS streams one can use? I think memory is just fine >>>>>>> though, thanks again a lot! >>>>>>> >>>>>> >>>>>> I just took an educated guess: I figured anything useful would extend >>>>>> Gio.InputStream. I then just browsed through the docs, looking for >>>>>> anything >>>>>> with "InputStream" in their name, which isn't so many... >>>>>> >>>>>> This is a good place to start perhaps: >>>>>> >>>>>> $ cgjs-about gi.Gio --json | grep InputStream | grep -Ev >>>>>> "Class|Private" >>>>>> >>>>>> >>>>>> It would be a neat extension to cgjs-about if one could have it list >>>>>> the classes known to implement an interface or extend from a class... >>>>>> >>>>>>> >>>>>>> On Tue, Nov 7, 2017 at 6:46 PM, Sam Jansen <sam.jan...@starleaf.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Andrea, >>>>>>>> >>>>>>>> I've come up with something that... almost does what you're looking >>>>>>>> at here. Perhaps it's useful as a guide of what one can do with the Gio >>>>>>>> interface. >>>>>>>> >>>>>>>> I think you may hit some awkward problems with modelling Node-style >>>>>>>> streams with GLib ones. But perhaps it is possible and this helps. I >>>>>>>> don't >>>>>>>> really know the Node stream semantics so I have assumed various things >>>>>>>> in my >>>>>>>> Readable implementation as you'll see... Note that MemoryInputStream >>>>>>>> really >>>>>>>> is just a byte stream; so there is no guarantee you'll receive the >>>>>>>> exact >>>>>>>> block of bytes that was written -- for example, when I run this I get a >>>>>>>> first chunk of "12", followed by "3", "4", etc. >>>>>>>> >>>>>>>> >>>>>>>> let Gio = imports.gi.Gio; >>>>>>>> let byteArray = imports.byteArray; >>>>>>>> let mainloop = imports.mainloop; >>>>>>>> >>>>>>>> class Readable { >>>>>>>> constructor() { >>>>>>>> this._mio = Gio.MemoryInputStream.new(); >>>>>>>> this._callbacks = {}; >>>>>>>> this._startNext(); >>>>>>>> } >>>>>>>> >>>>>>>> _startNext() { >>>>>>>> // Enqueue an async read; and re-enqueue when it finishes, so >>>>>>>> we're >>>>>>>> // always waiting for data... >>>>>>>> this._mio.read_bytes_async(4096, 1, null, (source, res) => { >>>>>>>> this._onData(this._mio.read_bytes_finish(res)); >>>>>>>> this._startNext(); >>>>>>>> }); >>>>>>>> } >>>>>>>> >>>>>>>> _onData(bytes) { >>>>>>>> if (this._callbacks['data']) { >>>>>>>> let ba = byteArray.fromGBytes(bytes); >>>>>>>> this._callbacks['data'](ba); >>>>>>>> this._read(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> push(bytes) { >>>>>>>> if (bytes == null) { >>>>>>>> mainloop.quit('main'); >>>>>>>> return; >>>>>>>> } >>>>>>>> this._mio.add_bytes(bytes); >>>>>>>> } >>>>>>>> >>>>>>>> on(name, callback) { >>>>>>>> this._callbacks[name] = callback; >>>>>>>> if (name === 'data') { >>>>>>>> this._read(); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> class Counter extends Readable { >>>>>>>> constructor(opt) { >>>>>>>> super(opt); >>>>>>>> this._max = 1000; >>>>>>>> this._index = 1; >>>>>>>> } >>>>>>>> >>>>>>>> _read() { >>>>>>>> const i = this._index++; >>>>>>>> if (i > this._max) >>>>>>>> this.push(null); >>>>>>>> else { >>>>>>>> const str = '' + i; >>>>>>>> const buf = byteArray.fromString(str); // Buffer.from(str, >>>>>>>> 'ascii'); >>>>>>>> this.push(buf); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> (new Counter).on('data', (str) => { >>>>>>>> print("data", str.toString()); >>>>>>>> }); >>>>>>>> >>>>>>>> mainloop.run('main'); >>>>>>>> >>>>>>>> >>>>>>>> On 7 November 2017 at 10:08, Andrea Giammarchi >>>>>>>> <andrea.giammar...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> I am trying to implement a stream module and apparently I have >>>>>>>>> everything I need but practically I'm unable to use streams. >>>>>>>>> >>>>>>>>> If I instantiate a `new Gio.InputStream` I have the following >>>>>>>>> error: >>>>>>>>> cannot create instance of abstract (non-instantiatable) type >>>>>>>>> 'GInputStream' >>>>>>>>> >>>>>>>>> I cannot even extend it ... so I've though "ok, maybe it's like an >>>>>>>>> interface, I implement it and that's it" >>>>>>>>> >>>>>>>>> But then a JS class wouldn't work as base_stream for a >>>>>>>>> Gio.BufferedInputStream, and if I extend the JS class to be a >>>>>>>>> GObject.Object >>>>>>>>> then: >>>>>>>>> Gjs-WARNING **: JS ERROR: TypeError: Object is of type >>>>>>>>> GObject.Object - cannot convert to GInputStream >>>>>>>>> >>>>>>>>> where GInputStream is the one I cannot use in the first place. >>>>>>>>> >>>>>>>>> I've reached full circle then so ... I wonder if anyone has any >>>>>>>>> idea how to use/create/extend streams in GJS (not talking about file >>>>>>>>> streams >>>>>>>>> but streams in general) or if it's even possible. >>>>>>>>> >>>>>>>>> In node, as example, I could do this and it will work: >>>>>>>>> >>>>>>>>> ```js >>>>>>>>> >>>>>>>>> const { Readable } = require('stream'); >>>>>>>>> >>>>>>>>> class Counter extends Readable { >>>>>>>>> constructor(opt) { >>>>>>>>> super(opt); >>>>>>>>> this._max = 1000; >>>>>>>>> this._index = 1; >>>>>>>>> } >>>>>>>>> >>>>>>>>> _read() { >>>>>>>>> const i = this._index++; >>>>>>>>> if (i > this._max) >>>>>>>>> this.push(null); >>>>>>>>> else { >>>>>>>>> const str = '' + i; >>>>>>>>> const buf = Buffer.from(str, 'ascii'); >>>>>>>>> this.push(buf); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> (new Counter).on('data', console.log); >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> javascript-list mailing list >>>>>>>>> javascript-list@gnome.org >>>>>>>>> https://mail.gnome.org/mailman/listinfo/javascript-list >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> javascript-list mailing list >>>> javascript-list@gnome.org >>>> https://mail.gnome.org/mailman/listinfo/javascript-list >> >> > > > _______________________________________________ > javascript-list mailing list > javascript-list@gnome.org > https://mail.gnome.org/mailman/listinfo/javascript-list > -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
