December 2019 - Pharo-users

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

by Sean P. DeNigris

Steffen MÃ¤rcker wrote > I can send you that code. Awesome. I'll email you. Although, I wonder how relevant this is given your answers down below. Are there many grammars available in Xtreams syntax to make this useful? Also, what is the license? Can I add it somewhere on GH under MIT (with attribution of course)? Steffen MÃ¤rcker wrote > However, I moved away from Xtreams own PEG flavor to Bryan Ford's > original PEG syntax (close but more common) Ah, interesting. I didn't realize that Xtreams used a custom PEG syntax. I wonder why?! Steffen MÃ¤rcker wrote > From Bryan Ford's original PEG syntax: > 1. Xtreams Grammer and Actor that build an Xtreams parser > ... > All three are available for VW in the Cincom's public repository: > - Xtreasm-Parsing (8.2-3,stm): +PEG parser +some fixes to Xtreams parser I'd certainly like to port that at some point, but I'm currently fairly mystified about the best practice process. I just reached out to Pavel about the Ring2 approach on which he spoke at ESUG. Do you have a documented process or any pointers even? Steffen MÃ¤rcker wrote > And 2, 3 for Pharo on GitHub, e.g. > - https://github.com/kursjan/petitparser2/tree/master/PetitParser2-PEG Great. I use PP2 a lot. So if IIUC, I can now feed a PEG-syntax grammar string and have a PP2 parser generated for it? Steffen MÃ¤rcker wrote > Speaking of, I just noticed that translator form Xtreams.PEG to PEG is > missing to complete the picture here. ;-) Ah, yes that makes sense. Any idea how much effort would be involved? Steffen MÃ¤rcker wrote > As far as I know, there is no BNF-like parser generator for Xtreams, > available. > ... > Is it an option for you to convert your BNF to PEG manually? I'm not a parsing expert, so that may have been what I'm already doing and I'm using the wrong terminology. I took the ABNF from rfc5322 [1] and adapted it slightly [2] to be consumed by Xtreams [3] [OT?] As a final aside, I've been wondering if there's any way to generate "hand-rolled" equivalent parsers from Xtreams, PP, etc. for use cases where none of the libraries are available. I have in mind Pharo's MailMessage. It doesn't seem like any full-featured parsing libraries will be integrated any time soon, so the lowest levels use painful, duplication-riddled hand-rolled parsers. It would be great to leverage all this great library tech to create and reason about those... [/OT] Thanks for the discussion! 1. https://tools.ietf.org/html/rfc5322 2. https://github.com/seandenigris/Xtreams-Pharo/blob/master/repository/Xtream… 3. https://github.com/seandenigris/Xtreams-Pharo/blob/master/repository/Xtream… ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 3, 2019

Re: [Pharo-users] uFFI: Debugging "External module not found" Error

by Sean P. DeNigris

Ben Coman wrote > One catch that has confused me in the past, is when the system caches that > it couldn't find the external module, > so even when I copyied it to the VM folder or got the path correct, it > continued to fail until I restarted the Image. Great gotcha! We should add that to the docs. I'll have a go after I figure this error out. In my case, restarting did not help :/ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 3, 2019

Re: [Pharo-users] uFFI: Debugging "External module not found" Error

by Alistair Grant

Hi Sean, On Tue, 3 Dec 2019 at 17:26, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I was trying to get Pharo-LibVLC working on Mac. The following is copied from > a GH issue[1]: > > > I have VLC installed via Homebrew cask, the formula for which simply > > installs the dmg. I > > first tried supplying a full path to the dylib that the VLC app uses > > (/Applications/VLC.app/Contents/MacOS/lib/libvlc.5.dylib), which resulted > > in "Error: > > External module not found". I then remembered some trouble people have had > > in the past > > with FFI lookup locations and tried copying into the VM's plugin folder > > both a link and the > > actual dylib, with the same error. I read the uFFI booklet, but didn't > > learn anything more. > > > > I also checked that the VLC lib was 64-bit via: > > > > lipo -info .../Pharo.app/Contents/MacOS/Plugins/libvlc.5.dylib > > which returned: > > Non-fat file: .../Plugins/libvlc.5.dylib is architecture: x86_64 The same message is returned whether the module itself isn't found, or if one of its dependencies can't be found. On linux you can check dependencies with `ldd file.so`, I don't know what the Mac equivalent is. HTH, Alistair

Dec. 3, 2019

Re: [Pharo-users] uFFI: Debugging "External module not found" Error

by Ben Coman

On Wed, 4 Dec 2019 at 00:26, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I was trying to get Pharo-LibVLC working on Mac. The following is copied > from > a GH issue[1]: > > > I have VLC installed via Homebrew cask, the formula for which simply > > installs the dmg. I > > first tried supplying a full path to the dylib that the VLC app uses > > (/Applications/VLC.app/Contents/MacOS/lib/libvlc.5.dylib), which resulted > > in "Error: > > External module not found". I then remembered some trouble people have > had > > in the past > > with FFI lookup locations and tried copying into the VM's plugin folder > One catch that has confused me in the past, is when the system caches that it couldn't find the external module, so even when I copyied it to the VM folder or got the path correct, it continued to fail until I restarted the Image. cheers -ben > > both a link and the > > actual dylib, with the same error. I read the uFFI booklet, but didn't > > learn anything more. > > > > I also checked that the VLC lib was 64-bit via: > > > > lipo -info .../Pharo.app/Contents/MacOS/Plugins/libvlc.5.dylib > > which returned: > > Non-fat file: .../Plugins/libvlc.5.dylib is architecture: x86_64 > > [1] https://github.com/badetitou/Pharo-LibVLC/issues/1 > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Dec. 3, 2019

