November 2017 - Pharo-users

Re: [Pharo-users] Pharo-Chrome (was: Soup bug(fix))

by Alistair Grant

Hi Offray, On 15 November 2017 at 00:18, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi Alistair, > > The example is not working for me. When I run it, a chrome session is > open but nothing happens there, except that my image gets frozen until I > close chrome and then I get this message: "ConnectionTimedOut: Cannot > connect to 127.0.0.1:9222". What is the expected behavior? I'm not sure why this is happening. Chrome only allows one instance per profile to be running, however the example should be creating its own profile (which is what is done when GoogleChrome>>debugSession is sent). Can you check that the profile directory is being created: /tmp/pharo/GoogleChrome/debugSession/ Also, you should have several processes running, similar to: alistair 11001 6953 3 07:34 pts/19 00:00:57 /opt/google/chrome/chrome --user-data-dir=/tmp/pharo/GoogleChrome/debugSession --remote-debugging-port=9222 alistair 11005 11001 0 07:34 pts/19 00:00:00 /opt/google/chrome/chrome --type=zygote --enable-crash-reporter=9472c7b5-b817-49a9-a2df-266ef87a1707,unknown --user-data-dir=/tmp/pharo/GoogleChrome/debugSession alistair 11009 11005 0 07:34 pts/19 00:00:00 /opt/google/chrome/chrome --type=zygote --enable-crash-reporter=9472c7b5-b817-49a9-a2df-266ef87a1707,unknown --user-data-dir=/tmp/pharo/GoogleChrome/debugSession alistair 11193 11009 6 07:35 pts/19 00:01:51 /opt/google/chrome/chrome --type=renderer --field-trial-handle=13786453131923986905,2801831905294320914,131072 --service-pipe-token=4E2DA31A2AA7D6D8585A99928CABF01B --lang=en-GB --enable-crash-reporter=9472c7b5-b817-49a9-a2df-266ef87a1707,unknown --user-data-dir=/tmp/pharo/GoogleChrome/debugSession --enable-offline-auto-reload --enable-offline-auto-reload-visible-only --enable-pinch --num-raster-threads=2 --enable-main-frame-before-activation --content-image-texture-target=(lots of numbers removed) You can see that the first process has the separate profile (--user-data-dir) and remote debugging enabled. The last process listed above is the one rendering the page (I ran GoogleChrome class>>exampleNavigation to get this). Maybe as a last resort you could try ensuring that no other instances of chrome are running before you try the example. > PharoChrome > expects the user to have a Google account or be logged in by default to > work (that would be a shame for those of us that don't a Google account > and still value our privacy). No, by default it won't be logged in (since it is creating a separate profile). Thanks, Alistair > Thanks, > > Offray

Nov. 15, 2017

Re: [Pharo-users] About suggestions on Pillar editor (was Re: [ann] pillar text editor)

by Tudor Girba

