February 2018 - Pharo-users

Re: [Pharo-users] UFFI correct way to cast void*

by Ben Coman

On 18 February 2018 at 01:46, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 17 Feb 2018, at 02:50, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On 16 February 2018 at 16:38, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> hi, >> >> âcastingâ is not necessary in general since is just a way to tell the C >> compiler that a pointer is form a certain type (but is always a pointer, >> and in machine code is always the same). >> >> So, here you will do something like this: >> >> Iterator >> asCollectionOfType: aTypeName >> | result address typeClass | >> >> result := OrderedCollection new. >> address := ExternalAddress new. >> typeClass := FFIExternalType resolveType: aTypeName. >> [self iterator_next: address] >> whileTrue: [ result add: (typeClass fromHandle: address) >> ]. >> > > Perhaps this is a bit about discover-ability. People with C experience > may > naturally search for "cast". If I Spotter search for..... cast #i > it turns up only four... "broadcast" under Socket class > > If that was instead like... (typeClass castFromHandle: address) > then people may be more likely to find it themselves. > > > I was thinking to implement the #castTo: for all the âpointerâ classes > (ByteArray, FFIExternalReference, FFIExternalStructure). > > #[42 0 0 0] castTo: FFIInt32 -> 42 > > what do you think? > That will be useful, and intuitive for people to find. cheers -ben > > Esteban > > > > cheers -ben > > > > >> ^result >> >> Iterator >> iterator_next: data >> ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** >> data)) >> >> nowâ¦ you have a problem if your type if your type is an âatomicâ type, >> like int, long, etc. because those values are passed âby valueâ and not by >> pointer, so you will need to decode them. >> in this case, I would implement a method extension (probably it worths >> to add it to UFFI): >> >> FFIExternalType class >> valueFromHandle: anAddress >> ^ self new handle: anAddress at: 1 âThis is used for structures, >> but we can reuse them :)" >> >> FFIExternalReference class >> valueFromHandle: anAddress >> ^ self fromHandle: anAddress >> >> FFIExternalStructure class >> valueFromHandle: anAddress >> ^ self fromHandle: anAddress >> >> So your function will be like something like this: >> >> Iterator >> asCollectionOfType: aTypeName >> | result address typeClass | >> >> result := OrderedCollection new. >> address := ExternalAddress new. >> typeClass := FFIExternalType resolveType: aTypeName. >> [self iterator_next: address] >> whileTrue: [ result add: (typeClass valueFromHandle:: >> address) ]. >> ^result >> >> and voilÃ , you have your cast :) >> >> Esteban >> >> ps: (some errors can be found here, since Iâm âprogramming at mail >> clientâ, but you get the idea ;) ) >> >> > On 15 Feb 2018, at 19:59, Egor Scorik <shirofaii(a)gmail.com> wrote: >> > >> > Hi, >> > >> > I'm trying to play with new UFFI system. It looks much easier then >> > NativeBoost, but unfortunately its hard to find any docs or examples. >> > I have problem with casting void* (ExternalAddress) into smalltalk >> object if >> > there is no hardcoded type in ffi method. And I really dislike the idea >> of >> > making many ffi methods, one for each required type. >> > In this example i can't understand how to make something like `address >> > castTo: type` >> > >> > FFIExternalObject subclass: #Iterator >> > >> > Iterator >> asCollectionOfType: aTypeName >> > | result address type | >> > >> > result := OrderedCollection new. >> > address := ExternalAddress new. >> > type := FFIExternalType resolveType: aTypeName. >> > [self iterator_next: address] whileTrue: [ >> > result add: (address castTo: type). >> > ]. >> > ^result >> > >> > Iterator >> iterator_next: data >> > ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** >> data)) >> > >> > >> > >> > >> > -- >> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >> >> >> > >

Feb. 17, 2018

Re: [Pharo-users] UFFI correct way to cast void*

by Egor Scorik

Thanks! #valueFromHandle: exactly what I looking for! I also add method for strings to make them working FFIExternalString >> valueFromHandle: anAddress | data | data := ExternalData fromHandle: anAddress type: ExternalType string. data isNull ifTrue: [ ^ nil ]. ^ data fromCString -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 17, 2018