uFFI: Debugging "External module not found" Error

by Sean P. DeNigris

I was trying to get Pharo-LibVLC working on Mac. The following is copied from a GH issue[1]: > I have VLC installed via Homebrew cask, the formula for which simply > installs the dmg. I > first tried supplying a full path to the dylib that the VLC app uses > (/Applications/VLC.app/Contents/MacOS/lib/libvlc.5.dylib), which resulted > in "Error: > External module not found". I then remembered some trouble people have had > in the past > with FFI lookup locations and tried copying into the VM's plugin folder > both a link and the > actual dylib, with the same error. I read the uFFI booklet, but didn't > learn anything more. > > I also checked that the VLC lib was 64-bit via: > > lipo -info .../Pharo.app/Contents/MacOS/Plugins/libvlc.5.dylib > which returned: > Non-fat file: .../Plugins/libvlc.5.dylib is architecture: x86_64 [1] https://github.com/badetitou/Pharo-LibVLC/issues/1 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 3, 2019

thesis on using ML for Pharo code completion

by Myroslava Romaniuk

Hi everyone I'm starting work on a thesis on using ML for Pharo completion, in particular n-gram language models, and I wrote a little blog post with some details and research questions that I have. Here's a link: https://medium.com/@myroslavarm/using-ml-for-pharo-autocompletion-ideas-80a… . Any feedback or ideas on the topic (and research questions) are most welcome. Best regards, Myroslava

Dec. 2, 2019

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

by Steffen MÃ¤rcker

Dear Sean, thanks for bringing this up and for the interesting link [1]. I'll have a look. Meanwhile, I am still on both lists. ;-) > Steffen MÃ¤rcker wrote >> I wrote a PetitParserGenerator that takes the DSL and builds a >> PetitParser. > > I don't know how I could've missed this gem! I hope Steffen is still > subscribed. I googled "PetitParserGenerator", but only found these ML > posts > :/ It was easy to miss, since I never actually posted that code. Here's what I've done: From Xtreams.PEG syntax: - PetitParserGenerater > PetitParser code - PetitParserParser > PetitParser instance I can send you that code. It should be straight forward to adapt it for PP2. However, I moved away from Xtreams own PEG flavor to Bryan Ford's original PEG syntax (close but more common) and programmed for Xtreams, PP and PP2: From Bryan Ford's original PEG syntax: 1. Xtreams Grammer and Actor that build an Xtreams parser 2. PP(2)PEGParserParser that builds a PP(2) parser instance 3. PP(2)PEGParserCompiler that builds PP(2) parser classes All three are available for VW in the Cincom's public repository: - Xtreasm-Parsing (8.2-3,stm): +PEG parser +some fixes to Xtreams parser - PetitParser-PEG (1.11,stm) - PetitParser2-PEG (1.11,stm) And 2, 3 for Pharo on GitHub, e.g. - https://github.com/kursjan/petitparser2/tree/master/PetitParser2-PEG Speaking of, I just noticed that translator form Xtreams.PEG to PEG is missing to complete the picture here. ;-) > IIRC Xtreams can take a BNF and generate a parser. As far as I know, there is no BNF-like parser generator for Xtreams, available. > wouldn't mind a two step BNF -> Xtreams -> PP process. Is it an option for you to convert your BNF to PEG manually? Best regards, Steffen

Dec. 2, 2019

Porting to Pharo via Ring

by Sean P. DeNigris

Pavel gave an intriguing high-level experience report on porting from VW to Pharo via (among other things) the Ring meta model [1]. Are any more specifics available? It would be valuable to the community to have knowledge of this process freely available. How would someone else actually go about this with another project? Would it help porting from one version of Pharo to another? [1] https://www.youtube.com/watch?v=XrOdlwtVfMM&list=PLJ5nSnWzQXi8DPNpy1jCkjE4y… ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 1, 2019

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

by Sean P. DeNigris

I rediscovered this thread while pondering an (existential?!) problem: Why do we keep having to write, and rewrite, and rewrite, ad infinitum, parsers for well known domains like rfc specs? The parser world in many ways feels like a modern post-"Tower of Babel". I was really excited about the reverse parsing stuff done in Squeak by Ted Kaehler and Alessandro Warth [1], which never seemed to get picked up. Steffen MÃ¤rcker wrote > I wrote a PetitParserGenerator that takes the DSL and builds a > PetitParser. I don't know how I could've missed this gem! I hope Steffen is still subscribed. I googled "PetitParserGenerator", but only found these ML posts :/ IIRC Xtreams can take a BNF and generate a parser. I was thinking about implementing a BNF parser in PetitParser, but would love to avoid that, wouldn't mind a two step BNF -> Xtreams -> PP process. Although there was this SO reply [2] where Lukas said that one can't necessarily blindly feed a BNF to a PEG. It also got me thinking about sharing parsers between PP and PP2, since in many cases it seems that only the internal class names would differ... [1] http://www.vpri.org/pdf/m2008001_parseback.pdf [2] https://stackoverflow.com/a/9443024/424245 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 1, 2019