- Pharo-users - lists.pharo.org

No window on OS X

by Hilaire

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

Jan. 30, 2019

Re: [Pharo-users] Fwd: startup error in windows 10

by Hilaire

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

Jan. 30, 2019

Re: [Pharo-users] [Glass] [squeak-dev] Falsehoods programmers believe about Smalltalk

by HernÃ¡n Morales Durand

Thank you for your notes Richard, it's really interesting to see not so well-known projects. I would love to have more people sharing their wisdom and knocking down more myths. Cheers, HernÃ¡n El dom., 27 ene. 2019 a las 1:17, Richard O'Keefe via Glass (< glass(a)lists.gemtalksystems.com>) escribiÃ³: > I have my own Smalltalk system implemented as a batch compiler via C. > This was originally just going to be a baseline for a student wanting > to work on JIT, but he went elsewhere and I found the system surprisingly > useful. I also wanted something that hewed closely to the ANSI Smalltalk > standard, but could diverge in other matters (like not having dynamic code > modification). > > - All Smalltalk bytecode sets are stack-based VM. (?) > > My system has no bytecodes. Smalltalk=>C=>native code. > > - Bytecodes are always fixed-size. (?) > > False back in the Blue Book. Why does it matter anyway? > > - Most of the time spent by a VM is in the instruction interpreter. > (actually it's in the GC right?) > > There is no interpreter in my system, and many modern systems use a JIT. > That or they generate Javascript or JVM instructions or .NET or something, > and then _that_ gets turned into native code. > > - You cannot serialize objects containing blocks. (IIRC one can use > MessageSends) > > True in my system but that's because blocks contain pointers to native > code and may > contain pointers into the C stack. I have plans to work around this, but > it has not been > a priority. Something I don't ever plan to deal with is objects > containing references to > external objects (memory-mapped segments, file descriptors, sockets, ...) > and it is not > at all clear to me what the semantics should be. > > BinaryObjectStorage in VisualWorks has no trouble with blocks. > > I meant to try this in Pharo 7.0. The image I just installed via the > launcher has > no DataStream, ReferenceStream, or SmartRefStream, but the class comment > for MCDataStream begins > "This is the save-to-disk facility. > A DataStream can store one or more objects in a persistent form. > > To handle objects with sharing and cycles, you must use a ReferenceStream > instead of a DataStream. (Or SmartRefStream.) ReferenceStream is > typically > faster and produces smaller files because it doesn't repeatedly write the > same Symbols." > > This was also the case back to Pharo 2.0. What *is* the persistence > scheme in Pharo these days? > > - Image cannot be bootstrapped. (This is possible in ST/X and now in Pharo > I think). > > There are no images in my system. > > - All Smalltalks includes UI classes. (GemStone doesn't have AFAIK). > > It depends on what you mean by "include". Gnu Smalltalk *has* UI classes > but they > are not loaded by default. > > - All implementations uses direct pointers, (GST?) > > True in my case, but that's because I'm lazy and using the Boehm collector. > > - All implementations uses green threads. (VAST? MT?) > > False in my case. A Process is a POSIX (red) thread and no green threads > exist. > This meant having to keep the interface fairly lean, but honestly wasn't > that hard, > since the Boehm collector handled the hard stuff. > > > On Tue, 22 Jan 2019 at 13:27, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> >> Done. >> >> I have some possible myths, but I'd like to confirm or reject: >> >> - All Smalltalk bytecode sets are stack-based VM. (?) >> - Bytecodes are always fixed-size. (?) >> - Most of the time spent by a VM is in the instruction interpreter. >> (actually it's in the GC right?) >> - You cannot serialize objects containing blocks. (IIRC one can use >> MessageSends) >> - Image cannot be bootstrapped. (This is possible in ST/X and now in >> Pharo I think). >> - All Smalltalks includes UI classes. (GemStone doesn't have AFAIK). >> - All implementations uses direct pointers, (GST?) >> - All implementations uses green threads. (VAST? MT?) >> >> I'm sure people in this list will have a lot more myths heard from >> Conferences, Forums, Videos, Talks, etc. Like the guy who said Smalltalk >> was dead. So if you did something which could be ignored publicly, please >> don't hesitate to reply or ping me to get added as collaborator. >> >> Cheers, >> >> HernÃ¡n >> >> >> >> El dom., 20 ene. 2019 a las 22:41, Eliot Miranda (< >> eliot.miranda(a)gmail.com>) escribiÃ³: >> >>> Hi HernÃ¡n, >>> >>> On Sun, Jan 20, 2019 at 2:31 PM HernÃ¡n Morales Durand < >>> hernan.morales(a)gmail.com> wrote: >>> >>>> 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. >>>> >>> >>> You want pull requests? If not, would you give me write permission? >>> I'd love to add to the "Smalltalk is obsolete" section... >>> >>> >>>> >>>> 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 >>>> >>>> >>>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >>> >> _______________________________________________ > Glass mailing list > Glass(a)lists.gemtalksystems.com > http://lists.gemtalksystems.com/mailman/listinfo/glass >

Jan. 30, 2019

Re: [Pharo-users] Fwd: startup error in windows 10

by Benoit St-Jean

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! On 2019-01-29 14:27, Hilaire wrote: > I asked the user to send me the PharoDebug.log to have a more accurate > feedback: > > http://forum.drgeo.eu/file/n4025537/PharoDebug.log > > Of course I should make him to test with a newer VM to see if the > problem is gone, but it is a bitÂ more complicate. > > Are the video info necessary? The image world starts just fine. > > Hilaire > > Le 28/01/2019 Ã 23:34, Ben Coman a Ã©critÂ : >> To provide the best chance for someone to help, can you provide: >> * base Image version >> * vm version >> * systeminfo.exe (stripped of personally identifying data) >> Â Â * with dates added to hotfixes from >> (https://www.tenforums.com/tutorials/5472-view-windows-update-history-window…) >> * video info from (wmic path win32_VideoController get /all >> /format:htable >> c:\temp\graphics.html) -- ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Jan. 29, 2019

SmaCC parsing "rest until"

by Manuel Leuenberger

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 } } ;

