November 2017 - Pharo-users

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

by Alistair Grant

Hi Sean, On 15 November 2017 at 23:04, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Alistair Grant wrote >> Sorry for making you do all the work > > Not at all; happy to help. It takes a village! BTW I tracked it down to the > spaces in the command path. IIRC from my OSP hacking days, it probably has > something to do with the path not being run through the shell to interpret > the $\s. I'm glad (and relieved :-)) to hear that it is working. Would you mind sending the modified command path that you're using so I can update the code? (I guess that it is just removing the backspaces, but just in case...). Thanks! Alistair

Nov. 15, 2017

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

by Sean P. DeNigris

Alistair Grant wrote > Sorry for making you do all the work Not at all; happy to help. It takes a village! BTW I tracked it down to the spaces in the command path. IIRC from my OSP hacking days, it probably has something to do with the path not being run through the shell to interpret the $\s. ----- 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

Richard Sargent wrote > I would go a little further. Any method modified by the developer during > the course of running a test voids the ability to claim the test > succeeded. > Likewise, for any object editted in an inspector. That makes sense to me. ----- 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 Denis Kudriashov

2017-11-15 17:16 GMT+01:00 Richard Sargent < richard.sargent(a)gemtalksystems.com>: > And in this thread only Richard was against current logic. >> > > I am against colouring it green without having run the test without > interruption or error. I don't think that is the current logic. > Fix is already in Pharo 7. So it is current logic now. And it was same for manual halt (instead of failure). > > On Wed, Nov 15, 2017 at 2:41 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2017-11-15 11:08 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>> On Wed, Nov 15, 2017 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com >>> > wrote: >>> >>>> >>>> >>>> 2017-11-15 11:00 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com> >>>> : >>>> >>>>> And just putting it back to gray? As "not run"? >>>>> >>>> >>>> We can implement any logic. >>>> Personally I need current behaviour. >>>> >>> >>> But it is not about you personally. It is about implementing the most >>> common and the less strange for newcomers. >>> >> >> To know what is the most common case people should tell personal opinion. >> And in this thread only Richard was against current logic. >> >> >>> >>> >>>> >>>> >>>>> >>>>> On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov < >>>>> dionisiydk(a)gmail.com> wrote: >>>>> >>>>>> 2017-11-15 1:49 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>> >>>>>>> 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? >>>>>>> >>>>>> >>>>>> Except that sometimes we are debugging slow test and running it >>>>>> second time automatically after "proceed" can be not appropriate. >>>>>> We are talking about single test run. If user have any doubts about >>>>>> result It is his responsibility to rerun the test. User knows what he is >>>>>> doing when he debug and fix the test. No intelligence is required here. >>>>>> >>>>>> And anyway current fix just provides consistent behaviour to >>>>>> debugging from explicit breakpoint/halt. In that case the result was always >>>>>> in sync with debug session. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> ----- >>>>>>> Cheers, >>>>>>> Sean >>>>>>> -- >>>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> 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> >>> >> >> >

Nov. 15, 2017

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

by Richard Sargent

> > I think that setting the button back to gray is a good behaviour. > - it is the same thing that happens once you modify a method (which is > what is happening during debugging) > - it explicitly says "please rerun the test because you may have > introduced side effects" > I would go a little further. Any method modified by the developer during the course of running a test voids the ability to claim the test succeeded. Likewise, for any object editted in an inspector. In other words, if the test run was interrupted, it cannot be considered successful. Keep things simple. (as simple as possible) On Wed, Nov 15, 2017 at 2:49 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > > > On Wed, Nov 15, 2017 at 11:41 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2017-11-15 11:08 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>> On Wed, Nov 15, 2017 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com >>> > wrote: >>> >>>> >>>> >>>> 2017-11-15 11:00 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com> >>>> : >>>> >>>>> And just putting it back to gray? As "not run"? >>>>> >>>> >>>> We can implement any logic. >>>> Personally I need current behaviour. >>>> >>> >>> But it is not about you personally. It is about implementing the most >>> common and the less strange for newcomers. >>> >> >> To know what is the most common case people should tell personal opinion. >> And in this thread only Richard was against current logic. >> > > But you're assuming here that: > - people that is not reading this email do not care and don't have a say > - so pleople that is not subscribed to the mailing list don't care > - and that includes newbies > > Our role of experienced guys it not only look after "our" best defaults. > But also after the defaults of people without experience. > > I think that setting the button back to gray is a good behaviour. > - it is the same thing that happens once you modify a method (which is > what is happening during debugging) > - it explicitly says "please rerun the test because you may have > introduced side effects" > > Unless you make the debugger more intelligent, you cannot be sure that the > result you obtained at the end of the test is really reproducible. And > moreover, to be able to make such assumption you should be an expert that > understands how the underlying framework behaves. > > >> >> >>> >>> >>>> >>>> >>>>> >>>>> On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov < >>>>> dionisiydk(a)gmail.com> wrote: >>>>> >>>>>> 2017-11-15 1:49 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>> >>>>>>> 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? >>>>>>> >>>>>> >>>>>> Except that sometimes we are debugging slow test and running it >>>>>> second time automatically after "proceed" can be not appropriate. >>>>>> We are talking about single test run. If user have any doubts about >>>>>> result It is his responsibility to rerun the test. User knows what he is >>>>>> doing when he debug and fix the test. No intelligence is required here. >>>>>> >>>>>> And anyway current fix just provides consistent behaviour to >>>>>> debugging from explicit breakpoint/halt. In that case the result was always >>>>>> in sync with debug session. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> ----- >>>>>>> Cheers, >>>>>>> Sean >>>>>>> -- >>>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> 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> >>> >> >> > > > -- > > > > 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> >