Re: [Pharo-users] UFFI correct way to cast void*

by Esteban Lorenzano

> On 17 Feb 2018, at 02:50, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On 16 February 2018 at 16:38, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > hi, > > âcastingâ is not necessary in general since is just a way to tell the C compiler that a pointer is form a certain type (but is always a pointer, and in machine code is always the same). > > So, here you will do something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass fromHandle: address) ]. > > Perhaps this is a bit about discover-ability. People with C experience may > naturally search for "cast". If I Spotter search for..... cast #i > it turns up only four... "broadcast" under Socket class > > If that was instead like... (typeClass castFromHandle: address) > then people may be more likely to find it themselves. I was thinking to implement the #castTo: for all the âpointerâ classes (ByteArray, FFIExternalReference, FFIExternalStructure). #[42 0 0 0] castTo: FFIInt32 -> 42 what do you think? Esteban > > cheers -ben > > > > ^result > > Iterator >> iterator_next: data > ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** data)) > > nowâ¦ you have a problem if your type if your type is an âatomicâ type, like int, long, etc. because those values are passed âby valueâ and not by pointer, so you will need to decode them. > in this case, I would implement a method extension (probably it worths to add it to UFFI): > > FFIExternalType class >> valueFromHandle: anAddress > ^ self new handle: anAddress at: 1 âThis is used for structures, but we can reuse them :)" > > FFIExternalReference class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > FFIExternalStructure class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > So your function will be like something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass valueFromHandle:: address) ]. > ^result > > and voilÃ , you have your cast :) > > Esteban > > ps: (some errors can be found here, since Iâm âprogramming at mail clientâ, but you get the idea ;) ) > > > On 15 Feb 2018, at 19:59, Egor Scorik <shirofaii(a)gmail.com <mailto:shirofaii@gmail.com>> wrote: > > > > Hi, > > > > I'm trying to play with new UFFI system. It looks much easier then > > NativeBoost, but unfortunately its hard to find any docs or examples. > > I have problem with casting void* (ExternalAddress) into smalltalk object if > > there is no hardcoded type in ffi method. And I really dislike the idea of > > making many ffi methods, one for each required type. > > In this example i can't understand how to make something like `address > > castTo: type` > > > > FFIExternalObject subclass: #Iterator > > > > Iterator >> asCollectionOfType: aTypeName > > | result address type | > > > > result := OrderedCollection new. > > address := ExternalAddress new. > > type := FFIExternalType resolveType: aTypeName. > > [self iterator_next: address] whileTrue: [ > > result add: (address castTo: type). > > ]. > > ^result > > > > Iterator >> iterator_next: data > > ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** data)) > > > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> > > > > >

Feb. 17, 2018

Re: [Pharo-users] UFFI correct way to cast void*

by Stephane Ducasse

Hi esteban do you plan to add this explanation to the documentation of uFFI? Stef On Fri, Feb 16, 2018 at 9:38 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > hi, > > âcastingâ is not necessary in general since is just a way to tell the C compiler that a pointer is form a certain type (but is always a pointer, and in machine code is always the same). > > So, here you will do something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass fromHandle: address) ]. > ^result > > Iterator >> iterator_next: data > ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** data)) > > nowâ¦ you have a problem if your type if your type is an âatomicâ type, like int, long, etc. because those values are passed âby valueâ and not by pointer, so you will need to decode them. > in this case, I would implement a method extension (probably it worths to add it to UFFI): > > FFIExternalType class >> valueFromHandle: anAddress > ^ self new handle: anAddress at: 1 âThis is used for structures, but we can reuse them :)" > > FFIExternalReference class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > FFIExternalStructure class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > So your function will be like something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass valueFromHandle:: address) ]. > ^result > > and voilÃ , you have your cast :) > > Esteban > > ps: (some errors can be found here, since Iâm âprogramming at mail clientâ, but you get the idea ;) ) > >> On 15 Feb 2018, at 19:59, Egor Scorik <shirofaii(a)gmail.com> wrote: >> >> Hi, >> >> I'm trying to play with new UFFI system. It looks much easier then >> NativeBoost, but unfortunately its hard to find any docs or examples. >> I have problem with casting void* (ExternalAddress) into smalltalk object if >> there is no hardcoded type in ffi method. And I really dislike the idea of >> making many ffi methods, one for each required type. >> In this example i can't understand how to make something like `address >> castTo: type` >> >> FFIExternalObject subclass: #Iterator >> >> Iterator >> asCollectionOfType: aTypeName >> | result address type | >> >> result := OrderedCollection new. >> address := ExternalAddress new. >> type := FFIExternalType resolveType: aTypeName. >> [self iterator_next: address] whileTrue: [ >> result add: (address castTo: type). >> ]. >> ^result >> >> Iterator >> iterator_next: data >> ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** data)) >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >

