January 2019 - Pharo-users - lists.pharo.org

[ANN] Pharo open documentation
by Cyril Ferlicot Jan. 31, 2019

Jan. 31, 2019

Hi everyone! With some other members of the community we are proud to announce a new effort on Pharo documentation. We launched an organization pharo-open-documentation which is a user-maintained documentation related to Pharo environment, language, and libraries. Currently it has three main projects: - pharo-wiki : Wiki related to the Pharo programming language and environment. - awesome-pharo : A collection of awesome Pharo libraries, tools, frameworks and software. We want to make this project a reference in https://github.com/sindresorhus/awesome - awesome-pharo-ml : List of projects, books, booklets, papers, and applications related to machine learning, AI, data science in Pharo. Contributions are welcomed! If you own a cool project in Pharo others could use in their own projects, send us a PR to awesome-pharo! If you have knowledge on Pharo or projects of Pharo, we would be glad if you could contribute to the pharo-wiki! Don't forget to read the contribution guidelines. ;) We opened a Twitter to announce new entries on the pharo-wiki. https://twitter.com/PharoOpen Have a nice day! -- Cyril Ferlicot https://ferlicot.fr

4 3

Fwd: startup error in windows 10
by Hilaire Jan. 31, 2019

Jan. 31, 2019

Hi, Any idea? It seems related to an error calling Cairo library. Hilaire -------- Message transfÃ©rÃ© -------- SujetÂ : startup error in windows 10 DateÂ : Sun, 27 Jan 2019 23:53:36 -0700 (MST) DeÂ : d_koticha [via Dr. Geo Forum] <ml+s996172n4025532h46(a)n3.nabble.com> PourÂ : Hilaire Fernandes <hfern(a)free.fr> I Installed Dr Geo and used it few times before November 2018. after updating windows 10 in January 2019 the app doesn't display drawing area. it loads but shows a red screen with some code and a cross. screen shot is attached. error.jpg <http://forum.drgeo.eu/file/n4025532/error.jpg> ------------------------------------------------------------------------ If you reply to this email, your message will be added to the discussion below: http://forum.drgeo.eu/startup-error-in-windows-10-tp4025532.html To start a new topic under Dr. Geo users, email ml+s996172n4023913h57(a)n3.nabble.com To unsubscribe from Dr. Geo Forum, click here <http://forum.drgeo.eu/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…>. NAML <http://forum.drgeo.eu/template/NamlServlet.jtp?macro=macro_viewer&id=instan…>

3 5

Re: [Pharo-users] Fwd: startup error in windows 10
by Hilaire Jan. 31, 2019

Jan. 31, 2019

Hi Benoit, You seems to describe another problem I am not sure to understand. Is it related to the encoding of your name in the path of your system? Does it look to your related to these bugs: https://bugs.launchpad.net/drgeo/+bug/1468205 https://bugs.launchpad.net/drgeo/+bug/1412834 ? Thanks to give a try Hilaire Le 31/01/2019 Ã 04:46, Benoit St-Jean via Pharo-users a Ã©critÂ : > Unfortunately, Dr. Geo suffers from the same problem I have with any > Pharo 6.x and 7.x image regarding the encoding of my name in Windows.Â > It crashes when the app starts at the exact same place and I can't do > much.Â Sorry. -- Dr. Geo http://drgeo.eu

1 0

Re: [Pharo-users] Fwd: startup error in windows 10
by Hilaire Jan. 31, 2019

Jan. 31, 2019

Hi Benoit, It is DrGeo 18.06 https://launchpad.net/drgeo/trunk/18.06/+download/DrGeo.app-18.06a.zip Thanks to try out. Hilaire Le 30/01/2019 Ã 00:16, Benoit St-Jean via Pharo-users a Ã©critÂ : > Hilaire, do you have an URL so I can download the exact same thing > that users has?Â I'm also on Windows 10. > > I'll try to run in dev mode and see what happens! -- Dr. Geo http://drgeo.eu

2 1