Nov. 15, 2017

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

by Richard Sargent

> > And in this thread only Richard was against current logic. > I am against colouring it green without having run the test without interruption or error. I don't think that is the current logic. On Wed, Nov 15, 2017 at 2:41 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-11-15 11:08 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >> On Wed, Nov 15, 2017 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> >>> >>> 2017-11-15 11:00 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>>> And just putting it back to gray? As "not run"? >>>> >>> >>> We can implement any logic. >>> Personally I need current behaviour. >>> >> >> But it is not about you personally. It is about implementing the most >> common and the less strange for newcomers. >> > > To know what is the most common case people should tell personal opinion. > And in this thread only Richard was against current logic. > > >> >> >>> >>> >>>> >>>> On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov < >>>> dionisiydk(a)gmail.com> wrote: >>>> >>>>> 2017-11-15 1:49 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>> >>>>>> 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? >>>>>> >>>>> >>>>> Except that sometimes we are debugging slow test and running it second >>>>> time automatically after "proceed" can be not appropriate. >>>>> We are talking about single test run. If user have any doubts about >>>>> result It is his responsibility to rerun the test. User knows what he is >>>>> doing when he debug and fix the test. No intelligence is required here. >>>>> >>>>> And anyway current fix just provides consistent behaviour to debugging >>>>> from explicit breakpoint/halt. In that case the result was always in sync >>>>> with debug session. >>>>> >>>>> >>>>>> >>>>>> >>>>>> ----- >>>>>> Cheers, >>>>>> Sean >>>>>> -- >>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> 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> >> > >

Nov. 15, 2017

Typical Pharo Application Footprint

by horrido

What is a typical Pharo application footprint size? (I'm assuming deployment starting with a minimal core image.) How small can a Pharo application be? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 15, 2017

[ANN] Lifeware upgraded to Platinum Membership

by Marcus Denker

The Pharo Consortium is very happy to announce that Lifeware has upgraded to Platinum Member status. About - Lifeware: http://www.lifeware.ch - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Nov. 15, 2017

Re: [Pharo-users] UFFI C basic types passed-by-reference for output

by Esteban Lorenzano

> On 15 Nov 2017, at 09:36, Ben Coman <btc(a)openInWorld.com> wrote: > > > > > On 15 November 2017 at 17:27, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > > On 15 Nov 2017, at 02:05, Ben Coman <btc(a)openInWorld.com> wrote: > > > > 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 > > no, that will not work :) > what you need to do here is to pass a âbufferâ to contain the width and height: > > testGetPageSizeByIndex > | document page_index widthBuffer heightBuffer width height result| > PDFium FPDF_InitLibrary. > document := PDFium FPDF_LoadDocument__file_path: helloPdf password: ''. > widthBuffer := ByteArray new: (FFIFloat64 typeSize). > heightBuffer := ByteArray new: (FFIFloat64 typeSize). > > Thanks Esteban. That worked. However I needed a minor tweak... > widthBuffer := ByteArray new: (FFIFloat64 new typeSize). > or... > widthBuffer := ByteArray new: (FFIFloat64 externalTypeSize). > > > Now it would be nice to do... > widthBuffer := FFIFloat64 newBuffer. you know, I thought the same :) but since Iâm officially on holiday I didnât do it (yet). If you want to add an issue and send a PR, it would be perfect :) > > which could be implemented... > FFIExternalType class >> newBuffer. > ^ByteArray new: (self externalTypeSize) > > testGetPageSizeByIndex > | document page_index widthBuffer heightBuffer width height result| > PDFium FPDF_InitLibrary. > document := PDFium FPDF_LoadDocument__file_path: helloPdf password: ''. > widthBuffer := FFIFloat64 buffer. > heightBuffer := FFIFloat64 buffer. > page_index := 0. "Its zero based" > result := PDFium FPDF_GetPageSizeByIndex__document: document > page_index: 0 > width: widthBuffer > height: heightBuffer. > width := widthBuffer doubleAt: 1. > height := heightBuffer doubleAt: 1. > > > > btw, a broader curiousity even though this is likely set in stone and not even your personal choice - why "FFIFloat64" and not "FFIDouble" ? > widthBuffer := FFIDouble newBuffer. > would be a nice match to the callout declaration. because the ABI defines float64 as the right name, heh. and yes, it was not my personal choice ;) > > Would it be overkill to have in Pharo an empty FFIDouble subclassed from FFIFloat64 ? > the superclass being explicit about the format, while the subclass provides a nice identifier for users? maybe it is overkilling. Because alsoâ¦ where do you put the limit? (doubles, floats, longs, etcâ¦ ?) Esteban > > > page_index := 0. "Its zero based" > result := PDFium FPDF_GetPageSizeByIndex__document: document > page_index: 0 > width: widthBuffer > height: heightBuffer. > width := widthBuffer doubleAt: 1. > height := heightBuffer doubleAt: 1. > 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. > > side note: I do not recommend using the UFFI type in declarations. In the long way is worst for comprehension and maintainability. This thingy: > > ^self ffiCall: #(int FPDF_GetPageSizeByIndex( > FPDF_DOCUMENT *document, > int page_index, > FFIFloat64 * width, > FFIFloat64 * height)) > > would be better as in original version: > > ^self ffiCall: #(int FPDF_GetPageSizeByIndex( > FPDF_DOCUMENT *document, > int page_index, > double * width, > double * height)) > > Thanks for the heads up. > > cheers -ben