Feb. 17, 2018

Re: [Pharo-users] UFFI correct way to cast void*

by Stephane Ducasse

On Fri, Feb 16, 2018 at 9:07 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>but unfortunately its hard to find any docs or examples. > > PDF Docu: https://github.com/SquareBracketAssociates/Booklet-uFFI > > (this should be added to http://books.pharo.org) It will be added when it will be completed. And since this is not me that will do it because I cannot then I wait. May be one day someone with enough knowledge will consider that FFI is important enough to document it seriously. Stef > > Examples: load OSWindows, OSLinuxUbuntu, ... or GlorpSQlite from catalog > They all use UFFI. >

Feb. 17, 2018

Re: [Pharo-users] UFFI correct way to cast void*

by Ben Coman

On 16 February 2018 at 16:38, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > hi, > > âcastingâ is not necessary in general since is just a way to tell the C > compiler that a pointer is form a certain type (but is always a pointer, > and in machine code is always the same). > > So, here you will do something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass fromHandle: address) ]. > Perhaps this is a bit about discover-ability. People with C experience may naturally search for "cast". If I Spotter search for..... cast #i it turns up only four... "broadcast" under Socket class If that was instead like... (typeClass castFromHandle: address) then people may be more likely to find it themselves. cheers -ben > ^result > > Iterator >> iterator_next: data > ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** > data)) > > nowâ¦ you have a problem if your type if your type is an âatomicâ type, > like int, long, etc. because those values are passed âby valueâ and not by > pointer, so you will need to decode them. > in this case, I would implement a method extension (probably it worths to > add it to UFFI): > > FFIExternalType class >> valueFromHandle: anAddress > ^ self new handle: anAddress at: 1 âThis is used for structures, > but we can reuse them :)" > > FFIExternalReference class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > FFIExternalStructure class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > So your function will be like something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass valueFromHandle:: > address) ]. > ^result > > and voilÃ , you have your cast :) > > Esteban > > ps: (some errors can be found here, since Iâm âprogramming at mail > clientâ, but you get the idea ;) ) > > > On 15 Feb 2018, at 19:59, Egor Scorik <shirofaii(a)gmail.com> wrote: > > > > Hi, > > > > I'm trying to play with new UFFI system. It looks much easier then > > NativeBoost, but unfortunately its hard to find any docs or examples. > > I have problem with casting void* (ExternalAddress) into smalltalk > object if > > there is no hardcoded type in ffi method. And I really dislike the idea > of > > making many ffi methods, one for each required type. > > In this example i can't understand how to make something like `address > > castTo: type` > > > > FFIExternalObject subclass: #Iterator > > > > Iterator >> asCollectionOfType: aTypeName > > | result address type | > > > > result := OrderedCollection new. > > address := ExternalAddress new. > > type := FFIExternalType resolveType: aTypeName. > > [self iterator_next: address] whileTrue: [ > > result add: (address castTo: type). > > ]. > > ^result > > > > Iterator >> iterator_next: data > > ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** > data)) > > > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > > >

Feb. 17, 2018

Re: [Pharo-users] Pillar questions

by Arturo Zambrano