Jan. 29, 2019

Re: [Pharo-users] PetitParser question

by Tudor Girba

Hi, > On Jan 29, 2019, at 7:04 PM, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > Tudor Girba <tudor(a)tudorgirba.com> writes: > >> But, does it solve your problem? > > Not yet. Not sure it will. Would this not work: p := (#digit asPParser separatedBy: ($+ asPParser / $- asPParser) trim) ==> [:tokens | | result | result := tokens. 2 to: tokens size - 1 by: 2 do: [ :index | (tokens at: index) = (tokens at: 2) ifFalse: [result := PP2Failure message: 'expected ', (tokens at: 2) asString, ' but got ', (tokens at: index) asString ]]. result ]. p end parse: '1+3+2 - 6' "a PP2Failure: 'expected + but got -â" p end parse: '1+3+2 + 6' "#($1 $+ $3 $+ $2 $+ $6)â ? Please note that I used PetitParser2 for this one because it also addresses the failure message issue you raised below. However, the logic would work in PP1 as well. Cheers, Doru >>> More generally, there seems to be a bug in how PetitParser handles >>> PPFailure return values. The actually reported error is always different >>> from what is passed to PPFailure. I love software ;-) >> >> What do you mean? > > If I return > > PPFailure message: 'whatever' at: 0 > > from my parser, then it does fail but it reports a different error. > > After some more experiments, it looks like this is perhaps not a bug, > but a feature that makes returning failures not so useful after all. I > suspect that PetitParser simply backtracks after my failure and tries a > different rule that then fails as well. > > A simple example: > > | p | > p := #digit asParser plus flatten > ==> [ :value | value asSet size = 1 ifTrue: [ value ] ifFalse: [ PPFailure message: 'not equal' at: 0 ]]. > p parse: '22233' > > The reported failure is "digit expected at 5". > > On the other hand, if there is no path for backtracking, the reported > failure is the expected one: > > | p | > p := (#digit asParser, #digit asParser) flatten > ==> [ :value | value first = value second ifTrue: [ value ] ifFalse: [ PPFailure message: 'not equal' at: 0 ]]. > p parse: '23' > > Konrad. -- www.feenk.com "Quality cannot be an afterthought."

Jan. 29, 2019

Re: [Pharo-users] Fwd: startup error in windows 10

by Hilaire

I asked the user to send me the PharoDebug.log to have a more accurate feedback: http://forum.drgeo.eu/file/n4025537/PharoDebug.log Of course I should make him to test with a newer VM to see if the problem is gone, but it is a bitÂ more complicate. Are the video info necessary? The image world starts just fine. Hilaire Le 28/01/2019 Ã 23:34, Ben Coman a Ã©critÂ : > To provide the best chance for someone to help, can you provide: > * base Image version > * vm version > * systeminfo.exe (stripped of personally identifying data) > Â Â * with dates added to hotfixes from > (https://www.tenforums.com/tutorials/5472-view-windows-update-history-window…) > * video info from (wmic path win32_VideoController get /all > /format:htable >> c:\temp\graphics.html) -- Dr. Geo http://drgeo.eu

Jan. 29, 2019

Re: [Pharo-users] PetitParser question

by Konrad Hinsen

Tudor Girba <tudor(a)tudorgirba.com> writes: > But, does it solve your problem? Not yet. Not sure it will. >> More generally, there seems to be a bug in how PetitParser handles >> PPFailure return values. The actually reported error is always different >> from what is passed to PPFailure. I love software ;-) > > What do you mean? If I return PPFailure message: 'whatever' at: 0 from my parser, then it does fail but it reports a different error. After some more experiments, it looks like this is perhaps not a bug, but a feature that makes returning failures not so useful after all. I suspect that PetitParser simply backtracks after my failure and tries a different rule that then fails as well. A simple example: | p | p := #digit asParser plus flatten ==> [ :value | value asSet size = 1 ifTrue: [ value ] ifFalse: [ PPFailure message: 'not equal' at: 0 ]]. p parse: '22233' The reported failure is "digit expected at 5". On the other hand, if there is no path for backtracking, the reported failure is the expected one: | p | p := (#digit asParser, #digit asParser) flatten ==> [ :value | value first = value second ifTrue: [ value ] ifFalse: [ PPFailure message: 'not equal' at: 0 ]]. p parse: '23' Konrad.