Nov. 15, 2017

Re: [Pharo-users] UFFI C basic types passed-by-reference for output

by Ben Coman

On 15 November 2017 at 17:27, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > On 15 Nov 2017, at 02:05, Ben Coman <btc(a)openInWorld.com> wrote: > > > > 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 > > no, that will not work :) > what you need to do here is to pass a âbufferâ to contain the width and > height: > > testGetPageSizeByIndex > | document page_index widthBuffer heightBuffer width height result| > PDFium FPDF_InitLibrary. > document := PDFium FPDF_LoadDocument__file_path: helloPdf > password: ''. > widthBuffer := ByteArray new: (FFIFloat64 typeSize). > heightBuffer := ByteArray new: (FFIFloat64 typeSize). > Thanks Esteban. That worked. However I needed a minor tweak... widthBuffer := ByteArray new: (FFIFloat64 new typeSize). or... widthBuffer := ByteArray new: (FFIFloat64 externalTypeSize). Now it would be nice to do... widthBuffer := FFIFloat64 newBuffer. which could be implemented... FFIExternalType class >> newBuffer. ^ByteArray new: (self externalTypeSize) testGetPageSizeByIndex | document page_index widthBuffer heightBuffer width height result| PDFium FPDF_InitLibrary. document := PDFium FPDF_LoadDocument__file_path: helloPdf password: ''. widthBuffer := FFIFloat64 buffer. heightBuffer := FFIFloat64 buffer. page_index := 0. "Its zero based" result := PDFium FPDF_GetPageSizeByIndex__document: document page_index: 0 width: widthBuffer height: heightBuffer. width := widthBuffer doubleAt: 1. height := heightBuffer doubleAt: 1. btw, a broader curiousity even though this is likely set in stone and not even your personal choice - why "FFIFloat64" and not "FFIDouble" ? widthBuffer := FFIDouble newBuffer. would be a nice match to the callout declaration. Would it be overkill to have in Pharo an empty FFIDouble subclassed from FFIFloat64 ? the superclass being explicit about the format, while the subclass provides a nice identifier for users? > page_index := 0. "Its zero based" > result := PDFium FPDF_GetPageSizeByIndex__document: document > page_index: 0 > width: widthBuffer > height: heightBuffer. > width := widthBuffer doubleAt: 1. > height := heightBuffer doubleAt: 1. 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. > > side note: I do not recommend using the UFFI type in declarations. In the > long way is worst for comprehension and maintainability. This thingy: > > ^self ffiCall: #(int FPDF_GetPageSizeByIndex( > FPDF_DOCUMENT *document, > int page_index, > FFIFloat64 * width, > FFIFloat64 * height)) > > would be better as in original version: > > ^self ffiCall: #(int FPDF_GetPageSizeByIndex( > FPDF_DOCUMENT *document, > int page_index, > double * width, > double * height)) > Thanks for the heads up. cheers -ben

Nov. 15, 2017