There are two presentations (tabs): - âContents' shows the plain file - âPillarâ shows the syntax highlighting. Can you check? Doru > On Nov 14, 2017, at 9:57 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Thanks Doru, > > Installation works, but syntax hightligthning and image preview are > disabled. I don't know if this is because is the same image with the > installation of GT Documenter, installed. > > Cheers, > > Offray > > > On 14/11/17 12:15, Tudor Girba wrote: >> Hi, >> >> Please retry again by loading the #development version in Pharo 6.1: >> >> Gofer new >> smalltalkhubUser: 'Pier' project: 'Pillar'; >> configuration; >> loadDevelopment. >> >> You should get the extension out of the box. >> >> Please let me know if it works. >> >> Cheers, >> Doru >> >> >>> On Nov 14, 2017, at 5:55 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>> >>> Hi, >>> >>> A suggestion from one year ago. Should be this converted into issues? >>> >>> Cheers, >>> >>> Offray >>> >>> On 10/10/16 13:26, Offray Vladimir Luna CÃ¡rdenas wrote: >>>> Hi Doru, >>>> >>>> I was exploring Stephan Eggermont's code Panel because the zooming in/out behavior implemented there, but I would like to add your Pillar text editor to the exploration. >>>> I would like to add two things: >>>> >>>> 1. Font decrease/increase buttons/shorcuts, because for long documents, default font size can be tiresome. >>>> >>>> 2. Augmenting the amount of syntax highlighting languages, starting with markdown. I think that this would be strategic in making writing inside the image, more appealing, giving the spread of markdown as a documentation syntax in different context (GitHub, Scholar markdown, wikis, discussion, Slack clones, etc). >>>> I installed the extension today on a Pharo 5 system, but trying to use it, bring me the error detailed at the end of this mail, so after having it working on Pharo, I would like to explore/help in implementing items 1 and 2, avove. >>>> >>>> Cheers, >>>> >>>> Offray >>>> >>>> Error report >>>> =========== >>>> Author: OffrayLuna >>>> >>>> Array(Object)>>shouldNotImplement >>>> Array(ArrayedCollection)>>add: >>>> [ :each | self add: each ] in Array(Collection)>>addAll: >>>> Array(SequenceableCollection)>>do: >>>> Array(Collection)>>addAll: >>>> [ :array | >>>> ({array first} >>>> addAll: array last; >>>> yourself) >>>> collect: [ :each | >>>> ('' join: each first) >>>> -> (each second ifNotNil: [ :second | '' join: second ]) ] ] in GTPillarHighlighter>>scriptParameters >>>> PPActionParser>>parseOn: >>>> PPDelegateParser>>parseOn: >>>> PPSequenceParser>>parseOn: >>>> PPActionParser>>parseOn: >>>> PPDelegateParser>>parseOn: >>>> PPChoiceParser>>parseOn: >>>> PPDelegateParser>>parseOn: >>>> PPChoiceParser>>parseOn: >>>> PPPossessiveRepeatingParser>>parseOn: >>>> PPDelegateParser>>parseOn: >>>> PPEndOfInputParser>>parseOn: >>>> GTPillarHighlighter(PPDelegateParser)>>parseOn: >>>> GTPillarHighlighter(PPParser)>>parseWithContext: >>>> GTPillarHighlighter(PPParser)>>parse:withContext: >>>> GTPillarHighlighter(PPParser)>>parse: >>>> GTPillarHighlighterTextDecorator>>parse:onError: >>>> GLMHighlighterTextParserStyler>>privateStyle: >>>> [ self privateStyle: text. >>>> view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ backgroundProcess := [ self privateStyle: text. >>>> view ifNotNil: [ view stylerStyledInBackground: text ] ] >>>> forkAt: Processor userBackgroundPriority ] in GLMHighlighterTextParserStyler(SHTextStyler)>>styleInBackgroundProcess: >>>> [ self value. >>>> Processor terminateActive ] in BlockClosure>>newProcess >>>> =============== >>>> >>>> On 09/10/16 16:23, Tudor Girba wrote: >>>>> Hi, >>>>> >>>>> Pillar now ships with a text editor that also features a syntax highlighter. >>>>> >>>>> So, now, if you load the development version of Pillar: >>>>> >>>>> Gofer new >>>>> smalltalkhubUser: 'Pier' project: 'Pillar'; >>>>> configuration; >>>>> loadDevelopment. >>>>> >>>>> You will have an extra presentation when inspecting a .pillar file: >>>>> >>>>> <gjkebecengkghnjk.png> >>>>> >>>>> The new thing here is that the highlighter is based on the Pillar PetitParser, and it is extensible for highlighting more parts if needed. The highlighting also can support actions. For example, the picture above shows the file to the right after clicking on the reference. >>>>> >>>>> Please take a look and let me know what you think. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "Things happen when they happen, >>>>> not when you talk about them happening." >>>>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "We are all great at making mistakes." >> >> >> >> >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Nov. 15, 2017

UFFI C basic types passed-by-reference for output

by Ben Coman

What is the recommended way for a C basic type to be passed-by-reference to function wanting to use it for output. For example 'width' & 'height' here in this library unction... int FPDF_GetPageSizeByIndex(FPDF_DOCUMENT document, int page_index, double* width, double* height); void mytestGetPageSizeByIndex(doc) { double width, height; FPDF_GetPageSizeByIndex(doc, 0, &width, &height); printf("width=%f, height=%f\n", width, height); } gives... width=200.000000, height=200.000000 In Pharo I'm trying... FFIOpaqueObject subclass: #FPDF_DOCUMENT FPDF_GetPageSizeByIndex__document: document page_index: page_index width: width height: height ^self ffiCall: #(int FPDF_GetPageSizeByIndex( FPDF_DOCUMENT *document, int page_index, FFIFloat64 * width, FFIFloat64 * height)) testGetPageSizeByIndex | document page_index width height result| PDFium FPDF_InitLibrary. document := PDFium FPDF_LoadDocument__file_path: helloPdf password: ''. width := 0.0. height := 0.0. page_index := 0. "Its zero based" result := PDFium FPDF_GetPageSizeByIndex__document: document page_index: 0 width: width height: height. PDFium FPDF_CloseDocument__document: document. PDFium FPDF_DestroyLibrary. self assert: document isNull not. "Document opened okay, and btw this works for a different pageCount test" self assert: result > 0. "Non-zero for success. 0 for error (document or page not found)" self halt. and at the halt the Inspector shows... result = 1 width = 0.0 height = 0.0 cheers -ben