Oh! I see. Thanks a lot! On Fri, Feb 16, 2018 at 9:16 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Pay attention that there is a pharo bug. The downloaded image has a > minimal window of 10 pixels height and 5 width. > > > On Thu, Feb 15, 2018 at 9:02 PM, Arturo Zambrano < > arturo.zambrano(a)gmail.com> wrote: > >> Thanks for your support! >> >> The image seems to be successfully built. >> When running it, it seems to be headless but I'm sure I'm not running it >> in headless mode. >> Is there any specific parameter for building or running it with UI? (I >> also tried the pharo-ui launch script). >> >> >> >> >> On Thu, Feb 15, 2018 at 3:16 PM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> Hi arturo >>> >>> I do not really get how you do it. :) >>> >>> $ git clone git@github.com:pillar-markup/pillar.git -b newpipeline >>> $ ./pillar/scripts/build.sh >>> >>> >>> should load and then you get an image with pillar loaded. >>> Now you can also just clone the branch and add with iceberg the project >>> and load should work. >>> >>> May be you should enable the metacello settings to true. >>> >>> Stef >>> >>> >>> On Thu, Feb 15, 2018 at 5:32 PM, Arturo Zambrano < >>> arturo.zambrano(a)gmail.com> wrote: >>> >>>> I found the baseline menu entry.. sorry >>>> >>>> [image: Inline image 1] >>>> >>>> installations fails when I choose Install baseline of Pillar (default) >>>> [image: Inline image 2] >>>> >>>> On Thu, Feb 15, 2018 at 12:50 PM, Arturo Zambrano < >>>> arturo.zambrano(a)gmail.com> wrote: >>>> >>>>> Thanks Stef & Guillermo. >>>>> >>>>> Sorry, I'm a bit confused with Icerberg and GIT support. >>>>> I'm using Iceberg and works fine for my small project without handling >>>>> dependencies in github. >>>>> >>>>> I don't understand how dependencies are managed in this case. >>>>> >>>>> What I understand is that Pillar7 lives in Github, I cloned that repo, >>>>> moved to the indicated branch >>>>> when I try to install the packages (Icerber ->load package) it, as >>>>> expected, >>>>> asks for its dependencies. That's why I tried ConfigurationOfPillar >>>>> loadXYZ >>>>> >>>>> @Stef, I'm trying to load Pillar packages into my image (pharo 6.1) >>>>> for development. I tried the readme of that branch, I will report the >>>>> errors I got in a separate thread. >>>>> >>>>> @Guillermo do you mean to manually clone each dependency github >>>>> repo with iceberg? I think I'm missing something, some documentation >>>>> maybe, any pointer is welcome. >>>>> >>>>> Thanks >>>>> >>>>> >>>>> On Thu, Feb 15, 2018 at 6:01 AM, Guillermo Polito < >>>>> guillermopolito(a)gmail.com> wrote: >>>>> >>>>>> And you should load baselines with iceberg (and git). >>>>>> >>>>>> On Thu, Feb 15, 2018 at 8:25 AM, Stephane Ducasse < >>>>>> stepharo.self(a)gmail.com> wrote: >>>>>> >>>>>>> No you should use iceberg. The newpipeline is managed on github. >>>>>>> Have a look at the readme of the that branch >>>>>>> Before executing the build scripts check what it is doing. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 14, 2018 at 10:00 PM, Arturo Zambrano < >>>>>>> arturo.zambrano(a)gmail.com> wrote: >>>>>>> >>>>>>>> Hi Guillermo >>>>>>>> >>>>>>>> I'd recommend to use the latest pillar version in this branch: >>>>>>>>> >>>>>>>>> https://github.com/pillar-markup/pillar/tree/newpipeline >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I cloned that repo (using Iceberg on 6.1 image), moved to that >>>>>>>> branch and then tried >>>>>>>> ConfigurationOfPillar load{stable|bleedingEdge| etc} >>>>>>>> >>>>>>>> To get all the dependencies. >>>>>>>> I got an error (see below) regarding magritte. >>>>>>>> >>>>>>>> Any advice? >>>>>>>> >>>>>>>> TIA >>>>>>>> >>>>>>>> [image: Inline image 1] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> Arturo >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Guille Polito >>>>>>>>> >>>>>>>>> Research Engineer >>>>>>>>> >>>>>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>>>>> >>>>>>>>> CRIStAL - UMR 9189 >>>>>>>>> >>>>>>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>>>>>> <http://www.cnrs.fr>* >>>>>>>>> >>>>>>>>> >>>>>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>>>>> >>>>>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> Guille Polito >>>>>> >>>>>> Research Engineer >>>>>> >>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>> >>>>>> CRIStAL - UMR 9189 >>>>>> >>>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>>> <http://www.cnrs.fr>* >>>>>> >>>>>> >>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>> >>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>> >>>>> >>>>> >>>> >>> >> >