Re: [Pharo-users] SmaCC parsing "rest until"
by Manuel Leuenberger Jan. 30, 2019

Jan. 30, 2019

Hi Thierry, Thanks for the ideas and references. I also tried parsing with PetitParser2, because with PEGs I can have unlimited lookahead. Still, I did not get it working quickly, and it was ugly anyway. One way would also be to just tokenize the whole remainder of the line into words, and rebuild the rest without the last word in a second step. Ultimately, it was easier to write a hand-knitted parser that does exactly that (https://github.com/maenu/leak-reporter/blob/master/src/pharo/LeakReporter/L… <https://github.com/maenu/leak-reporter/blob/master/src/pharo/LeakReporter/L…>), the structure is easy enough. Cheers, Manuel > On 30 Jan 2019, at 19:19, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 29/01/2019 Ã 22:17, Manuel Leuenberger a Ã©crit : >> Hi, >> I am currently struggling with understanding why my SmaCC parser refuses to parse a rather simple language. Grammar and example are below. >> The language consists of multiple leak reports, separated by two newlines. Each leak report has a type and object and byte size on the first line. Then comes a stack of indented frames with addresses, and method and source location if available. Somehow my parser always fails because it trying to scan the whole string as <method>. I am struggling with this since hours but not making any progress. >> How do I need to rewrite the grammar so that the scanner produces the right tokens for the parser? >> I understand that the <method> token use in Source is problematic, because it needs to match until the last word. But I cannot find a way to write it in another way or tweak the parser attributes to figure out the right tokenization. > > Hi Manuel, > > the problem is effectively your <method> tag, which is eating next to everything. > > In such a situation, you could use a state in your scanner, limit <method> to that state, and switch in and out of that state in the parser actions. > > something like: > > inMethod <method> : ; > > in: "in" {self state: #inMethod}; > > method: <method> {self state: #default}; > > See section 3.6 in the SmaCC booklet. > >> Anybody has some hints? I would greatly appreciate it. > > The scanner state may help, but I think your <method> tag has to be better defined, else you will be unable to get the <file> part. > > Source > : " (<unknown module>)" { #unknown } > | "in " <method> 'method' " " <file> 'file' { { method value . file value } } > ; > > Avoid having spaces into the terminals (i.e. "in "), and it won't probably match the " ". > > What I can only suggest is to write a <method> (or method non terminal) closed by a space, and only allowing spaces if inside enclosing parenthesis "(" ")" or brackets "<" ">"; what is after the space is the <file>. > > Hope this helps, > > Thierry > >> Cheers, >> Manuel >> Example: >> LeReParser parse: 'Indirect leak of 8 byte(s) in 1 object(s) allocated from: >> #0 0x106be248c in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5d48c) >> #1 0x12193989d in moz_xmalloc mozalloc.cpp:83 >> #2 0x11fc8200d in std::__1::vector<unsigned int, std::__1::allocator<unsigned int> >::__append(unsigned long) mozalloc.h:194 >> #3 0x11fc80d5a in mozilla::gfx::GradientStopsSkia::GradientStopsSkia(std::__1::vector<mozilla::gfx::GradientStop, std::__1::allocator<mozilla::gfx::GradientStop> > const&, unsigned int, mozilla::gfx::ExtendMode) vector:2041 >> #4 0x11fc6f1dc in mozilla::gfx::DrawTargetSkia::CreateGradientStops(mozilla::gfx::GradientStop*, unsigned int, mozilla::gfx::ExtendMode) const DrawTargetSkia.cpp:62 >> #5 0x122236b1e in create_gradient_stops(mozilla::gfx::DrawTarget*, float*, unsigned int, mozilla::gfx::ExtendMode) pattern.cpp:98 >> #6 0x122236323 in moz2d_pattern_linear_gradient_create_flat pattern.cpp:40 >> #7 0x1069cf901 in primitiveCalloutWithArgs (Pharo:x86_64+0x1003a5901) >> #8 0x10669e222 in primitiveExternalCall gcc3x-cointerp.c:76887 >> #9 0x106694aed in executeNewMethod gcc3x-cointerp.c:22341 >> #10 0x10669a403 in ceSendsupertonumArgs gcc3x-cointerp.c:16540 >> #11 0x11043c134 (<unknown module>) >> #12 0x10662d712 in interpret gcc3x-cointerp.c:2754 >> #13 0x1068b2ada in -[sqSqueakMainApplication runSqueak] sqSqueakMainApplication.m:201 >> #14 0x7fffc93786fc in __NSFirePerformWithOrder (Foundation:x86_64+0xd76fc) >> #15 0x7fffc78cfc56 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ (CoreFoundation:x86_64h+0xa6c56) >> #16 0x7fffc78cfbc6 in __CFRunLoopDoObservers (CoreFoundation:x86_64h+0xa6bc6) >> #17 0x7fffc78b05f8 in __CFRunLoopRun (CoreFoundation:x86_64h+0x875f8) >> #18 0x7fffc78b0033 in CFRunLoopRunSpecific (CoreFoundation:x86_64h+0x87033) >> #19 0x7fffc6e10ebb in RunCurrentEventLoopInMode (HIToolbox:x86_64+0x30ebb) >> #20 0x7fffc6e10bf8 in ReceiveNextEventCommon (HIToolbox:x86_64+0x30bf8) >> #21 0x7fffc6e10b25 in _BlockUntilNextEventMatchingListInModeWithFilter (HIToolbox:x86_64+0x30b25) >> #22 0x7fffc53a5a53 in _DPSNextEvent (AppKit:x86_64+0x46a53) >> #23 0x7fffc5b217ed in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (AppKit:x86_64+0x7c27ed) >> #24 0x7fffc539a3da in -[NSApplication run] (AppKit:x86_64+0x3b3da) >> #25 0x7fffc5364e0d in NSApplicationMain (AppKit:x86_64+0x5e0d) >> #26 0x7fffdd0a2234 in start (libdyld.dylib:x86_64+0x5234) >> '. >> Grammar: >> %prefix LeRe; >> %suffix Node; >> %root Report; >> <newline> >> : \r \n? | \n >> ; >> <number> >> : \d+ >> ; >> <index> >> : \# \d+ >> ; >> <address> >> : 0 x [0-9a-f]+ >> ; >> <method> >> : [^\r\n]+ >> ; >> <file> >> : \S+ >> ; >> Report >> : Leaks 'leaks' { leaks } >> ; >> Leaks >> : Leak 'leak' { { leak } } >> | Leaks 'leaks' Leak 'leak' { leaks , { leak } } >> ; >> Leak >> : LeakType 'type' <number> 'bytes' " byte(s) in " <number> 'objects' " object(s) allocated from:" <newline> Stack 'stack' <newline> { { type . bytes value . objects value . stack } } >> ; >> LeakType >> : "Indirect leak of " { #indirect } >> | "Direct leak of " { #direct } >> ; >> Stack >> : Frames 'frames' { frames } >> ; >> Frames >> : Frame 'frame' { { frame } } >> | Frames 'frames' Frame 'frame' { frames , { frame } } >> ; >> Frame >> : " " <index> " " <address> " " Source 'source' <newline> { source } >> ; >> Source >> : " (<unknown module>)" { #unknown } >> | "in " <method> 'method' " " <file> 'file' { { method value . file value } } >> ; >

1 0

PetitParser question
by Konrad Hinsen Jan. 30, 2019

Jan. 30, 2019

Dear parsing experts, I have been working on a medium-size parser using the PetitParser framework, which so far has been a very productive environment. But now I have a problem to which I could not find the solution in "Deep into Pharo", nor by searching around in the code. One of my production rules requires several parsed items to be equal. It should accept expressions such as 1 + 3 + 2 + 6 2 * 9 * 3 * 6 0 - 8 - 5 - 3 but not expressions that mix different operators (because my grammar has no precedence rules and thus requires parentheses for disambiguation). In various other parsing frameworks, I do this by parsing up to the first operator, retrieving it, and permitting only that same string in the following. But I haven't found a way to do this in PetitParser, nor any other obvious solution. The only solution I see right now is to have one production rule per operator, but that makes for a huge grammar. Is there another way? Thanks in advance, Konrad

3 9

No window on OS X
by Hilaire Jan. 30, 2019

Jan. 30, 2019

Hi, DrGeo 18.06 for Mac OSX[1] was built against P6.1 32bits VM (as far I remember). On Mac OS X High Sierra 10.13.6 (17G65), drgeo starts but there is no window. Is there known issues as this one? Thanks, Hilaire [1] https://launchpad.net/drgeo/trunk/18.06/+download/DrGeo.app-18.06a.zip -- Dr. Geo http://drgeo.eu

1 0

Falsehoods programmers believe about Smalltalk
by HernÃ¡n Morales Durand Jan. 30, 2019

Jan. 30, 2019

Hi there, I just created a GitHub repo to collect myths around Smalltalk-based technologies: Pharo, Squeak, VW, VAST, Smalltalk/X, GNU/ST, etc. in the spirit of the Falsehoods lists [1-4]. This is just a draft now but please feel free to add falsehoods based on your own experiences. Examples are greatly appreciated. https://github.com/hernanmd/falsehoods_smalltalk Cheers, HernÃ¡n [1] https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-ab… [2] https://chiselapp.com/user/ttmrichter/repository/gng/doc/trunk/output/false… [3] https://github.com/googlei18n/libphonenumber/blob/master/FALSEHOODS.md [4] https://meta-package-manager.readthedocs.io/en/develop/falsehoods.html

4 6

SmaCC parsing "rest until"
by Manuel Leuenberger Jan. 29, 2019

Jan. 29, 2019

Hi, I am currently struggling with understanding why my SmaCC parser refuses to parse a rather simple language. Grammar and example are below. The language consists of multiple leak reports, separated by two newlines. Each leak report has a type and object and byte size on the first line. Then comes a stack of indented frames with addresses, and method and source location if available. Somehow my parser always fails because it trying to scan the whole string as <method>. I am struggling with this since hours but not making any progress. How do I need to rewrite the grammar so that the scanner produces the right tokens for the parser? I understand that the <method> token use in Source is problematic, because it needs to match until the last word. But I cannot find a way to write it in another way or tweak the parser attributes to figure out the right tokenization. Anybody has some hints? I would greatly appreciate it. Cheers, Manuel Example: LeReParser parse: 'Indirect leak of 8 byte(s) in 1 object(s) allocated from: #0 0x106be248c in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5d48c) #1 0x12193989d in moz_xmalloc mozalloc.cpp:83 #2 0x11fc8200d in std::__1::vector<unsigned int, std::__1::allocator<unsigned int> >::__append(unsigned long) mozalloc.h:194 #3 0x11fc80d5a in mozilla::gfx::GradientStopsSkia::GradientStopsSkia(std::__1::vector<mozilla::gfx::GradientStop, std::__1::allocator<mozilla::gfx::GradientStop> > const&, unsigned int, mozilla::gfx::ExtendMode) vector:2041 #4 0x11fc6f1dc in mozilla::gfx::DrawTargetSkia::CreateGradientStops(mozilla::gfx::GradientStop*, unsigned int, mozilla::gfx::ExtendMode) const DrawTargetSkia.cpp:62 #5 0x122236b1e in create_gradient_stops(mozilla::gfx::DrawTarget*, float*, unsigned int, mozilla::gfx::ExtendMode) pattern.cpp:98 #6 0x122236323 in moz2d_pattern_linear_gradient_create_flat pattern.cpp:40 #7 0x1069cf901 in primitiveCalloutWithArgs (Pharo:x86_64+0x1003a5901) #8 0x10669e222 in primitiveExternalCall gcc3x-cointerp.c:76887 #9 0x106694aed in executeNewMethod gcc3x-cointerp.c:22341 #10 0x10669a403 in ceSendsupertonumArgs gcc3x-cointerp.c:16540 #11 0x11043c134 (<unknown module>) #12 0x10662d712 in interpret gcc3x-cointerp.c:2754 #13 0x1068b2ada in -[sqSqueakMainApplication runSqueak] sqSqueakMainApplication.m:201 #14 0x7fffc93786fc in __NSFirePerformWithOrder (Foundation:x86_64+0xd76fc) #15 0x7fffc78cfc56 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ (CoreFoundation:x86_64h+0xa6c56) #16 0x7fffc78cfbc6 in __CFRunLoopDoObservers (CoreFoundation:x86_64h+0xa6bc6) #17 0x7fffc78b05f8 in __CFRunLoopRun (CoreFoundation:x86_64h+0x875f8) #18 0x7fffc78b0033 in CFRunLoopRunSpecific (CoreFoundation:x86_64h+0x87033) #19 0x7fffc6e10ebb in RunCurrentEventLoopInMode (HIToolbox:x86_64+0x30ebb) #20 0x7fffc6e10bf8 in ReceiveNextEventCommon (HIToolbox:x86_64+0x30bf8) #21 0x7fffc6e10b25 in _BlockUntilNextEventMatchingListInModeWithFilter (HIToolbox:x86_64+0x30b25) #22 0x7fffc53a5a53 in _DPSNextEvent (AppKit:x86_64+0x46a53) #23 0x7fffc5b217ed in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (AppKit:x86_64+0x7c27ed) #24 0x7fffc539a3da in -[NSApplication run] (AppKit:x86_64+0x3b3da) #25 0x7fffc5364e0d in NSApplicationMain (AppKit:x86_64+0x5e0d) #26 0x7fffdd0a2234 in start (libdyld.dylib:x86_64+0x5234) '. Grammar: %prefix LeRe; %suffix Node; %root Report; <newline> : \r \n? | \n ; <number> : \d+ ; <index> : \# \d+ ; <address> : 0 x [0-9a-f]+ ; <method> : [^\r\n]+ ; <file> : \S+ ; Report : Leaks 'leaks' { leaks } ; Leaks : Leak 'leak' { { leak } } | Leaks 'leaks' Leak 'leak' { leaks , { leak } } ; Leak : LeakType 'type' <number> 'bytes' " byte(s) in " <number> 'objects' " object(s) allocated from:" <newline> Stack 'stack' <newline> { { type . bytes value . objects value . stack } } ; LeakType : "Indirect leak of " { #indirect } | "Direct leak of " { #direct } ; Stack : Frames 'frames' { frames } ; Frames : Frame 'frame' { { frame } } | Frames 'frames' Frame 'frame' { frames , { frame } } ; Frame : " " <index> " " <address> " " Source 'source' <newline> { source } ; Source : " (<unknown module>)" { #unknown } | "in " <method> 'method' " " <file> 'file' { { method value . file value } } ;

1 0

What's wrong?
by eftomi Jan. 28, 2019

Jan. 28, 2019

Every time that I start Pharo 7.0.1 32-bit image (it's name is "Pharo 7.0 - 32bit" and it resides in the directory of the same name), a new directory is created under images directory, with the name "Pharo 7.0 - 64bit (development version)-01". Within it, Pharo is using directories "ombu-sessions", "play-cache" to store its run-time information. I'm using PharoLauncher version: 1.5.1. The situation is the same if I do this with a fresh 7.0.1 image. System reporter shows: Image ----- C:\Users\eftomi.MISKOTI\EFTOMI\PHARO\images\Pharo 7.0 - 32bit\Pharo 7.0 - 32bit.image Pharo7.0.1 Build information: Pharo-7.0.1+build.143.sha.eca26da119bccd95e463c7717a44b814453df4e8 (32 Bit) Unnamed Virtual Machine --------------- C:\Users\eftomi.MISKOTI\EFTOMI\PHARO\vms\70-x86\Pharo.exe CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6 Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Win32 built on Jan 5 2019 20:12:30 GMT Compiler: 7.4.0 VMMaker versionString VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6 Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

2 2