Nov. 15, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Stephan Eggermont

Op 15-11-2017 om 01:49 schreef Sean P. DeNigris: > Again, it seems that just automatically rerunning the test immediately after > a human-manipulated run and setting the color based on that second run > addresses all points on both sides, no? How many times do you want to restart execution? I have writen enough code where running it twice was not enough to get to green :) Stephan

Nov. 15, 2017

Re: [Pharo-users] Pharo-Chrome (was: Soup bug(fix))

by Mariano Martinez Peck

If this is a problem with OSSubprocess I am happy to help it debug it, but please share with me the exact steps to reproduce it and which code to look at. And which OS and which Pharo. And it should be 32 bits (OSSubprocess doesn't work on 64 yet) Thanks, On Tue, Nov 14, 2017 at 9:47 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Alistair Grant wrote > > This looks like you are using an old (cached?) version. > > Ugh, yes. I just deleted the local clone and let Iceberg reclone. > > Now when I tried: > `GoogleChrome get: > 'https://finance.yahoo.com/quote/%5EAXJO/history?p=%5EAXJO'` > I got: > Error: Error: posix_spawn(), code: 2, description: No such file or > directory > Even though pasting the command into Terminal successfully launched Chrome. > > BTW I had to insert a leading / to into the executable location. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- Mariano http://marianopeck.wordpress.com

Nov. 15, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Richard Sargent

> > Again, it seems that just automatically rerunning the test immediately > after a human-manipulated run and setting the color based on that second run > Absolutely! (Although, I was kind of looking forward to the third colour discussions. My vote would have been for paisley!) On Tue, Nov 14, 2017 at 4:49 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Ben Coman wrote > > Or it could go to Amber, half-way between green & red to mean probably > > correct. > > Ha ha. > > Again, it seems that just automatically rerunning the test immediately > after > a human-manipulated run and setting the color based on that second run > addresses all points on both sides, no? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Nov. 15, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Sean P. DeNigris

Ben Coman wrote > Or it could go to Amber, half-way between green & red to mean probably > correct. Ha ha. Again, it seems that just automatically rerunning the test immediately after a human-manipulated run and setting the color based on that second run addresses all points on both sides, no? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 15, 2017

Re: [Pharo-users] Pharo-Chrome (was: Soup bug(fix))

by Sean P. DeNigris

Alistair Grant wrote > This looks like you are using an old (cached?) version. Ugh, yes. I just deleted the local clone and let Iceberg reclone. Now when I tried: `GoogleChrome get: 'https://finance.yahoo.com/quote/%5EAXJO/history?p=%5EAXJO'` I got: Error: Error: posix_spawn(), code: 2, description: No such file or directory Even though pasting the command into Terminal successfully launched Chrome. BTW I had to insert a leading / to into the executable location. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 15, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Ben Coman

On 15 November 2017 at 00:14, Richard Sargent <rsargent(a)5x5.on.ca> wrote: > >> I would expect it to turn green if I press resume. > > I disagree with your expectations. You are arguing that we should operate > is if "probably correct" is the same as "correct". That's why we have > ****ty software. > > I have no objection to leaving the method uncoloured when you resume after > correcting the error. > I have no objection to eliminating the red colouring in these scenarios. > I strongly object to pretending that it is known to be correct. > Or it could go to Amber, half-way between green & red to mean probably correct. cheers -ben > > > In my experience, we end up with better results when we act on what we > absolutely know to be factual and stop relying on guessing. > > > ------------------------------ > *From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] *On > Behalf Of *Tim Mackinnon > *Sent:* November 14, 2017 06:19 > *To:* Any question about pharo is welcome > *Subject:* Re: [Pharo-users] Why does the test runner show red when I > correct a test? > > Richard - I better understand what you are saying now. If you change the > method and save it (hence restarting on the stack) I would expect it to > turn green if I press resume. That is the TDD flow I expect, and one which > sunit and coding in the debugger was predicated on. > > However, there is the potential that some memory object that cached a > result and is now running a second time could be the cause of a pass and so > it is remotely possible that this is a false passâ¦. (And this I think is > the crux of your argument - if any memory object is affected, theoretically > you should rerun the whole transaction from a virgin state - which is > effectively rerun the test from the beginning). So I guess we are > discussing that we donât have fully transactional memory executions? > > However I would argue that its way more common that you edit a method and > fix a text and have 0 side effects than mucking around in memory or having > something that rerunning locally messes up memory as well. So its much more > useful to get the confirmation of green and move on. YES you could have a > subtle error, and when you re-run it may later go red - but I would favour > the 99% case as its a annoying if you are doing TDD. > > Tim > > On 10 Nov 2017, at 19:45, Richard Sargent <richard.sargent@ > gemtalksystems.com> wrote: > > I hear you and I understand your pain. > > However, if you corrected the problem, not by a code change, but by > playing in the object's inspector or otherwise causing its internal state > to change, and then resumed from the debugger, would you still claim the > method was successful and should be coloured green? > > The only thing we can claim is that there were or were not further errors > in the test. Colour it red if there were, but you cannot honestly colour it > green. The code doesn't actually work. > > > On Fri, Nov 10, 2017 at 11:29 AM, Tim Mackinnon <tim(a)testit.works> wrote: > >> My specific usecase is from a pragmatic TDD perspective - failing test, >> in the debugger you fix the test and press proceed - expecting green. >> Getting red, and then immediately running again to get red takes away from >> our story of love coding and loving your debugger - and even Cassie me to >> mistrust the tools. >> >> I get the idea that you can jiffy in the debugger and cause a false pass >> - but I feel you are penalised for doing it right at the moment. >> >> Of course these tests will get run again, but I like the idea that if I >> did it right, it should recognise this, not incur an extra click and moment >> of doubt. >> >> A button to rerun the whole lot, or automatically rerun, or just run it >> would work for me. >> >> Tim >> >> Sent from my iPhone >> >> On 10 Nov 2017, at 17:56, Richard Sargent <richard.sargent@gemtalksystem >> s.com> wrote: >> >> That would be fine. >> The point is that, without running the test in its entirety, from start >> to finish, without interruption, error, or failure, one cannot claim >> success. >> >> On Fri, Nov 10, 2017 at 9:34 AM, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >> >>> Richard Sargent wrote >>> > The only reliable conclusion one can make from such an interrupted run >>> is >>> > whether it failed again. So, it would be possible to determine that the >>> > test should be coloured red, but it is impossible to *reliably* claim >>> that >>> > the test should be coloured green. >>> >>> What if we ran the test again as if from the browser/runner before >>> setting >>> the icon? >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> >> > >

Nov. 15, 2017

Re: [Pharo-users] FFI 64 bit libClang issue on Sierra.

by Ben Coman

On 15 November 2017 at 00:07, Todd Blanchard <tblanchard(a)mac.com> wrote: > I've got it loaded, have fixed up the library path and fixed the test for > version (built in lib returns very different version string). > > I have many tests green. However, as before, tests involving > CXSourceRange that return CXSourceLocations return all zero'd data. The > CXSourceRange struct looks sane. > > The calls to CXSourceLocation clang_getRangeStart(CXSourceRange range); > > and its twin RangeEnd result in zero'd structs. > > Any idea on where I can look to try to figure out where this is going > wrong? > > I have compiled little C programs and verified that both struct sizes > agree in FFI and native code (24 bytes each). > > Not sure what to try next. > c > -Todd Blanchard > Compile your own debug-VM** and make a little C wrapper MyCXSourceRange to forward to Clang's CXSourceRange, and set a gdb a breakpoint in MyCXSourceRange and compare 64 bit and 32 bit versions. That still leaves differences in the callout before your breakpoint in MyCXSourceRange is reached, so just do two callouts in a row and trace from the first to the second. ** https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/build.linux64x64… cheers -ben

Nov. 15, 2017