Feb. 16, 2018

Re: [Pharo-users] Web scrapping with Pharo Chrome

by Alistair Grant

Hi Offray, On 16 February 2018 at 19:08, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi Alistair, > > > On 15/02/18 12:50, Alistair Grant wrote: >> Hi Offray, >> >> On 14 February 2018 at 20:29, Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com> wrote: >>> Yes. Me too. Alistair, any starting points with this example? I will take >>> from there and we could get visibility in the upcoming Open Data Day. >> I'm not sure that I understand what you're after, but maybe the >> following will help. >> >> This simply returns a collection of all the h4 headings that are in cells: >> >> >> | rootNode divs cells cellTitleNodes cellTitles | >> >> rootNode := GoogleChrome get: 'http://mutabit.com/grafoscopio/index.en.html'. >> divs := rootNode findAllTags: 'div'. >> cells := divs select: [ :each | (' ' split: (each attributeAt: >> 'class')) includes: 'mdl-cell' ]. >> cellTitleNodes := cells flatCollect: [ :each | each findAllTags: 'h4' ]. >> cellTitles := cellTitleNodes collect: [ :each | (each findAllStrings: >> true) first nodeValue ]. >> { rootNode. divs. cells. cellTitleNodes. cellTitles } >> > > Thanks. This was the starting point I was looking for. Great. The other place to look is at any examples you can find using Soup (which can be loaded from the Catalog). The API for Pharo-Chrome is a subset of that provided by Soup. >>> Of course, we're going to document everything and share back (I have already >>> proposed some improvements in documentation via PR on the Git repo). >> Thanks very much for improving the readme. I've merged the PR. > > No problem. Thanks to you for starting the project. Actually we need to thank Torsten: https://github.com/astares/Pharo-Chrome Cheers, Alistair > Cheers, > > Offray >

Feb. 16, 2018

Re: [Pharo-users] global exception handler mechanism

by Norbert Hartl

> Am 16.02.2018 um 13:38 schrieb Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > > You can also override #defaultAction on Exception, and install a custom > UIManager subclass implementing unhandledErrorDefaultAction: (sent by > UnhandledError #defaultAction, receives the error as argument). > > Would be nice(r) if UIManager had a defaultUnhandledErrorActionBlock: > setter, but it's not too bothersome creating a subclass. > +1 Norbert > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 16, 2018

Re: [Pharo-users] Web scrapping with Pharo Chrome

by Offray Vladimir Luna CÃ¡rdenas

Hi Alistair, On 15/02/18 12:50, Alistair Grant wrote: > Hi Offray, > > On 14 February 2018 at 20:29, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: >> Yes. Me too. Alistair, any starting points with this example? I will take >> from there and we could get visibility in the upcoming Open Data Day. > I'm not sure that I understand what you're after, but maybe the > following will help. > > This simply returns a collection of all the h4 headings that are in cells: > > > | rootNode divs cells cellTitleNodes cellTitles | > > rootNode := GoogleChrome get: 'http://mutabit.com/grafoscopio/index.en.html'. > divs := rootNode findAllTags: 'div'. > cells := divs select: [ :each | (' ' split: (each attributeAt: > 'class')) includes: 'mdl-cell' ]. > cellTitleNodes := cells flatCollect: [ :each | each findAllTags: 'h4' ]. > cellTitles := cellTitleNodes collect: [ :each | (each findAllStrings: > true) first nodeValue ]. > { rootNode. divs. cells. cellTitleNodes. cellTitles } > Thanks. This was the starting point I was looking for. > > >> Of course, we're going to document everything and share back (I have already >> proposed some improvements in documentation via PR on the Git repo). > Thanks very much for improving the readme. I've merged the PR. No problem. Thanks to you for starting the project. Cheers, Offray

Feb. 16, 2018