Jan. 29, 2019

Re: [Pharo-users] PetitParser question

by Tudor Girba

Hi, > On Jan 29, 2019, at 6:31 PM, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > Hi Doru, > > Thanks for pointing out the use case in XML, which gave me an > opportunity to play around with this with almost no > effort. Unfortunately there seems to be a bug in how PPXmlParser > constructs the PPFailure message > (freshly reported: > https://github.com/moosetechnology/PetitParser/issues/38) Yes, I saw it. I mostly pointed you to the example. We originally built PPXmlParser as an example, and not so much as a production parser. But, does it solve your problem? > More generally, there seems to be a bug in how PetitParser handles > PPFailure return values. The actually reported error is always different > from what is passed to PPFailure. I love software ;-) What do you mean? Cheers, Doru > Konrad. -- www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Jan. 29, 2019

Re: [Pharo-users] PetitParser question

by Konrad Hinsen

Hi Doru, Thanks for pointing out the use case in XML, which gave me an opportunity to play around with this with almost no effort. Unfortunately there seems to be a bug in how PPXmlParser constructs the PPFailure message (freshly reported: https://github.com/moosetechnology/PetitParser/issues/38) More generally, there seems to be a bug in how PetitParser handles PPFailure return values. The actually reported error is always different from what is passed to PPFailure. I love software ;-) Konrad.

Jan. 29, 2019