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

[Alistair Grant]

Hi Sean,

Sorry (and to Offray) for the trouble, but thanks for persevering.

On 15 November 2017 at 01:47, Sean P. DeNigris  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.

Would you mind setting a breakpoint in
AKGOSProcess>>command:arguments:, printing the command and arguments
and making sure that the --user-data-dir exists?  (I'm not familiar
with MacOS and am wondering if maybe there is some sandboxing causing
trouble).

Also, as Mariano requested, can you confirm that it is MacOS, which
version of Pharo, and a 32 bit VM?

Thanks,
Alistair

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

[Richard Sargent]

I would say that is an entirely different question. If a test isn't stable,
you have a completely different scenario from a test that interrupts
execution and is resumed.

On Nov 14, 2017 20:45, "Stephan Eggermont"  wrote:

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

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

[Alistair Grant]

Hi Offray,

On 15 November 2017 at 00:18, Offray Vladimir Luna Cárdenas
 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

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

[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 
>  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 
>>>  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:
> 
> 
> 
> 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 

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

[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, , );
printf("width=%f, height=%f\n", width, height);
}

gives...
   width=200.00, height=200.00



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

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

[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

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

[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 
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

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

[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 
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
>
>

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

[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

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

[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

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

[Ben Coman]

On 15 November 2017 at 00:14, Richard Sargent  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-boun...@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  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  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 > 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 
>> 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
>>>
>>>
>>
>
>

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

[Ben Coman]

On 15 November 2017 at 00:07, Todd Blanchard  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/pharo.cog.spur/build.debug

cheers -ben

Re: [Pharo-users] FFIExternalEnumeration int versus long

[Ben Coman]

On 15 November 2017 at 00:17, Todd Blanchard  wrote:

> Yeah, I don't know if that is necessarily worth doing TBH.
>
> Generally enumerations are going to be default int size unless you have
> values that are out of range.
>
> In this case you have a function that returns a long.  In a strictly typed
> language you would be required to do a type cast anyhow.
>
> If this were done in Swift, you'd have to do something heinous like
>
> FPDF_ERR.fromRaw(FPDF_GetLastError()) // older Swift
> FPDF_ERR(rawValue: FPDF_GetLastError())
>
> even C++ would require you cast from unsigned long to the enum type.
>
> So, to me, it makes sense with this kind of api that you'd have to
> explicitly convert in the method that does the ffiCall:, get the result,
> then look up the proper enum.
>

To clarify, in this case its not a technical enumeration in the C header to
be passed around the library, just a bunch of 10 defines for error return
values.  Initially I was thinking of doing it in Pharo as an enumeration
just because they are numbers, but the GetLastError() function return type
was 'long' so it made me curious.Now I've reevaluated I think it will
work better to create a Error class to raise for each return value.

Thanks for your thoughts.
cheers -ben


>
> On Nov 14, 2017, at 2:44 AM, Esteban Lorenzano 
> wrote:
>
> right now FFIExternalEnumeration support int32 and uint32 types, but I
> think is not hard to create a FFIExternalLongEnumeration or whatever is
> need.
>
> FFIExternalEnumeration >> initializeEnumeration, however, could be better
> refactored, I admit ;)
>
> On 13 Nov 2017, at 23:41, Ben Coman  wrote:
>
> I have a C definition...
>   unsigned long FPDF_GetLastError();
>
> whose return values are...
>   #define FPDF_ERR_SUCCESS 0// No error.
>   #define FPDF_ERR_UNKNOWN 1// Unknown error.
>   #define FPDF_ERR_FILE 2   // File not found or could not be opened.
>   #define FPDF_ERR_FORMAT 3 // File not in PDF format or corrupted.
>   #define FPDF_ERR_PASSWORD 4   // Password required or incorrect
>  password.
>   #define FPDF_ERR_SECURITY 5   // Unsupported security scheme.
>   #define FPDF_ERR_PAGE 6   // Page not found or content error.
>
> I was thinking of turning those #define's into an FFIExternalEnumeration,
> but I was wondering if I'll hit some undefined behaviour with the
> underlying representation being a "long" rather than an "int" ?
>
> I do see here that C enumerations can be a range of types including "long"
> * https://stackoverflow.com/questions/7093360/c-sharp-enum-of-long-values
> but I'm not sure how it works in the Pharo context to know what the size
> underlying representation.
>
> cheers -ben
>
>
>
>

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

[Offray Vladimir Luna Cárdenas]

The last was a question :-P Is PharoChrome expecting to be logged in to
some Google account to work?

Cheers,

Offray


On 14/11/17 18:18, Offray Vladimir Luna Cárdenas 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? 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).
>
> Thanks,
>
> Offray
>
>
> On 14/11/17 11:26, Alistair Grant wrote:
>> I've committed some fixes to the development branch:
>>
>> 1. MacOS hopefully works now (I don't have access to the platform, so
>> can't test it).
>> 2. The development version of Beacon is loaded (which is required for
>> the InMemoryLogger).
>> 3. The README is a tiny bit better.
>> 4. Added #extractTables.
>>
>> As an example of how historical stock market data can be extracted,
>> the following retrieves data for the Australian S index from
>> yahoo:
>>
>>
>> | rootNode tables historicalData dataFrame |
>>
>> rootNode := GoogleChrome get:
>> 'https://finance.yahoo.com/quote/%5EAXJO/history?p=%5EAXJO'.
>> tables := rootNode extractTables.
>> historicalData := (tables sorted: #size ascending) last.
>> dataFrame := DataFrame fromRows: (historicalData select: [ :each |
>> each size = 7 ]).
>> dataFrame asStringTable.
>>
>> "
>>  |  1 2 3 4 5 6
>> 7
>> -+-
>> 1|  Date  Open  High  Low   Close*Adj
>> Close**  Volume
>> 2|  Nov 14, 2017  6,021.80  6,021.80  5,957.10  5,966.00  5,966.00
>> -
>> 3|  Nov 13, 2017  6,029.40  6,029.40  6,010.70  6,021.80  6,021.80
>> -
>> 4|  Nov 10, 2017  6,049.40  6,049.40  6,020.70  6,029.40  6,029.40
>> -
>> etc.
>> "
>>
>>
>> To load the development version on MacOS or Linux in a 32 bit image:
>>
>> "Assuming you don't have OSProcess loaded:"
>> Metacello new
>> configuration: 'OSSubprocess';
>> repository: 'github://marianopeck/OSSubprocess:master/repository';
>> version: #stable;
>> load.
>>
>> Metacello new
>> baseline: 'Chrome';
>> repository: 'github://akgrant43/Pharo-Chrome:development/repository';
>> load.
>>
>>
>> Cheers,
>> Alistair
>>
>>
>> On 12 November 2017 at 20:09, Alistair Grant  wrote:
>>> Hi Sean,
>>>
>>> Thanks for your feedback!  (responses below)
>>>
>>>
>>> On 12 November 2017 at 18:11, Sean P. DeNigris  
>>> wrote:
 Alistair Grant wrote
> https://github.com/akgrant43/Pharo-Chrome
 Wow, that was a wild ride!
>>> Sorry about that.
>>>
>>>
 Lessons learned along the way:
 1. On a Mac, to use the snazzy `chrome` terminal command referenced all 
 over
 the place in the docs, you must first `alias chrome="/Applications/Google\
 Chrome.app/Contents/MacOS/Google\ Chrome"`
>>> I'm an Ubuntu Linux user, however if you look at OSXChromePlatform
>>> class>>defaultExecutableLocation you can see that is where it should
>>> be looking for the exe, so the alias shouldn't really be necessary.
>>> Torsten wrote this, so maybe has more insight.
>>>
>>>
 2. Chrome must be started with certain flags: `chrome
 --remote-debugging-port=9222 --disable-gpu` (not sure if the last flag is
 needed, but `#get:` seemed to hang before using; reference
 https://developers.google.com/web/updates/2017/04/headless-chrome)
>>> I've been using this without headless mode.  I'll add a headless flag
>>> that also disables the gpu.
>>>
>>>
>>>
 3. Beacon has renamed InMemoryLogger to MemoryLogger
 4. I guess Beacon has renamed `#log` to `#emit`
>>> Sorry about that.  I didn't realise that the Pharo-Chrome baseline is
>>> loading Beacon stable while my install script upgrades it to
>>> #development.  #development is more recent, so I'll update the
>>> baseline.
>>>
>>>
>>>
 5. I had to comment out `chromeProcess sigterm.` because `chromeProcess` 
 was
 nil and also #sigterm seemed not to be defined anywhere in the image. I'm
 not sure what the issue is there.
>>> chromeProcess is set in GoogleChrome>>openURL:.  Can you give me a
>>> small example that demonstrates the problem?
>>>
>>> #sigterm is implemented by OSSUnixSubprocess, which is what I
>>> ultimately use to launch the Chrome process on Ubuntu.
>>>
>>> But... this will be broken on Mac at the moment because the current
>>> method of launching chrome doesn't keep track of the process, so
>>> doesn't support #sigterm.  Do you know if OSSUnixSubprocess works on
>>> Mac?  If it does, I can update the code (but not test it :-().
>>>
>>>
 Pull request issued for #3 & #4.
>>> Once I update 

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

[Offray Vladimir Luna Cárdenas]

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? 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).

Thanks,

Offray


On 14/11/17 11:26, Alistair Grant wrote:
> I've committed some fixes to the development branch:
>
> 1. MacOS hopefully works now (I don't have access to the platform, so
> can't test it).
> 2. The development version of Beacon is loaded (which is required for
> the InMemoryLogger).
> 3. The README is a tiny bit better.
> 4. Added #extractTables.
>
> As an example of how historical stock market data can be extracted,
> the following retrieves data for the Australian S index from
> yahoo:
>
>
> | rootNode tables historicalData dataFrame |
>
> rootNode := GoogleChrome get:
> 'https://finance.yahoo.com/quote/%5EAXJO/history?p=%5EAXJO'.
> tables := rootNode extractTables.
> historicalData := (tables sorted: #size ascending) last.
> dataFrame := DataFrame fromRows: (historicalData select: [ :each |
> each size = 7 ]).
> dataFrame asStringTable.
>
> "
>  |  1 2 3 4 5 6
> 7
> -+-
> 1|  Date  Open  High  Low   Close*Adj
> Close**  Volume
> 2|  Nov 14, 2017  6,021.80  6,021.80  5,957.10  5,966.00  5,966.00
> -
> 3|  Nov 13, 2017  6,029.40  6,029.40  6,010.70  6,021.80  6,021.80
> -
> 4|  Nov 10, 2017  6,049.40  6,049.40  6,020.70  6,029.40  6,029.40
> -
> etc.
> "
>
>
> To load the development version on MacOS or Linux in a 32 bit image:
>
> "Assuming you don't have OSProcess loaded:"
> Metacello new
> configuration: 'OSSubprocess';
> repository: 'github://marianopeck/OSSubprocess:master/repository';
> version: #stable;
> load.
>
> Metacello new
> baseline: 'Chrome';
> repository: 'github://akgrant43/Pharo-Chrome:development/repository';
> load.
>
>
> Cheers,
> Alistair
>
>
> On 12 November 2017 at 20:09, Alistair Grant  wrote:
>> Hi Sean,
>>
>> Thanks for your feedback!  (responses below)
>>
>>
>> On 12 November 2017 at 18:11, Sean P. DeNigris  wrote:
>>> Alistair Grant wrote
 https://github.com/akgrant43/Pharo-Chrome
>>> Wow, that was a wild ride!
>> Sorry about that.
>>
>>
>>> Lessons learned along the way:
>>> 1. On a Mac, to use the snazzy `chrome` terminal command referenced all over
>>> the place in the docs, you must first `alias chrome="/Applications/Google\
>>> Chrome.app/Contents/MacOS/Google\ Chrome"`
>> I'm an Ubuntu Linux user, however if you look at OSXChromePlatform
>> class>>defaultExecutableLocation you can see that is where it should
>> be looking for the exe, so the alias shouldn't really be necessary.
>> Torsten wrote this, so maybe has more insight.
>>
>>
>>> 2. Chrome must be started with certain flags: `chrome
>>> --remote-debugging-port=9222 --disable-gpu` (not sure if the last flag is
>>> needed, but `#get:` seemed to hang before using; reference
>>> https://developers.google.com/web/updates/2017/04/headless-chrome)
>> I've been using this without headless mode.  I'll add a headless flag
>> that also disables the gpu.
>>
>>
>>
>>> 3. Beacon has renamed InMemoryLogger to MemoryLogger
>>> 4. I guess Beacon has renamed `#log` to `#emit`
>> Sorry about that.  I didn't realise that the Pharo-Chrome baseline is
>> loading Beacon stable while my install script upgrades it to
>> #development.  #development is more recent, so I'll update the
>> baseline.
>>
>>
>>
>>> 5. I had to comment out `chromeProcess sigterm.` because `chromeProcess` was
>>> nil and also #sigterm seemed not to be defined anywhere in the image. I'm
>>> not sure what the issue is there.
>> chromeProcess is set in GoogleChrome>>openURL:.  Can you give me a
>> small example that demonstrates the problem?
>>
>> #sigterm is implemented by OSSUnixSubprocess, which is what I
>> ultimately use to launch the Chrome process on Ubuntu.
>>
>> But... this will be broken on Mac at the moment because the current
>> method of launching chrome doesn't keep track of the process, so
>> doesn't support #sigterm.  Do you know if OSSUnixSubprocess works on
>> Mac?  If it does, I can update the code (but not test it :-().
>>
>>
>>> Pull request issued for #3 & #4.
>> Once I update the baseline this shouldn't be required.
>>
>>
>>> Also, I'm not sure what platforms you
>>> support, but you may want to tag the example methods with  or
>>> similar so that they are runnable from the browser and open an inspector if
>>> there is an interesting return value.
>> Good idea, I'll do this.
>>
>> I'm also making a few 

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

[Offray Vladimir Luna Cárdenas]

OK, the development branch solve this, as shown in
http://ws.stfx.eu/O6J4CJ1FZF89. Now I'm getting an unresponsive image
until I close Chrome, but I think that was talked in the thread. I'll
revise.

Cheers,

Offray


On 14/11/17 17:28, Offray Vladimir Luna Cárdenas wrote:
> Hi Alistar,
>
> I have tried to run the examples, but seems that installation doesn't
> include all needed package. At the beginning I installed OSUnix and then
> OSLinuxUbuntu. None of them seems to include "AKGOSProcess", so the
> "GoogleChrome get: 'http://pharo.org'" example raises:
> "#command:arguments: was sent to nil". What package provides the proper
> installation for a 64 bits Manjaro Linux including the dependencies?
>
> Thanks,
>
> Offray
>
>
> On 14/11/17 13:14, Alistair Grant wrote:
>> On 14 November 2017 at 19:13, Alistair Grant  wrote:
>>> Hi Sean,
>>>
>>> On 14 November 2017 at 19:06, Sean P. DeNigris  
>>> wrote:
 Alistair Grant wrote
> I've committed some fixes to the development branch:
 Thanks!

 I tried your example, but apparently the OSXProcess class, which is
 referenced in openChromeWith: is missing. Also, no class in the image seems
 to define #createProcess:, which is sent to OSXProcess there
>>> This looks like you are using an old (cached?) version.  Maybe try
>>> "Pull incoming commits" from Iceberg?
>>>
>>> You should have (minus the broken formatting from pasting):
>>>
>>>
>>> OSXChromePlatform>>openChromeWith: arguments
>>>
>>> | executableLocation process |
>>> executableLocation := self defaultExecutableLocation copyReplaceAll: '
>>> ' with: '\ '.
>>> process := AKGOSProcess command: executableLocation arguments: arguments.
>>> process run.
>>> ^process
>> P.S. Don't forget this is on the development branch.
>>
>> Cheers,
>> Alistair
>>
>>
>
>
>

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

[Offray Vladimir Luna Cárdenas]

Hi Alistar,

I have tried to run the examples, but seems that installation doesn't
include all needed package. At the beginning I installed OSUnix and then
OSLinuxUbuntu. None of them seems to include "AKGOSProcess", so the
"GoogleChrome get: 'http://pharo.org'" example raises:
"#command:arguments: was sent to nil". What package provides the proper
installation for a 64 bits Manjaro Linux including the dependencies?

Thanks,

Offray


On 14/11/17 13:14, Alistair Grant wrote:
> On 14 November 2017 at 19:13, Alistair Grant  wrote:
>> Hi Sean,
>>
>> On 14 November 2017 at 19:06, Sean P. DeNigris  wrote:
>>> Alistair Grant wrote
 I've committed some fixes to the development branch:
>>> Thanks!
>>>
>>> I tried your example, but apparently the OSXProcess class, which is
>>> referenced in openChromeWith: is missing. Also, no class in the image seems
>>> to define #createProcess:, which is sent to OSXProcess there
>> This looks like you are using an old (cached?) version.  Maybe try
>> "Pull incoming commits" from Iceberg?
>>
>> You should have (minus the broken formatting from pasting):
>>
>>
>> OSXChromePlatform>>openChromeWith: arguments
>>
>> | executableLocation process |
>> executableLocation := self defaultExecutableLocation copyReplaceAll: '
>> ' with: '\ '.
>> process := AKGOSProcess command: executableLocation arguments: arguments.
>> process run.
>> ^process
>
> P.S. Don't forget this is on the development branch.
>
> Cheers,
> Alistair
>
>

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

[Offray Vladimir Luna Cárdenas]

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 
>>  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:

 

 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."
>
>
>
>
>
>
>
>
>
>

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

[Alistair Grant]

On 14 November 2017 at 19:13, Alistair Grant  wrote:
> Hi Sean,
>
> On 14 November 2017 at 19:06, Sean P. DeNigris  wrote:
>> Alistair Grant wrote
>>> I've committed some fixes to the development branch:
>>
>> Thanks!
>>
>> I tried your example, but apparently the OSXProcess class, which is
>> referenced in openChromeWith: is missing. Also, no class in the image seems
>> to define #createProcess:, which is sent to OSXProcess there
>
> This looks like you are using an old (cached?) version.  Maybe try
> "Pull incoming commits" from Iceberg?
>
> You should have (minus the broken formatting from pasting):
>
>
> OSXChromePlatform>>openChromeWith: arguments
>
> | executableLocation process |
> executableLocation := self defaultExecutableLocation copyReplaceAll: '
> ' with: '\ '.
> process := AKGOSProcess command: executableLocation arguments: arguments.
> process run.
> ^process


P.S. Don't forget this is on the development branch.

Cheers,
Alistair

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

[Alistair Grant]

Hi Sean,

On 14 November 2017 at 19:06, Sean P. DeNigris  wrote:
> Alistair Grant wrote
>> I've committed some fixes to the development branch:
>
> Thanks!
>
> I tried your example, but apparently the OSXProcess class, which is
> referenced in openChromeWith: is missing. Also, no class in the image seems
> to define #createProcess:, which is sent to OSXProcess there

This looks like you are using an old (cached?) version.  Maybe try
"Pull incoming commits" from Iceberg?

You should have (minus the broken formatting from pasting):


OSXChromePlatform>>openChromeWith: arguments

| executableLocation process |
executableLocation := self defaultExecutableLocation copyReplaceAll: '
' with: '\ '.
process := AKGOSProcess command: executableLocation arguments: arguments.
process run.
^process


HTH,
Alistair

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

[Sean P. DeNigris]

Alistair Grant wrote
> I've committed some fixes to the development branch:

Thanks!

I tried your example, but apparently the OSXProcess class, which is
referenced in openChromeWith: is missing. Also, no class in the image seems
to define #createProcess:, which is sent to OSXProcess there



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Offray Vladimir Luna Cárdenas]

Thanks both, Alex and Doru for your quick answers. I'm using Manjaro
Cinnamon Edition[1]. If you need any help with 32 bits over 64 bits
systems, let me know.

[1] https://manjaro.org/community-editions/

Cheers,

Offray


On 14/11/17 12:46, Aliaksei Syrel wrote:
> Offray, which edition of Manjaro do you have? (XFCE, KDE or Gnome)
>
> Cheers,
> Alex
>
> On 14 November 2017 at 18:41, Aliaksei Syrel  > wrote:
>
> Hi Offray,
>
> I agree with your point of view. It is in our best interests to
> make it work as smoothly as possible, ideally automagically :)
> Now I will try to install Pharo6.1 on Manjaro Linux in order to
> see if there is something that needs to be noted in README.md.
>
> One of the biggest problems on linux for me is installation of
> 32bit libs on 64 bit distro. That is why I will test 64bit Pharo
> on 64bit Manjaro Linux with Moz2D and without it.
> I will let you know
>
> Cheers,
> Alex
>
> On 14 November 2017 at 18:25, Offray Vladimir Luna Cárdenas
> > wrote:
>
> Alex,
>
> I understand that frustration on installation could be
> motivated by other issues instead of GT Documenter, but if the
> team ask to use "|Iceberg enableMetacelloIntegration: true."
> |in the project readme, where it also says that is supported
> for Pharo 6.1 and 7.0, is natural to think that something is
> wrong with documentation and/or in the project's expectations
> about its intended users and their will to invest the effort,
> time and motivation for "living in the edge". I understand
> that if we want stuff to be improved it should be tested, but
> also that not all the people that is willing to test stuff for
> Pharo 6.1 needs to live in such edge. Or the project is
> sending a message that is not giving the bests firsts
> impressions, or is going to users which are not intended . I
> would go for a smooth install first and then for collaboration
> with git. I'll make a pull request with the proposal for a
> better documentation, but my understanding about how you can
> go from the first (user of GT Documenter) to the second
> (developer using Git integration) is not clear.
>
> GT Tools has been pretty empowering. I have told that several
> times and I don't think that I have wrote a single line of
> code in their repos. But is getting more difficult just to
> test and use them and I think that is related with the idea
> that my user *needs* to be also my co-developer, starting with
> their ssh git key pair. If we don't make easier to contribute
> by just making easier to install, there will be no evolution
> either.
>
> Cheers,
>
> Offray
>
>
> On 14/11/17 11:45, Aliaksei Syrel wrote:
>> Hi Offray,
>>
>> I understand your frustration, but with all respect, the fact
>> that you have problems with Iceberg does not mean that GT
>> Documenter or any other GT tool is responsible for described
>> problems.
>>
>> Most complains about bloc, brick, whatever is because of
>> unrelated stuff. It is a little bit disappointing. Especially
>> for me, as one of the maintainers. But it is ok, I got used
>> to it :)
>>
>> I don’t remember when last time I used stable Pharo (not
>> because it does not exist), simply live on the edge since
>> Pharo4. If no one will use Git and report problems Iceberg
>> will never progress. If no one will use Bloc it will never
>> get “there”. Unfortunately, living on the edge is dangerous,
>> requires effort, motivation and time.
>>
>> The script that Doru provided works flawlessly on OSX, we
>> load it almost everyday. !! Bloc is tested on CI and builds
>> are green on Windows, Linux and OSX !!. If computer (CI)
>> manages to install it, I am pretty sure human can do it too.
>> Looks like there is something missing in your configuration,
>> something tiny :) Error handling in Iceberg can be definitely
>> improved, but it is a different story.
>>
>> P.S. Documenter can be installed without enabled Iceberg
>> integration. This is how CI does it. You will just not be
>> able to contribute.
>>
>> Cheers,
>> Alex
>>
>> On Tue, 14 Nov 2017 at 16:37, Offray Vladimir Luna Cárdenas
>> > wrote:
>>
>> I have been just trying to install GT Documenter and is
>> really frustrating (I have been unable to install it even
>> for the first time!).
>>
>> This was the list of errors I 

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Aliaksei Syrel]

Offray, which edition of Manjaro do you have? (XFCE, KDE or Gnome)

Cheers,
Alex

On 14 November 2017 at 18:41, Aliaksei Syrel  wrote:

> Hi Offray,
>
> I agree with your point of view. It is in our best interests to make it
> work as smoothly as possible, ideally automagically :)
> Now I will try to install Pharo6.1 on Manjaro Linux in order to see if
> there is something that needs to be noted in README.md.
>
> One of the biggest problems on linux for me is installation of 32bit libs
> on 64 bit distro. That is why I will test 64bit Pharo on 64bit Manjaro
> Linux with Moz2D and without it.
> I will let you know
>
> Cheers,
> Alex
>
> On 14 November 2017 at 18:25, Offray Vladimir Luna Cárdenas <
> offray.l...@mutabit.com> wrote:
>
>> Alex,
>>
>> I understand that frustration on installation could be motivated by other
>> issues instead of GT Documenter, but if the team ask to use "Iceberg
>> enableMetacelloIntegration: true." in the project readme, where it also
>> says that is supported for Pharo 6.1 and 7.0, is natural to think that
>> something is wrong with documentation and/or in the project's expectations
>> about its intended users and their will to invest the effort, time and
>> motivation for "living in the edge". I understand that if we want stuff to
>> be improved it should be tested, but also that not all the people that is
>> willing to test stuff for Pharo 6.1 needs to live in such edge. Or the
>> project is sending a message that is not giving the bests firsts
>> impressions, or is going to users which are not intended . I would go for a
>> smooth install first and then for collaboration with git. I'll make a pull
>> request with the proposal for a better documentation, but my understanding
>> about how you can go from the first (user of GT Documenter) to the second
>> (developer using Git integration) is not clear.
>>
>> GT Tools has been pretty empowering. I have told that several times and I
>> don't think that I have wrote a single line of code in their repos. But is
>> getting more difficult just to test and use them and I think that is
>> related with the idea that my user *needs* to be also my co-developer,
>> starting with their ssh git key pair. If we don't make easier to contribute
>> by just making easier to install, there will be no evolution either.
>>
>> Cheers,
>>
>> Offray
>>
>> On 14/11/17 11:45, Aliaksei Syrel wrote:
>>
>> Hi Offray,
>>
>> I understand your frustration, but with all respect, the fact that you
>> have problems with Iceberg does not mean that GT Documenter or any other GT
>> tool is responsible for described problems.
>>
>> Most complains about bloc, brick, whatever is because of unrelated stuff.
>> It is a little bit disappointing. Especially for me, as one of the
>> maintainers. But it is ok, I got used to it :)
>>
>> I don’t remember when last time I used stable Pharo (not because it does
>> not exist), simply live on the edge since Pharo4. If no one will use Git
>> and report problems Iceberg will never progress. If no one will use Bloc it
>> will never get “there”. Unfortunately, living on the edge is dangerous,
>> requires effort, motivation and time.
>>
>> The script that Doru provided works flawlessly on OSX, we load it almost
>> everyday. !! Bloc is tested on CI and builds are green on Windows, Linux
>> and OSX !!. If computer (CI) manages to install it, I am pretty sure human
>> can do it too. Looks like there is something missing in your configuration,
>> something tiny :) Error handling in Iceberg can be definitely improved, but
>> it is a different story.
>>
>> P.S. Documenter can be installed without enabled Iceberg integration.
>> This is how CI does it. You will just not be able to contribute.
>>
>> Cheers,
>> Alex
>>
>> On Tue, 14 Nov 2017 at 16:37, Offray Vladimir Luna Cárdenas <
>> offray.l...@mutabit.com> wrote:
>>
>>> I have been just trying to install GT Documenter and is really
>>> frustrating (I have been unable to install it even for the first time!).
>>>
>>> This was the list of errors I got and steps I followed, in almost
>>> sequential order, just to get a (bittersweet!) taste of GT Documenter:
>>>
>>>- 1st: LGit_GIT_ERROR: No ssh-agent suitable credentials found. So I
>>>go to GitHub, follow the five pages of documentation to get my SSH
>>>credentials that start at [1], then, because I still get the same error, 
>>> go
>>>to the Iceberg FAQ [2], try to surpass the erro,r via command line and
>>>doesn't work, so I go to the Iceberg settings and try the manual
>>>configuration, going to the next item
>>>
>>>[1] https://help.github.com/articles/generating-a-new-ssh-key-an
>>>d-adding-it-to-the-ssh-agent/#generating-a-new-ssh-key
>>>
>>> 
>>>[2] https://github.com/pharo-vcs/iceberg/blob/master/README.md
>>>
>>>- Now I get "Instance of LGitCredentialsSSH 

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Aliaksei Syrel]

Hi Offray,

I agree with your point of view. It is in our best interests to make it
work as smoothly as possible, ideally automagically :)
Now I will try to install Pharo6.1 on Manjaro Linux in order to see if
there is something that needs to be noted in README.md.

One of the biggest problems on linux for me is installation of 32bit libs
on 64 bit distro. That is why I will test 64bit Pharo on 64bit Manjaro
Linux with Moz2D and without it.
I will let you know

Cheers,
Alex

On 14 November 2017 at 18:25, Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> Alex,
>
> I understand that frustration on installation could be motivated by other
> issues instead of GT Documenter, but if the team ask to use "Iceberg
> enableMetacelloIntegration: true." in the project readme, where it also
> says that is supported for Pharo 6.1 and 7.0, is natural to think that
> something is wrong with documentation and/or in the project's expectations
> about its intended users and their will to invest the effort, time and
> motivation for "living in the edge". I understand that if we want stuff to
> be improved it should be tested, but also that not all the people that is
> willing to test stuff for Pharo 6.1 needs to live in such edge. Or the
> project is sending a message that is not giving the bests firsts
> impressions, or is going to users which are not intended . I would go for a
> smooth install first and then for collaboration with git. I'll make a pull
> request with the proposal for a better documentation, but my understanding
> about how you can go from the first (user of GT Documenter) to the second
> (developer using Git integration) is not clear.
>
> GT Tools has been pretty empowering. I have told that several times and I
> don't think that I have wrote a single line of code in their repos. But is
> getting more difficult just to test and use them and I think that is
> related with the idea that my user *needs* to be also my co-developer,
> starting with their ssh git key pair. If we don't make easier to contribute
> by just making easier to install, there will be no evolution either.
>
> Cheers,
>
> Offray
>
> On 14/11/17 11:45, Aliaksei Syrel wrote:
>
> Hi Offray,
>
> I understand your frustration, but with all respect, the fact that you
> have problems with Iceberg does not mean that GT Documenter or any other GT
> tool is responsible for described problems.
>
> Most complains about bloc, brick, whatever is because of unrelated stuff.
> It is a little bit disappointing. Especially for me, as one of the
> maintainers. But it is ok, I got used to it :)
>
> I don’t remember when last time I used stable Pharo (not because it does
> not exist), simply live on the edge since Pharo4. If no one will use Git
> and report problems Iceberg will never progress. If no one will use Bloc it
> will never get “there”. Unfortunately, living on the edge is dangerous,
> requires effort, motivation and time.
>
> The script that Doru provided works flawlessly on OSX, we load it almost
> everyday. !! Bloc is tested on CI and builds are green on Windows, Linux
> and OSX !!. If computer (CI) manages to install it, I am pretty sure human
> can do it too. Looks like there is something missing in your configuration,
> something tiny :) Error handling in Iceberg can be definitely improved, but
> it is a different story.
>
> P.S. Documenter can be installed without enabled Iceberg integration. This
> is how CI does it. You will just not be able to contribute.
>
> Cheers,
> Alex
>
> On Tue, 14 Nov 2017 at 16:37, Offray Vladimir Luna Cárdenas <
> offray.l...@mutabit.com> wrote:
>
>> I have been just trying to install GT Documenter and is really
>> frustrating (I have been unable to install it even for the first time!).
>>
>> This was the list of errors I got and steps I followed, in almost
>> sequential order, just to get a (bittersweet!) taste of GT Documenter:
>>
>>- 1st: LGit_GIT_ERROR: No ssh-agent suitable credentials found. So I
>>go to GitHub, follow the five pages of documentation to get my SSH
>>credentials that start at [1], then, because I still get the same error, 
>> go
>>to the Iceberg FAQ [2], try to surpass the erro,r via command line and
>>doesn't work, so I go to the Iceberg settings and try the manual
>>configuration, going to the next item
>>
>>[1] https://help.github.com/articles/generating-a-new-ssh-key-
>>and-adding-it-to-the-ssh-agent/#generating-a-new-ssh-key
>>
>> 
>>[2] https://github.com/pharo-vcs/iceberg/blob/master/README.md
>>
>>- Now I get "Instance of LGitCredentialsSSH class did not understand
>>#ifTrue:ifFalse:". I try to make sense of it in the debugger, but is
>>something I cannot. Anyway, I rerun it and now I get: LGit_GIT_EEXISTS:
>>
>> '/home/offray/Programas/Pharo/6.1a/Dev24/pharo-local/iceberg/feenkcom/gtoolkit'
>>

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Offray Vladimir Luna Cárdenas]

Hi Doru,


On 14/11/17 11:36, Tudor Girba wrote:
> Hi Offray,
>
> There are two issues that I take from your email. So, please allow me to 
> address them separately:
>
> 1. The process of installing the new GT (with Documenter)
> GT is meant to load in Pharo 6.1. It is tested tested automatically several 
> times a day both on Windows (Appveyor) and on Linux (Travis CI), and we load 
> it automatically on Mac when we develop. Other people managed to load it as 
> well. That does not mean that there are no problems, but it does mean that 
> there are no problems that we are aware of. So, we need to understand what 
> the issue is.
> From your email I understand that you are using Pharo 6.1. Is it the latest 
> image and VM?

This is what about says: "Pharo 6.0 Latest update: #60510", but is Pharo
6.1. I don't know if that gives any info on the VM or how to get it.

> What is the operating system?

Manjaro Linux

> What is the exact loading snippet that you used?

The one in the thread I'm answering. Is the same in the Readme fro
gtoolkit. https://github.com/feenkcom/gtoolkit

> Now, please bare in mind that GT relies on the common way of organizing 
> GitHub projects. So, what you describe seems to have to do with Iceberg, not 
> with GT. For example, did you manage to load any other Pharo project from 
> GitHub?
>
> 2. There is something about silence which I do not understand. I do not 
> remember a particular question that you asked and you got no answer to. If 
> there was one, I am sorry. Please repost it.

I have done. Was about giving feedback to the Pillar editor. But also
happened at the beginning when I tried to get feedback on the Moose
list. In fact I prefer to post questions here. There is a lot of overlap
between both lists, but here I have a better answers ratio.

Cheers,

Offray

Re: [Pharo-users] Stream API

[Stephane Ducasse]

Sven

>From the thread discussion here my take.

- I do not think that we want to reuse any of the old streams.
- So first Zn to replace the binary and MultiUglyStream and after we
will have to check
if we should port the design of Xtream (but not the API) to Pharo.

Stef

On Tue, Nov 14, 2017 at 5:59 PM, Stephane Ducasse
 wrote:
> Denis I agree. I do not like to code in reverse order.
>
>
> On Tue, Nov 14, 2017 at 4:49 PM, Denis Kudriashov  
> wrote:
>> 2017-11-14 16:30 GMT+01:00 Steffen Märcker :
>>>
>>> I forgot to mention, that the most recent code for Pharo is already on
>>> Github: https://github.com/Pharophile/Transducers
>>>
>>> Reducers was the name of the first very first implementation.
>>>
>>> (In fact, I was originally inspired by clojures Reducers lib. After
>>> implementing it in Smalltalk, I developed the concept further. Later I found
>>> out, that the clojure guys did the same in parallel and ended up with the
>>> same abstraction but a differnt name. Hence I decided change the name in
>>> order to make the relation clear.)
>>
>>
>> I like abstraction. But I think names and order of computation should be
>> changed to be more Smalltalk friendly. Because now it looks like Haskell
>> with right to left order:
>>
>> squares := Set <~ 1000 take <~ #squared map <~ (1 to: 1000).
>> fileOut writeStream <~ #isSeparator filter <~ fileIn readStream.
>>
>>
>> Is there any reason to not change it? I would like to start expressions with
>> source of data:
>>
>> squares := (1 to: 1000) ~> #squared map ~> 1000 take ~> Set.
>> fileIn readStream ~> #isSeparator filter ~> fileOut writeStream.
>>
>>
>>
>>>
>>> Am .11.2017, 16:18 Uhr, schrieb Sven Van Caekenberghe :
>>>


> On 14 Nov 2017, at 16:00, Steffen Märcker  wrote:
>
> Hi,
>
>>> <---Schnitt--->
>
>
> No. Transducers is my side project. I've implemented a package for
> VisualWorks. Unfortunately, I did not finish the port to Pharo yet, simply
> due to a lack of time. Originally, transducers evolved in the clojure
> community. I figured, the concept a good fit for Smalltalk and adapted it
> accordingly. (My thesis is on conditional probabilities in model-checking 
> of
> probabilistic systems.)
>
>>> <---Schnitt--->
>>>
>
> http://www.cincomsmalltalk.com/publicRepository/Transducers.html
> https://clojure.org/reference/transducers
> Plus some mails on this list and more on the vwnc list. Feel free to
> ask; I understand, that the package comment has lots of potential for
> improvement to help understanding.
>
> Best, Steffen


 Some code seems to be here: http://smalltalkhub.com/#!/~cdlm/Experiments

 Not sure if it is complete or what the relation is, or the difference
 between transducers and reducers ...


>>>
>>>
>>>
>>

Re: [Pharo-users] Stream API

[Stephane Ducasse]

Denis I agree. I do not like to code in reverse order.


On Tue, Nov 14, 2017 at 4:49 PM, Denis Kudriashov  wrote:
> 2017-11-14 16:30 GMT+01:00 Steffen Märcker :
>>
>> I forgot to mention, that the most recent code for Pharo is already on
>> Github: https://github.com/Pharophile/Transducers
>>
>> Reducers was the name of the first very first implementation.
>>
>> (In fact, I was originally inspired by clojures Reducers lib. After
>> implementing it in Smalltalk, I developed the concept further. Later I found
>> out, that the clojure guys did the same in parallel and ended up with the
>> same abstraction but a differnt name. Hence I decided change the name in
>> order to make the relation clear.)
>
>
> I like abstraction. But I think names and order of computation should be
> changed to be more Smalltalk friendly. Because now it looks like Haskell
> with right to left order:
>
> squares := Set <~ 1000 take <~ #squared map <~ (1 to: 1000).
> fileOut writeStream <~ #isSeparator filter <~ fileIn readStream.
>
>
> Is there any reason to not change it? I would like to start expressions with
> source of data:
>
> squares := (1 to: 1000) ~> #squared map ~> 1000 take ~> Set.
> fileIn readStream ~> #isSeparator filter ~> fileOut writeStream.
>
>
>
>>
>> Am .11.2017, 16:18 Uhr, schrieb Sven Van Caekenberghe :
>>
>>>
>>>
 On 14 Nov 2017, at 16:00, Steffen Märcker  wrote:

 Hi,

>> <---Schnitt--->


 No. Transducers is my side project. I've implemented a package for
 VisualWorks. Unfortunately, I did not finish the port to Pharo yet, simply
 due to a lack of time. Originally, transducers evolved in the clojure
 community. I figured, the concept a good fit for Smalltalk and adapted it
 accordingly. (My thesis is on conditional probabilities in model-checking 
 of
 probabilistic systems.)

>> <---Schnitt--->
>>

 http://www.cincomsmalltalk.com/publicRepository/Transducers.html
 https://clojure.org/reference/transducers
 Plus some mails on this list and more on the vwnc list. Feel free to
 ask; I understand, that the package comment has lots of potential for
 improvement to help understanding.

 Best, Steffen
>>>
>>>
>>> Some code seems to be here: http://smalltalkhub.com/#!/~cdlm/Experiments
>>>
>>> Not sure if it is complete or what the relation is, or the difference
>>> between transducers and reducers ...
>>>
>>>
>>
>>
>>
>

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Stephane Ducasse]

For git / iceberg first time users:
Please read the tip and tricks booklet available on http://books.pharo.org

On Tue, Nov 14, 2017 at 5:45 PM, Aliaksei Syrel  wrote:
> Hi Offray,
>
> I understand your frustration, but with all respect, the fact that you have
> problems with Iceberg does not mean that GT Documenter or any other GT tool
> is responsible for described problems.
>
> Most complains about bloc, brick, whatever is because of unrelated stuff. It
> is a little bit disappointing. Especially for me, as one of the maintainers.
> But it is ok, I got used to it :)
>
> I don’t remember when last time I used stable Pharo (not because it does not
> exist), simply live on the edge since Pharo4. If no one will use Git and
> report problems Iceberg will never progress. If no one will use Bloc it will
> never get “there”. Unfortunately, living on the edge is dangerous, requires
> effort, motivation and time.
>
> The script that Doru provided works flawlessly on OSX, we load it almost
> everyday. !! Bloc is tested on CI and builds are green on Windows, Linux and
> OSX !!. If computer (CI) manages to install it, I am pretty sure human can
> do it too. Looks like there is something missing in your configuration,
> something tiny :) Error handling in Iceberg can be definitely improved, but
> it is a different story.
>
> P.S. Documenter can be installed without enabled Iceberg integration. This
> is how CI does it. You will just not be able to contribute.
>
> Cheers,
> Alex
>
> On Tue, 14 Nov 2017 at 16:37, Offray Vladimir Luna Cárdenas
>  wrote:
>>
>> I have been just trying to install GT Documenter and is really frustrating
>> (I have been unable to install it even for the first time!).
>>
>> This was the list of errors I got and steps I followed, in almost
>> sequential order, just to get a (bittersweet!) taste of GT Documenter:
>>
>> 1st: LGit_GIT_ERROR: No ssh-agent suitable credentials found. So I go to
>> GitHub, follow the five pages of documentation to get my SSH credentials
>> that start at [1], then, because I still get the same error, go to the
>> Iceberg FAQ [2], try to surpass the erro,r via command line and doesn't
>> work, so I go to the Iceberg settings and try the manual configuration,
>> going to the next item
>>
>> [1]
>> https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/#generating-a-new-ssh-key
>> [2] https://github.com/pharo-vcs/iceberg/blob/master/README.md
>>
>> Now I get "Instance of LGitCredentialsSSH class did not understand
>> #ifTrue:ifFalse:". I try to make sense of it in the debugger, but is
>> something I cannot. Anyway, I rerun it and now I get: LGit_GIT_EEXISTS:
>> '/home/offray/Programas/Pharo/6.1a/Dev24/pharo-local/iceberg/feenkcom/gtoolkit'
>> exists and is not an empty directory. I delete that directory and try an
>> installation... again
>> Now I get: "Instance of FileReference did not understand #notEmpty". I try
>> to make sense of it in the debugger. My user is git, my public and private
>> ssh keys are not empty. Despite of not making sense of all I understand that
>> is trying to clone something at g...@github.com:feenkcom/gtoolkit.git. I go
>> to my image dir and then to `iceberg/feenkcom/gtoolkit/`. There is a git
>> repository there, but is empty.
>> Now I wonder, maybe if I can just clone the directory there, but how I say
>> Iceberg to load it? So I run now only the Metacello part. Same error and
>> solution that the last time but now for gtoolkit-visualizer, Brick,
>> gtoolkit-examples, Bloc and Sparta.
>> After getting my ssh keys, overcome config problems in shell and the Pharo
>> settings, chasing these errors and solving them by cloning the repositories
>> manually, I'm, a couple of hours later, ready to test GT Documenter, but
>> with the last Iceberg's duplicated repository message about Sparta I give
>> up. Is not nice to start your day accumulating frustration... that sets a
>> bad mood for the rest of it, and you need to actively fight against.
>>
>> I have thought that Git is overcomplicated for most of the developers'
>> tasks and communities. I don't know if the root of previous issues is in the
>> "Iceberg enableMetacelloIntegration: true" line, but having to get your pair
>> of keys working to just install software is overkill for the common user
>> (and when LibGit errors are present, the documented solutions don't work
>> seamlessly). Maybe a more sensitive solution would be just to use libgit,
>> without any ssh auth to clone repositories and its prerequisites or even
>> better, some download that goes to the files in the tip (or other) version
>> without all this overhead.
>>
>> Anyway, as I said, I have been unable to test GT Documenter properly and
>> getting feedback over GT Tools from the team usually requires a lot of
>> effort in my case (insisting on getting answers or getting none). And that
>> is just to test a promising tech that still doesn't offer 

Re: [Pharo-users] extending STON

[henry]

Thank you, Sven. That was a much better place for internalizing after 
reconstituting. I now have bi-directional substitutions working with STON. I’m 
grateful.

Sent from ProtonMail Mobile

On Tue, Nov 14, 2017 at 09:24, Sven Van Caekenberghe  wrote:

> Henry, > On 14 Nov 2017, at 15:02, henry wrote: > > Hello, I am trying to 
> extend STON to allow for substitutions as data is written out or read in. On 
> the write side I got it working as #nextPut: is recursively called, so that 
> is the perfect place to substitute before an object is written. I have tested 
> and my changes work well, where I have an arbitrary object as a subObject and 
> it gets substituted out for my Descriptor object. OK good. > I am having 
> difficult on the read side identifying where a substitution lookup should 
> occur after decoding the object on the input stream. I want to inflate the 
> Descritpor object, with its data, and call for a possible substitution. As it 
> is a Descriptor, it should get substituted with the right bits on the read 
> side. I chose to try and do this in the method #setReference:to: and put the 
> substitute into the objects list. This did not work. Where is a good place to 
> look within STON to do a read-side post-substitution? In 
> STONReader>>#parseObject | targetClass reference object | [ reference := self 
> newReference. targetClass := self parseClass. object := targetClass fromSton: 
> self. self setReference: reference to: object ] ... I would try just 
> re-assigning object with your custom substitute. Like this 
> MySTONReader>>#parseObject | targetClass reference object | [ reference := 
> self newReference. targetClass := self parseClass. object := targetClass 
> fromSton: self. object := object resolveSubstitution. self setReference: 
> reference to: object ] ... The references are used if the same (#==) object 
> is used twice, then you get something like STON fromString: 
> '[Point[1,2],@2]'. which is an 2 element Array where the exact same object is 
> in both positions (structure sharing). This works with circular references 
> too (but be careful because the inspector might loop). HTH, Sven > Thank you. 
> > > - HH > > @callistohouse.club>

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Aliaksei Syrel]

Hi Offray,

I understand your frustration, but with all respect, the fact that you have
problems with Iceberg does not mean that GT Documenter or any other GT tool
is responsible for described problems.

Most complains about bloc, brick, whatever is because of unrelated stuff.
It is a little bit disappointing. Especially for me, as one of the
maintainers. But it is ok, I got used to it :)

I don’t remember when last time I used stable Pharo (not because it does
not exist), simply live on the edge since Pharo4. If no one will use Git
and report problems Iceberg will never progress. If no one will use Bloc it
will never get “there”. Unfortunately, living on the edge is dangerous,
requires effort, motivation and time.

The script that Doru provided works flawlessly on OSX, we load it almost
everyday. !! Bloc is tested on CI and builds are green on Windows, Linux
and OSX !!. If computer (CI) manages to install it, I am pretty sure human
can do it too. Looks like there is something missing in your configuration,
something tiny :) Error handling in Iceberg can be definitely improved, but
it is a different story.

P.S. Documenter can be installed without enabled Iceberg integration. This
is how CI does it. You will just not be able to contribute.

Cheers,
Alex

On Tue, 14 Nov 2017 at 16:37, Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> I have been just trying to install GT Documenter and is really frustrating
> (I have been unable to install it even for the first time!).
>
> This was the list of errors I got and steps I followed, in almost
> sequential order, just to get a (bittersweet!) taste of GT Documenter:
>
>- 1st: LGit_GIT_ERROR: No ssh-agent suitable credentials found. So I
>go to GitHub, follow the five pages of documentation to get my SSH
>credentials that start at [1], then, because I still get the same error, go
>to the Iceberg FAQ [2], try to surpass the erro,r via command line and
>doesn't work, so I go to the Iceberg settings and try the manual
>configuration, going to the next item
>
>[1]
>
> https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/#generating-a-new-ssh-key
>[2] https://github.com/pharo-vcs/iceberg/blob/master/README.md
>
>- Now I get "Instance of LGitCredentialsSSH class did not understand
>#ifTrue:ifFalse:". I try to make sense of it in the debugger, but is
>something I cannot. Anyway, I rerun it and now I get: LGit_GIT_EEXISTS:
>
> '/home/offray/Programas/Pharo/6.1a/Dev24/pharo-local/iceberg/feenkcom/gtoolkit'
>exists and is not an empty directory. I delete that directory and try an
>installation... again
>- Now I get: "Instance of FileReference did not understand #notEmpty".
>I try to make sense of it in the debugger. My user is git, my public and
>private ssh keys are not empty. Despite of not making sense of all I
>understand that is trying to clone something at
>g...@github.com:feenkcom/gtoolkit.git. I go to my image dir and then to
>`iceberg/feenkcom/gtoolkit/`. There is a git repository there, but is 
> empty.
>- Now I wonder, maybe if I can just clone the directory there, but how
>I say Iceberg to load it? So I run now only the Metacello part. Same error
>and solution that the last time but now for gtoolkit-visualizer, Brick,
>gtoolkit-examples, Bloc and Sparta.
>- After getting my ssh keys, overcome config problems in shell and the
>Pharo settings, chasing these errors and solving them by cloning the
>repositories manually, I'm, a couple of hours later, ready to test GT
>Documenter, but with the last Iceberg's duplicated repository message about
>Sparta I give up. Is not nice to start your day accumulating frustration...
>that sets a bad mood for the rest of it, and you need to actively fight
>against.
>
> I have thought that Git is overcomplicated for most of the developers'
> tasks and communities. I don't know if the root of previous issues is in
> the "Iceberg enableMetacelloIntegration: true" line, but having to get your
> pair of keys working to just install software is overkill for the common
> user (and when LibGit errors are present, the documented solutions don't
> work seamlessly). Maybe a more sensitive solution would be just to use
> libgit, without any ssh auth to clone repositories and its prerequisites or
> even better, some download that goes to the files in the tip (or other)
> version without all this overhead.
>
> Anyway, as I said, I have been unable to test GT Documenter properly and
> getting feedback over GT Tools from the team usually requires a lot of
> effort in my case (insisting on getting answers or getting none). And that
> is just to test a promising tech that still doesn't offer saving features
> (just and awesome preview). I think that a more sensible approach for a
> good documentation toolkit for now is on Spec and creating custom syntax
> highlighters 

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Tudor Girba]

What operating system are you on? What version of Pharo do you use? Is it 32b 
or 64b?

Cheers,
Doru


> On Nov 14, 2017, at 5:33 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> 
> 
> On 14/11/17 10:36, Offray Vladimir Luna Cárdenas wrote:
> 
> [...]
>> I have thought that Git is overcomplicated for most of the developers'
>> tasks and communities. I don't know if the root of previous issues is
>> in the "Iceberg enableMetacelloIntegration: true" line, but having to
>> get your pair of keys working to just install software is overkill for
>> the common user (and when LibGit errors are present, the documented
>> solutions don't work seamlessly). Maybe a more sensitive solution
>> would be just to use libgit, without any ssh auth to clone
>> repositories and its prerequisites or even better, some download that
>> goes to the files in the tip (or other) version without all this
>> overhead. 
> 
> In fact, using "Iceberg enableMetacelloIntegration: false" produce a
> smoother installing experience. Putting this as the first line of the
> script doesn't help to most of the users if we want to enable easy
> feedback. Anyway, after a mostly successful installation, Moz2D
> installation failed, downloading a ~20Mb file and after that saying:
> "Moz2D library is not installed correctly. Select Proceed to continue,
> or close this window to cancel the operation." That made most of the
> examples non functional because of the lack of Moz2D or because some
> deprecation.
> 
> Any other way to install Moz2D on Manjaro/Arch Linux or to disable it an
> still be able to use Pillar preview features?
> 
> Cheers,
> 
> Offray
> 
> 

--
www.tudorgirba.com
www.feenk.com

"When people care, great things can happen."

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Tudor Girba]

Hi Offray,

There are two issues that I take from your email. So, please allow me to 
address them separately:

1. The process of installing the new GT (with Documenter)
GT is meant to load in Pharo 6.1. It is tested tested automatically several 
times a day both on Windows (Appveyor) and on Linux (Travis CI), and we load it 
automatically on Mac when we develop. Other people managed to load it as well. 
That does not mean that there are no problems, but it does mean that there are 
no problems that we are aware of. So, we need to understand what the issue is.
From your email I understand that you are using Pharo 6.1. Is it the latest 
image and VM?
What is the operating system?
What is the exact loading snippet that you used?
Now, please bare in mind that GT relies on the common way of organizing GitHub 
projects. So, what you describe seems to have to do with Iceberg, not with GT. 
For example, did you manage to load any other Pharo project from GitHub?

2. There is something about silence which I do not understand. I do not 
remember a particular question that you asked and you got no answer to. If 
there was one, I am sorry. Please repost it.

Cheers,
Doru



> On Nov 14, 2017, at 4:36 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> I have been just trying to install GT Documenter and is really frustrating (I 
> have been unable to install it even for the first time!).
> 
> This was the list of errors I got and steps I followed, in almost sequential 
> order, just to get a (bittersweet!) taste of GT Documenter:
> 
>   • 1st: LGit_GIT_ERROR: No ssh-agent suitable credentials found. So I go 
> to GitHub, follow the five pages of documentation to get my SSH credentials 
> that start at [1], then, because I still get the same error, go to the 
> Iceberg FAQ [2], try to surpass the erro,r via command line and doesn't work, 
> so I go to the Iceberg settings and try the manual configuration, going to 
> the next item
> 
> [1] 
> https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/#generating-a-new-ssh-key
> [2] https://github.com/pharo-vcs/iceberg/blob/master/README.md
> 
>   • Now I get "Instance of LGitCredentialsSSH class did not understand 
> #ifTrue:ifFalse:". I try to make sense of it in the debugger, but is 
> something I cannot. Anyway, I rerun it and now I get: LGit_GIT_EEXISTS: 
> '/home/offray/Programas/Pharo/6.1a/Dev24/pharo-local/iceberg/feenkcom/gtoolkit'
>  exists and is not an empty directory. I delete that directory and try an 
> installation... again
>   • Now I get: "Instance of FileReference did not understand #notEmpty". 
> I try to make sense of it in the debugger. My user is git, my public and 
> private ssh keys are not empty. Despite of not making sense of all I 
> understand that is trying to clone something at 
> g...@github.com:feenkcom/gtoolkit.git. I go to my image dir and then to 
> `iceberg/feenkcom/gtoolkit/`. There is a git repository there, but is empty.
>   • Now I wonder, maybe if I can just clone the directory there, but how 
> I say Iceberg to load it? So I run now only the Metacello part. Same error 
> and solution that the last time but now for gtoolkit-visualizer, Brick, 
> gtoolkit-examples, Bloc and Sparta.
>   • After getting my ssh keys, overcome config problems in shell and the 
> Pharo settings, chasing these errors and solving them by cloning the 
> repositories manually, I'm, a couple of hours later, ready to test GT 
> Documenter, but with the last Iceberg's duplicated repository message about 
> Sparta I give up. Is not nice to start your day accumulating frustration... 
> that sets a bad mood for the rest of it, and you need to actively fight 
> against.
> I have thought that Git is overcomplicated for most of the developers' tasks 
> and communities. I don't know if the root of previous issues is in the 
> "Iceberg enableMetacelloIntegration: true" line, but having to get your pair 
> of keys working to just install software is overkill for the common user (and 
> when LibGit errors are present, the documented solutions don't work 
> seamlessly). Maybe a more sensitive solution would be just to use libgit, 
> without any ssh auth to clone repositories and its prerequisites or even 
> better, some download that goes to the files in the tip (or other) version 
> without all this overhead.
> 
> Anyway, as I said, I have been unable to test GT Documenter properly and 
> getting feedback over GT Tools from the team usually requires a lot of effort 
> in my case (insisting on getting answers or getting none). And that is just 
> to test a promising tech that still doesn't offer saving features (just and 
> awesome preview). I think that a more sensible approach for a good 
> documentation toolkit for now is on Spec and creating custom syntax 
> highlighters with SmaCC[3], that is well documented and works today.
> [3] 
> 

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Offray Vladimir Luna Cárdenas]

On 14/11/17 10:36, Offray Vladimir Luna Cárdenas wrote:

[...]
> I have thought that Git is overcomplicated for most of the developers'
> tasks and communities. I don't know if the root of previous issues is
> in the "Iceberg enableMetacelloIntegration: true" line, but having to
> get your pair of keys working to just install software is overkill for
> the common user (and when LibGit errors are present, the documented
> solutions don't work seamlessly). Maybe a more sensitive solution
> would be just to use libgit, without any ssh auth to clone
> repositories and its prerequisites or even better, some download that
> goes to the files in the tip (or other) version without all this
> overhead. 

In fact, using "Iceberg enableMetacelloIntegration: false" produce a
smoother installing experience. Putting this as the first line of the
script doesn't help to most of the users if we want to enable easy
feedback. Anyway, after a mostly successful installation, Moz2D
installation failed, downloading a ~20Mb file and after that saying:
"Moz2D library is not installed correctly. Select Proceed to continue,
or close this window to cancel the operation." That made most of the
examples non functional because of the lack of Moz2D or because some
deprecation.

Any other way to install Moz2D on Manjaro/Arch Linux or to disable it an
still be able to use Pillar preview features?

Cheers,

Offray

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

[Alistair Grant]

I've committed some fixes to the development branch:

1. MacOS hopefully works now (I don't have access to the platform, so
can't test it).
2. The development version of Beacon is loaded (which is required for
the InMemoryLogger).
3. The README is a tiny bit better.
4. Added #extractTables.

As an example of how historical stock market data can be extracted,
the following retrieves data for the Australian S index from
yahoo:


| rootNode tables historicalData dataFrame |

rootNode := GoogleChrome get:
'https://finance.yahoo.com/quote/%5EAXJO/history?p=%5EAXJO'.
tables := rootNode extractTables.
historicalData := (tables sorted: #size ascending) last.
dataFrame := DataFrame fromRows: (historicalData select: [ :each |
each size = 7 ]).
dataFrame asStringTable.

"
 |  1 2 3 4 5 6
7
-+-
1|  Date  Open  High  Low   Close*Adj
Close**  Volume
2|  Nov 14, 2017  6,021.80  6,021.80  5,957.10  5,966.00  5,966.00
-
3|  Nov 13, 2017  6,029.40  6,029.40  6,010.70  6,021.80  6,021.80
-
4|  Nov 10, 2017  6,049.40  6,049.40  6,020.70  6,029.40  6,029.40
-
etc.
"


To load the development version on MacOS or Linux in a 32 bit image:

"Assuming you don't have OSProcess loaded:"
Metacello new
configuration: 'OSSubprocess';
repository: 'github://marianopeck/OSSubprocess:master/repository';
version: #stable;
load.

Metacello new
baseline: 'Chrome';
repository: 'github://akgrant43/Pharo-Chrome:development/repository';
load.


Cheers,
Alistair


On 12 November 2017 at 20:09, Alistair Grant  wrote:
> Hi Sean,
>
> Thanks for your feedback!  (responses below)
>
>
> On 12 November 2017 at 18:11, Sean P. DeNigris  wrote:
>> Alistair Grant wrote
>>> https://github.com/akgrant43/Pharo-Chrome
>>
>> Wow, that was a wild ride!
>
> Sorry about that.
>
>
>> Lessons learned along the way:
>> 1. On a Mac, to use the snazzy `chrome` terminal command referenced all over
>> the place in the docs, you must first `alias chrome="/Applications/Google\
>> Chrome.app/Contents/MacOS/Google\ Chrome"`
>
> I'm an Ubuntu Linux user, however if you look at OSXChromePlatform
> class>>defaultExecutableLocation you can see that is where it should
> be looking for the exe, so the alias shouldn't really be necessary.
> Torsten wrote this, so maybe has more insight.
>
>
>> 2. Chrome must be started with certain flags: `chrome
>> --remote-debugging-port=9222 --disable-gpu` (not sure if the last flag is
>> needed, but `#get:` seemed to hang before using; reference
>> https://developers.google.com/web/updates/2017/04/headless-chrome)
>
> I've been using this without headless mode.  I'll add a headless flag
> that also disables the gpu.
>
>
>
>> 3. Beacon has renamed InMemoryLogger to MemoryLogger
>> 4. I guess Beacon has renamed `#log` to `#emit`
>
> Sorry about that.  I didn't realise that the Pharo-Chrome baseline is
> loading Beacon stable while my install script upgrades it to
> #development.  #development is more recent, so I'll update the
> baseline.
>
>
>
>> 5. I had to comment out `chromeProcess sigterm.` because `chromeProcess` was
>> nil and also #sigterm seemed not to be defined anywhere in the image. I'm
>> not sure what the issue is there.
>
> chromeProcess is set in GoogleChrome>>openURL:.  Can you give me a
> small example that demonstrates the problem?
>
> #sigterm is implemented by OSSUnixSubprocess, which is what I
> ultimately use to launch the Chrome process on Ubuntu.
>
> But... this will be broken on Mac at the moment because the current
> method of launching chrome doesn't keep track of the process, so
> doesn't support #sigterm.  Do you know if OSSUnixSubprocess works on
> Mac?  If it does, I can update the code (but not test it :-().
>
>
>> Pull request issued for #3 & #4.
>
> Once I update the baseline this shouldn't be required.
>
>
>> Also, I'm not sure what platforms you
>> support, but you may want to tag the example methods with  or
>> similar so that they are runnable from the browser and open an inspector if
>> there is an interesting return value.
>
> Good idea, I'll do this.
>
> I'm also making a few other changes:
>
> 1. Add an #extractTables method that searches through the page and
> returns an array of rows for each table it finds in the page
> (something that can easily be loaded in to DataFrame using #fromRows:,
> but I don't want to make Pharo-Chrome dependent on DataFrame at the
> moment).  Most of the time I use Pharo-Chrome it is extracting data
> from tables.
>
> 2. I don't know of any reliable way to tell when a page has loaded
> since there can always be javascript that periodically updates the
> page.  At the moment it waits until the page hasn't changed for a
> configurable amount of time.  I'm planning to add a check for specific
> content to determine if the 

Re: [Pharo-users] FFIExternalEnumeration int versus long

[Todd Blanchard]

Yeah, I don't know if that is necessarily worth doing TBH.

Generally enumerations are going to be default int size unless you have values 
that are out of range.

In this case you have a function that returns a long.  In a strictly typed 
language you would be required to do a type cast anyhow.

If this were done in Swift, you'd have to do something heinous like 

FPDF_ERR.fromRaw(FPDF_GetLastError()) // older Swift
FPDF_ERR(rawValue: FPDF_GetLastError())

even C++ would require you cast from unsigned long to the enum type.

So, to me, it makes sense with this kind of api that you'd have to explicitly 
convert in the method that does the ffiCall:, get the result, then look up the 
proper enum.

> On Nov 14, 2017, at 2:44 AM, Esteban Lorenzano  wrote:
> 
> right now FFIExternalEnumeration support int32 and uint32 types, but I think 
> is not hard to create a FFIExternalLongEnumeration or whatever is need.
> 
> FFIExternalEnumeration >> initializeEnumeration, however, could be better 
> refactored, I admit ;)
> 
>> On 13 Nov 2017, at 23:41, Ben Coman > > wrote:
>> 
>> I have a C definition...
>>   unsigned long FPDF_GetLastError();
>> 
>> whose return values are...
>>   #define FPDF_ERR_SUCCESS 0// No error.
>>   #define FPDF_ERR_UNKNOWN 1// Unknown error.
>>   #define FPDF_ERR_FILE 2   // File not found or could not be opened.
>>   #define FPDF_ERR_FORMAT 3 // File not in PDF format or corrupted.
>>   #define FPDF_ERR_PASSWORD 4   // Password required or incorrect   password.
>>   #define FPDF_ERR_SECURITY 5   // Unsupported security scheme.
>>   #define FPDF_ERR_PAGE 6   // Page not found or content error.
>> 
>> I was thinking of turning those #define's into an FFIExternalEnumeration,
>> but I was wondering if I'll hit some undefined behaviour with the underlying 
>> representation being a "long" rather than an "int" ? 
>> 
>> I do see here that C enumerations can be a range of types including "long" 
>> * https://stackoverflow.com/questions/7093360/c-sharp-enum-of-long-values 
>> 
>> but I'm not sure how it works in the Pharo context to know what the size 
>> underlying representation.
>> 
>> cheers -ben
> 

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Offray Vladimir Luna Cárdenas]

I have been just trying to install GT Documenter and is really
frustrating (I have been unable to install it even for the first time!).

This was the list of errors I got and steps I followed, in almost
sequential order, just to get a (bittersweet!) taste of GT Documenter:

  * 1st: LGit_GIT_ERROR: No ssh-agent suitable credentials found. So I
go to GitHub, follow the five pages of documentation to get my SSH
credentials that start at [1], then, because I still get the same
error, go to the Iceberg FAQ [2], try to surpass the erro,r via
command line and doesn't work, so I go to the Iceberg settings and
try the manual configuration, going to the next item

[1]

https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/#generating-a-new-ssh-key
[2] https://github.com/pharo-vcs/iceberg/blob/master/README.md

  * Now I get "Instance of LGitCredentialsSSH class did not understand
#ifTrue:ifFalse:". I try to make sense of it in the debugger, but is
something I cannot. Anyway, I rerun it and now I get:
LGit_GIT_EEXISTS:

'/home/offray/Programas/Pharo/6.1a/Dev24/pharo-local/iceberg/feenkcom/gtoolkit'
exists and is not an empty directory. I delete that directory and
try an installation... again
  * Now I get: "Instance of FileReference did not understand #notEmpty".
I try to make sense of it in the debugger. My user is git, my public
and private ssh keys are not empty. Despite of not making sense of
all I understand that is trying to clone something at
g...@github.com:feenkcom/gtoolkit.git. I go to my image dir and then
to `iceberg/feenkcom/gtoolkit/`. There is a git repository there,
but is empty.
  * Now I wonder, maybe if I can just clone the directory there, but how
I say Iceberg to load it? So I run now only the Metacello part. Same
error and solution that the last time but now for
gtoolkit-visualizer, Brick, gtoolkit-examples, Bloc and Sparta.
  * After getting my ssh keys, overcome config problems in shell and the
Pharo settings, chasing these errors and solving them by cloning the
repositories manually, I'm, a couple of hours later, ready to test
GT Documenter, but with the last Iceberg's duplicated repository
message about Sparta I give up. Is not nice to start your day
accumulating frustration... that sets a bad mood for the rest of it,
and you need to actively fight against.

I have thought that Git is overcomplicated for most of the developers'
tasks and communities. I don't know if the root of previous issues is in
the "Iceberg enableMetacelloIntegration: true" line, but having to get
your pair of keys working to just install software is overkill for the
common user (and when LibGit errors are present, the documented
solutions don't work seamlessly). Maybe a more sensitive solution would
be just to use libgit, without any ssh auth to clone repositories and
its prerequisites or even better, some download that goes to the files
in the tip (or other) version without all this overhead.

Anyway, as I said, I have been unable to test GT Documenter properly and
getting feedback over GT Tools from the team usually requires a lot of
effort in my case (insisting on getting answers or getting none). And
that is just to test a promising tech that still doesn't offer saving
features (just and awesome preview). I think that a more sensible
approach for a good documentation toolkit for now is on Spec and
creating custom syntax highlighters with SmaCC[3], that is well
documented and works today.

[3]
https://medium.com/@juliendelplanque/hacking-a-simple-syntactic-highlighter-around-specs-textmodel-44ba2e2b1ab9

I understand that community is trying its best, but expressing how
current offerings are not mature and constructive criticism can help on
that. At the moment my feeling is that if you want to try the new shinny
alpha stuff from GT Documenter, you will need to be prepared for a lot
of frustration and silence.

Cheers,

Offray

On 10/11/17 12:41, Tudor Girba wrote:
> Hi,
>
> As shown at ESUG, GT Documenter offers an advanced viewer (and editor) for 
> Pillar working on top of Bloc.
>
> You can get it by loading:
>
> Iceberg enableMetacelloIntegration: true.
> Metacello new
>baseline: 'GToolkit';
>repository: 'github://feenkcom/gtoolkit/src';
>load.
>
> For example, you can then inspect:
> 'PATH_TO_ICEBERG/feenkcom/gtoolkit/doc/transcript/index.pillar’ 
> asFileReference
>
> Cheers,
> Doru
>
>
>> On Nov 10, 2017, at 12:58 PM, H. Hirzel  wrote:
>>
>> A note:
>>
>> Tudor Girba wrote:
>>    Fri, Aug 25, 2017 at 1:31 PM
>> Reply-To: Any question about pharo is welcome 
>> To: Any question about pharo is welcome 
>>
>> Hi,
>>
>> As mentioned in an announcement about 10 days ago, we are building a
>> Pillar editor with inline viewing abilities in Bloc. 

Re: [Pharo-users] Stream API

[Steffen Märcker]

I forgot to mention, that the most recent code for Pharo is already on  
Github: https://github.com/Pharophile/Transducers


Reducers was the name of the first very first implementation.

(In fact, I was originally inspired by clojures Reducers lib. After  
implementing it in Smalltalk, I developed the concept further. Later I  
found out, that the clojure guys did the same in parallel and ended up  
with the same abstraction but a differnt name. Hence I decided change the  
name in order to make the relation clear.)


Am .11.2017, 16:18 Uhr, schrieb Sven Van Caekenberghe :





On 14 Nov 2017, at 16:00, Steffen Märcker  wrote:

Hi,


<---Schnitt--->


No. Transducers is my side project. I've implemented a package for  
VisualWorks. Unfortunately, I did not finish the port to Pharo yet,  
simply due to a lack of time. Originally, transducers evolved in the  
clojure community. I figured, the concept a good fit for Smalltalk and  
adapted it accordingly. (My thesis is on conditional probabilities in  
model-checking of probabilistic systems.)



<---Schnitt--->


http://www.cincomsmalltalk.com/publicRepository/Transducers.html
https://clojure.org/reference/transducers
Plus some mails on this list and more on the vwnc list. Feel free to  
ask; I understand, that the package comment has lots of potential for  
improvement to help understanding.


Best, Steffen


Some code seems to be here: http://smalltalkhub.com/#!/~cdlm/Experiments

Not sure if it is complete or what the relation is, or the difference  
between transducers and reducers ...

Re: [Pharo-users] Stream API

[Sven Van Caekenberghe]

> On 14 Nov 2017, at 16:00, Steffen Märcker  wrote:
> 
> Hi,
> 
>> Are transducers the subject of your thesis ?
> 
> No. Transducers is my side project. I've implemented a package for 
> VisualWorks. Unfortunately, I did not finish the port to Pharo yet, simply 
> due to a lack of time. Originally, transducers evolved in the clojure 
> community. I figured, the concept a good fit for Smalltalk and adapted it 
> accordingly. (My thesis is on conditional probabilities in model-checking of 
> probabilistic systems.)
> 
>> Any pointers to more information ?
> 
> http://www.cincomsmalltalk.com/publicRepository/Transducers.html
> https://clojure.org/reference/transducers
> Plus some mails on this list and more on the vwnc list. Feel free to ask; I 
> understand, that the package comment has lots of potential for improvement to 
> help understanding.
> 
> Best, Steffen

Some code seems to be here: http://smalltalkhub.com/#!/~cdlm/Experiments

Not sure if it is complete or what the relation is, or the difference between 
transducers and reducers ...

Re: [Pharo-users] QCMagritte on Github

[Todd Blanchard]

Found this on /r/programming today.  Seemed relevant.  Gist is that YAML spec 
is ambiguous and implementations seem to disagree widely on proper 
interpretation.

https://github.com/cblp/yaml-sucks

> On Nov 10, 2017, at 10:37 AM, Andrew Glynn  wrote:
> 
> YAML is what it says, lol.
>  
> I still prefer using SGML and outputting whatever markup I need, although I 
> have to use US army software (that only works on Windows)  to do it since 
> Adobe gouges for FrameMaker.
>  
> Probably a long lasting hangover from working for IBM years ago. Sure was a 
> headache, so a hangover isn’t that surprising.
>  
> Looking for the latest version of that software for a new Win 10 install I 
> came across one of the best quotes on Windows, especially considering the 
> source, though the quote must’ve been written about an old version.
>  
> “With luck, this will start Windows, and a dialogue box will appear and tell 
> you the default drive into which IADS will be installed (C:).
>  
> If Windows doesn't start up, you could always try launching Windows manually.”
>  
>  
> Andrew
>  
>  
> From: Stephane Ducasse 
> Sent: Friday, November 10, 2017 1:21 PM
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] QCMagritte on Github
>  
> For your information.
> We got some problem with travis (what a bad idea to have a syntax like
> yaml - our industry is looping , even xml is better).
> we spent more than 30 min trying with Guille and Andrew to use bash in
> a script section (while this is working in some guille project)
> it does not in other just because yaml does not know who to find the
> end of a line
>  
> Terrible!
>  
> Stef
>  
> On Wed, Nov 8, 2017 at 8:15 AM, stephan  wrote:
> > On 27-10-17 12:39, laurent laffont wrote:
> >> 
> >> Hi,
> >> 
> >> my team starts to use QCMagritte. For our needs we have imported
> >> SmalltalkHub repository to Github here:
> >> https://github.com/Afibre/QCMagritte
> >> 
> >> I don't know if you (Diego, Stephan, Tobias) plan to use Github
> >> instead of SmalltalkHub. At least Github allows branches & pull
> >> request.
> > 
> > 
> > Definitely, and I'm still struggling a bit with Iceberg. I would definitely
> > favor a setup where the whole open source part is build on each commit using
> > travis and images are put on (e.g.) bitbucket.
> > The current jenkins builds are waiting for Diego to finish some changes, and
> > he is a bit distracted with plans for a new house.
> > 
> > Tobias told me he's also interested, so I assume he'll provide a modified
> > baseline for other platforms.
> > 
> > At a certain point we might want to fold all of QCMagritte back into
> > Magritte, but that is a discussion for later I think.
> > 
> > Stephan
> > 
> >

Re: [Pharo-users] Stream API

[Steffen Märcker]

Hi,


Are transducers the subject of your thesis ?


No. Transducers is my side project. I've implemented a package for  
VisualWorks. Unfortunately, I did not finish the port to Pharo yet, simply  
due to a lack of time. Originally, transducers evolved in the clojure  
community. I figured, the concept a good fit for Smalltalk and adapted it  
accordingly. (My thesis is on conditional probabilities in model-checking  
of probabilistic systems.)



Any pointers to more information ?


http://www.cincomsmalltalk.com/publicRepository/Transducers.html
https://clojure.org/reference/transducers
Plus some mails on this list and more on the vwnc list. Feel free to ask;  
I understand, that the package comment has lots of potential for  
improvement to help understanding.


Best, Steffen

Re: [Pharo-users] Stream API

[Sven Van Caekenberghe]

> On 14 Nov 2017, at 15:33, Steffen Märcker  wrote:
> 
> Hi!
> 
>>> Yes, I agree, Xtreams is much better (but steep learning curve).
>>> 
>>> I just wanted to point out that my contributions in Zn streams focus and
>>> better/simpler byte/character IO.
>> 
>> Yes, and it is really nice.
>> Interesting how many users we have in system for general streams? (created 
>> on arbitrary collections).
> 
> I really think streams (in general) should focus on what they are best at. 
> Namely, (stepwise) reading and writing from and to various sources, and 
> buffering for efficiency, too. XStreams does an excellent job here. However, 
> higher level operations - like collecting, selecting, splitting (map, filter, 
> partition) and such - should be addressed by other means. Those operations 
> apply to streams, collections, generators and other data structures. They can 
> efficiently be implemented independent from the data structure. By doing so, 
> code duplication can be avoided and the API of streams, etc. can be kept 
> simple.
> 
> Although I won't have time to contribute code, before finishing my thesis, 
> I'd like to point out, that transducers are here to address exactly this. The 
> package already works with collections, streams and xstreams.

Are transducers the subject of your thesis ?
Any pointers to more information ?

> Best,
> Steffen
> 

Re: [Pharo-users] Stream API

[Steffen Märcker]

Hi!


Yes, I agree, Xtreams is much better (but steep learning curve).

I just wanted to point out that my contributions in Zn streams focus and
better/simpler byte/character IO.


Yes, and it is really nice.
Interesting how many users we have in system for general streams?  
(created on arbitrary collections).


I really think streams (in general) should focus on what they are best at.  
Namely, (stepwise) reading and writing from and to various sources, and  
buffering for efficiency, too. XStreams does an excellent job here.  
However, higher level operations - like collecting, selecting, splitting  
(map, filter, partition) and such - should be addressed by other means.  
Those operations apply to streams, collections, generators and other data  
structures. They can efficiently be implemented independent from the data  
structure. By doing so, code duplication can be avoided and the API of  
streams, etc. can be kept simple.


Although I won't have time to contribute code, before finishing my thesis,  
I'd like to point out, that transducers are here to address exactly this.  
The package already works with collections, streams and xstreams.


Best,
Steffen

Re: [Pharo-users] extending STON

[Sven Van Caekenberghe]

Henry,

> On 14 Nov 2017, at 15:02, henry  wrote:
> 
> Hello, I am trying to extend STON to allow for substitutions as data is 
> written out or read in. On the write side I got it working as #nextPut: is 
> recursively called, so that is the perfect place to substitute before an 
> object is written. I have tested and my changes work well, where I have an 
> arbitrary object as a subObject and it gets substituted out for my Descriptor 
> object.

OK good.

> I am having difficult on the read side identifying where a substitution 
> lookup should occur after decoding the object on the input stream. I want to 
> inflate the Descritpor object, with its data, and call for a possible 
> substitution. As it is a Descriptor, it should get substituted with the right 
> bits on the read side. I chose to try and do this in the method 
> #setReference:to: and put the substitute into the objects list. This did not 
> work. Where is a good place to look within STON to do a read-side 
> post-substitution?

In 

STONReader>>#parseObject
| targetClass reference object |
[
reference := self newReference.
targetClass := self parseClass.
object := targetClass fromSton: self.
self setReference: reference to: object ]
...

I would try just re-assigning object with your custom substitute. Like this

MySTONReader>>#parseObject
| targetClass reference object |
[
reference := self newReference.
targetClass := self parseClass.
object := targetClass fromSton: self.
object := object resolveSubstitution.
self setReference: reference to: object ]
...

The references are used if the same (#==) object is used twice, then you get 
something like

STON fromString: '[Point[1,2],@2]'.

which is an 2 element Array where the exact same object is in both positions 
(structure sharing). This works with circular references too (but be careful 
because the inspector might loop).

HTH,

Sven

> Thank you.
> 
> - HH
> 
> 

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

[Tim Mackinnon]

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

Re: [Pharo-users] QCMagritte on Github

[Tim Mackinnon]

I’ll agree that YAML is not an ideal syntax - but I have to also add that I 
wasn’t that impressed with Travis either, and reading between the lines its the 
combo of both that might be catching you out.

Even with a few glitches, I’ve been impressed with GitLab although the team I 
worked with recently found that CircleCI was more to their liking. In both 
cases you have much more control about what is going on. It may be that you 
need something a bit more heavy duty - and it might be worth checking out some 
of the alternatives.

Tim

> On 10 Nov 2017, at 18:20, Stephane Ducasse  wrote:
> 
> For your information.
> We got some problem with travis (what a bad idea to have a syntax like
> yaml - our industry is looping , even xml is better).
> we spent more than 30 min trying with Guille and Andrew to use bash in
> a script section (while this is working in some guille project)
> it does not in other just because yaml does not know who to find the
> end of a line
> 
> Terrible!
> 
> Stef
> 
> On Wed, Nov 8, 2017 at 8:15 AM, stephan  wrote:
>> On 27-10-17 12:39, laurent laffont wrote:
>>> 
>>> Hi,
>>> 
>>> my team starts to use QCMagritte. For our needs we have imported
>>> SmalltalkHub repository to Github here:
>>> https://github.com/Afibre/QCMagritte
>>> 
>>> I don't know if you (Diego, Stephan, Tobias) plan to use Github
>>> instead of SmalltalkHub. At least Github allows branches & pull
>>> request.
>> 
>> 
>> Definitely, and I'm still struggling a bit with Iceberg. I would definitely
>> favor a setup where the whole open source part is build on each commit using
>> travis and images are put on (e.g.) bitbucket.
>> The current jenkins builds are waiting for Diego to finish some changes, and
>> he is a bit distracted with plans for a new house.
>> 
>> Tobias told me he's also interested, so I assume he'll provide a modified
>> baseline for other platforms.
>> 
>> At a certain point we might want to fold all of QCMagritte back into
>> Magritte, but that is a discussion for later I think.
>> 
>> Stephan
>> 
>> 
> 

Re: [Pharo-users] when a subclass is loaded, is super-class-side>>initialize executed?

[Ben Coman]

Thx. Thats exactly what I was looking for. The key part being "self
isInitializer" where...
isInitializer
^ selector = #initialize and: [classIsMeta]

Now I also see "self isExternalStructureFieldDefinition"
"Postloading of FFI fields. This code will be called when loading FFI
structures that are not by default in the image."

Could something similar be done like "self isEnumDecl" ?  It would be a
minor improvement to not have write up in blog posts that
MyFFIExternalEnumeration needs a class-side #initialize simply to do
"self initializeEnumeration"
when having #enumDecl is a strong convention and indicator that
intialization is required.

Or is that starting to load up with too many implicit initializations?

Alternatively, what consideration has been given to pragmas for class
initialization?
For example this seems more self contained and explicit
MyFFIExternalEnumeration class >> enumDecl

^ #( EnumA  1   EnumB 2)

cheers -ben

On 14 November 2017 at 16:40, Pavel Krivanek 
wrote:

> Hi,
>
> the #initialize message is sent only to the classes that implement this
> method. In *.st files it is an explicit call, Monticello does it slightly
> smarter way, see MCMethodDefinition>>#postloadOver:
>
> Cheers,
> -- Pavel
>
> 2017-11-14 3:08 GMT+01:00 Ben Coman :
>
>> Because I'm lazy to experiment this instant (not wanting to get
>> distracted from my current track), and also its probably a useful remainder
>> for others I'll just ask...
>>
>> When MyClass is loaded, #initialize is sent to it.  Typically the
>> class-side>>initialize should not call "super initialize" to avoid
>> re-initializing the superclaass, but what if MyClass doesn't implement
>> #initialize?  Does the message fall through to the superclass, or is
>> #initialize only sent if MyClass implements it?
>>
>> Concrete example...
>> FFIExternalEnumeration subclass MyEnumeration needs to be sent
>> #initializeEnumeration when it is loaded.  We have...
>>
>> FFIExternalEnustmeration>>#initialize
>> self initializeEnumeration
>>
>> so is MyEnumeration *required* to implement its own
>> MyEnumeration>>#initialize, or can it rely 
>> FFIExternalEnustmeration>>#initialize.
>>  I believe it is the former, but just wanted to confirm my understanding.
>>
>> cheers -ben
>>
>>
>>
>

[Pharo-users] extending STON

[henry]

Hello, I am trying to extend STON to allow for substitutions as data is written 
out or read in. On the write side I got it working as #nextPut: is recursively 
called, so that is the perfect place to substitute before an object is written. 
I have tested and my changes work well, where I have an arbitrary object as a 
subObject and it gets substituted out for my Descriptor object.

I am having difficult on the read side identifying where a substitution lookup 
should occur after decoding the object on the input stream. I want to inflate 
the Descritpor object, with its data, and call for a possible substitution. As 
it is a Descriptor, it should get substituted with the right bits on the read 
side. I chose to try and do this in the method #setReference:to: and put the 
substitute into the objects list. This did not work. Where is a good place to 
look within STON to do a read-side post-substitution?

Thank you.

- HH

Re: [Pharo-users] Stream API

[Denis Kudriashov]

2017-11-14 14:25 GMT+01:00 Sven Van Caekenberghe :
>
> > Yes, Zn streams focus on classic binary(byte) / character streams.
> >
> > Streaming over arbitrary data is very cool and well covered by the old
> ones.
> >
> > While I really like traditional streams I can not agree here. Sometimes
> it reminds me poor java collections which force writing loops all the time.
> > For example the most common task in my experience was writing contents
> of read stream into write stream. And the only possibility now is loop.
> > From this point of view XStreams really pushes streams to the level of
> smalltalk collections.
>
> Yes, I agree, Xtreams is much better (but steep learning curve).
>
> I just wanted to point out that my contributions in Zn streams focus and
> better/simpler byte/character IO.
>

Yes, and it is really nice.
Interesting how many users we have in system for general streams? (created
on arbitrary collections).
>From first look the main users are #printOn: methods. But they use string
based, so they are not general. What others we have?


>
> Improvement on the classic streams are, of course, welcome.
>
> > > About contribution: it is in external repository of Sven. Can we
> contribute with normal process, create pull request into Pharo repo?
> > >
> > > 2017-11-14 9:36 GMT+01:00 Guillermo Polito  >:
> > > To a package next to block?
> > >
> > > On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov <
> dionisi...@gmail.com> wrote:
> > > What about contributing to zinc streams? Imaging that I will create
> block based streams, collecting:/selecting streams like in XSteam. Where I
> should put them?
> > >
> > >
> > > 2017-11-13 23:51 GMT+01:00 Norbert Hartl :
> > >
> > >
> > > > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse <
> stepharo.s...@gmail.com>:
> > > >
> > > >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe <
> s...@stfx.eu> wrote:
> > > >> The idea is to have much simpler streams which can be composed to
> get more sophisticated behaviour.
> > > >>
> > > >> The most primitive streams should be binary read or write streams,
> like a raw file or network connection.
> > > >>
> > > >> To add a character encoding/decoding you wrap them in a
> ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer,
> cleaner ZnCharacterEncoders).
> > > >
> > > > Yes really nice :)
> > > >
> > > > And Guille started to use them and we are slowly rewriting all the
> > > > stream internal users to use Zn and after we will be free.
> > > >
> > > >
> > > No, you will depend on zinc classes. How is that supposed to work in
> bootstrap?
> > >
> > > Norbert
> > > >> If you want buffering, you wrap a ZnBufferedReadStream or
> ZnBufferedWriteStream around them.
> > > >>
> > > >> And there are some other examples in the system too.
> > > >>
> > > >> Have a look at BinaryFileStream and ZdcSocketStream.
> > > >>
> > > >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream
> must die, because they try to be everything at once and are impossible to
> change.
> > > >
> > > >
> > > > YES YES YES and celebrate. I could never understand anything. My
> brain
> > > > is too limited for these kind of games :)
> > > >
> > > >
> > > >
> > > >> The contract of a stream should be much, much simpler than it is
> today.
> > > >
> > > > Fully agree.
> > > >
> > > >>
> > > >> For writing that means
> > > >>
> > > >> #nextPut:
> > > >> #nextPutAll:
> > > >> #next:putAll:
> > > >> #next:putAll:startingAt:
> > > >>
> > > >> the 3 last ones can be written in terms of of the first one, but
> the last one is key because it can be the most efficient.
> > > >> And maybe also
> > > >>
> > > >> #flush
> > > >> #close
> > > >>
> > > >> Some helpers for character writing are
> > > >>
> > > >> #space
> > > >> #tab
> > > >> #cr
> > > >> #crlf
> > > >> #lf
> > > >>
> > > >> Maybe #newline
> > > >
> > > > :)
> > > >
> > > >
> > > >>
> > > >> #<< is a handy method too.
> > > >>
> > > >> For reading that means
> > > >>
> > > >> #atEnd
> > > >> #next
> > > >> #next:
> > > >> #next:into:
> > > >> #next:into:startingAt:
> > > >> #nextInto:
> > > >> #peek
> > > >> #skip:
> > > >> #upToEnd
> > > >> #upTo:
> > > >> #readInto:startingAt:count:
> > > >>
> > > >> Again, they can all be written in terms of #next, but
> #readInto:startingAt:count: is the core, efficient one.
> > > >> Note that #peek allows a one character lookahead, which should be
> sufficient for almost all parsing needs.
> > > >>
> > > >> #close is also a necessary operation, #peekFor: a handy one,
> #nextLine is popular too.
> > > >>
> > > >> There is a discussion about positioning (#position , #position: and
> related) but these cannot be supported _in general_ by the kind of streams
> described above.
> > > >>
> > > >> If you absolutely need these, read #upToEnd and use a regular
> ReadStream (over a fixed collection).
> > > >>
> > > >> The collection based classic Streams should always remain in the
> 

Re: [Pharo-users] Stream API

[Sven Van Caekenberghe]

> On 14 Nov 2017, at 14:18, Denis Kudriashov  wrote:
> 
> 
> 2017-11-14 14:00 GMT+01:00 Sven Van Caekenberghe :
> 
> 
> > On 14 Nov 2017, at 09:53, Denis Kudriashov  wrote:
> >
> > I look at the code, So Zinc provides only binary/character streams. Right?
> 
> Yes, Zn streams focus on classic binary(byte) / character streams.
> 
> Streaming over arbitrary data is very cool and well covered by the old ones.
> 
> While I really like traditional streams I can not agree here. Sometimes it 
> reminds me poor java collections which force writing loops all the time.
> For example the most common task in my experience was writing contents of 
> read stream into write stream. And the only possibility now is loop. 
> From this point of view XStreams really pushes streams to the level of 
> smalltalk collections. 

Yes, I agree, Xtreams is much better (but steep learning curve).

I just wanted to point out that my contributions in Zn streams focus and 
better/simpler byte/character IO.

Improvement on the classic streams are, of course, welcome.

> > About contribution: it is in external repository of Sven. Can we contribute 
> > with normal process, create pull request into Pharo repo?
> >
> > 2017-11-14 9:36 GMT+01:00 Guillermo Polito :
> > To a package next to block?
> >
> > On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov  
> > wrote:
> > What about contributing to zinc streams? Imaging that I will create block 
> > based streams, collecting:/selecting streams like in XSteam. Where I should 
> > put them?
> >
> >
> > 2017-11-13 23:51 GMT+01:00 Norbert Hartl :
> >
> >
> > > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse :
> > >
> > >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe  
> > >> wrote:
> > >> The idea is to have much simpler streams which can be composed to get 
> > >> more sophisticated behaviour.
> > >>
> > >> The most primitive streams should be binary read or write streams, like 
> > >> a raw file or network connection.
> > >>
> > >> To add a character encoding/decoding you wrap them in a 
> > >> ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer, 
> > >> cleaner ZnCharacterEncoders).
> > >
> > > Yes really nice :)
> > >
> > > And Guille started to use them and we are slowly rewriting all the
> > > stream internal users to use Zn and after we will be free.
> > >
> > >
> > No, you will depend on zinc classes. How is that supposed to work in 
> > bootstrap?
> >
> > Norbert
> > >> If you want buffering, you wrap a ZnBufferedReadStream or 
> > >> ZnBufferedWriteStream around them.
> > >>
> > >> And there are some other examples in the system too.
> > >>
> > >> Have a look at BinaryFileStream and ZdcSocketStream.
> > >>
> > >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must 
> > >> die, because they try to be everything at once and are impossible to 
> > >> change.
> > >
> > >
> > > YES YES YES and celebrate. I could never understand anything. My brain
> > > is too limited for these kind of games :)
> > >
> > >
> > >
> > >> The contract of a stream should be much, much simpler than it is today.
> > >
> > > Fully agree.
> > >
> > >>
> > >> For writing that means
> > >>
> > >> #nextPut:
> > >> #nextPutAll:
> > >> #next:putAll:
> > >> #next:putAll:startingAt:
> > >>
> > >> the 3 last ones can be written in terms of of the first one, but the 
> > >> last one is key because it can be the most efficient.
> > >> And maybe also
> > >>
> > >> #flush
> > >> #close
> > >>
> > >> Some helpers for character writing are
> > >>
> > >> #space
> > >> #tab
> > >> #cr
> > >> #crlf
> > >> #lf
> > >>
> > >> Maybe #newline
> > >
> > > :)
> > >
> > >
> > >>
> > >> #<< is a handy method too.
> > >>
> > >> For reading that means
> > >>
> > >> #atEnd
> > >> #next
> > >> #next:
> > >> #next:into:
> > >> #next:into:startingAt:
> > >> #nextInto:
> > >> #peek
> > >> #skip:
> > >> #upToEnd
> > >> #upTo:
> > >> #readInto:startingAt:count:
> > >>
> > >> Again, they can all be written in terms of #next, but 
> > >> #readInto:startingAt:count: is the core, efficient one.
> > >> Note that #peek allows a one character lookahead, which should be 
> > >> sufficient for almost all parsing needs.
> > >>
> > >> #close is also a necessary operation, #peekFor: a handy one, #nextLine 
> > >> is popular too.
> > >>
> > >> There is a discussion about positioning (#position , #position: and 
> > >> related) but these cannot be supported _in general_ by the kind of 
> > >> streams described above.
> > >>
> > >> If you absolutely need these, read #upToEnd and use a regular ReadStream 
> > >> (over a fixed collection).
> > >>
> > >> The collection based classic Streams should always remain in the system, 
> > >> they are too handy. But have you seen for example, #nextInt32 on 
> > >> PositionableStream ? Good luck with that when the the 

Re: [Pharo-users] Stream API

[Denis Kudriashov]

2017-11-14 14:00 GMT+01:00 Sven Van Caekenberghe :

>
>
> > On 14 Nov 2017, at 09:53, Denis Kudriashov  wrote:
> >
> > I look at the code, So Zinc provides only binary/character streams.
> Right?
>
> Yes, Zn streams focus on classic binary(byte) / character streams.
>
> Streaming over arbitrary data is very cool and well covered by the old
> ones.
>

While I really like traditional streams I can not agree here. Sometimes it
reminds me poor java collections which force writing loops all the time.
For example the most common task in my experience was writing contents of
read stream into write stream. And the only possibility now is loop.
>From this point of view XStreams really pushes streams to the level of
smalltalk collections.


>
> > About contribution: it is in external repository of Sven. Can we
> contribute with normal process, create pull request into Pharo repo?
> >
> > 2017-11-14 9:36 GMT+01:00 Guillermo Polito :
> > To a package next to block?
> >
> > On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov 
> wrote:
> > What about contributing to zinc streams? Imaging that I will create
> block based streams, collecting:/selecting streams like in XSteam. Where I
> should put them?
> >
> >
> > 2017-11-13 23:51 GMT+01:00 Norbert Hartl :
> >
> >
> > > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse <
> stepharo.s...@gmail.com>:
> > >
> > >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe 
> wrote:
> > >> The idea is to have much simpler streams which can be composed to get
> more sophisticated behaviour.
> > >>
> > >> The most primitive streams should be binary read or write streams,
> like a raw file or network connection.
> > >>
> > >> To add a character encoding/decoding you wrap them in a
> ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer,
> cleaner ZnCharacterEncoders).
> > >
> > > Yes really nice :)
> > >
> > > And Guille started to use them and we are slowly rewriting all the
> > > stream internal users to use Zn and after we will be free.
> > >
> > >
> > No, you will depend on zinc classes. How is that supposed to work in
> bootstrap?
> >
> > Norbert
> > >> If you want buffering, you wrap a ZnBufferedReadStream or
> ZnBufferedWriteStream around them.
> > >>
> > >> And there are some other examples in the system too.
> > >>
> > >> Have a look at BinaryFileStream and ZdcSocketStream.
> > >>
> > >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must
> die, because they try to be everything at once and are impossible to change.
> > >
> > >
> > > YES YES YES and celebrate. I could never understand anything. My brain
> > > is too limited for these kind of games :)
> > >
> > >
> > >
> > >> The contract of a stream should be much, much simpler than it is
> today.
> > >
> > > Fully agree.
> > >
> > >>
> > >> For writing that means
> > >>
> > >> #nextPut:
> > >> #nextPutAll:
> > >> #next:putAll:
> > >> #next:putAll:startingAt:
> > >>
> > >> the 3 last ones can be written in terms of of the first one, but the
> last one is key because it can be the most efficient.
> > >> And maybe also
> > >>
> > >> #flush
> > >> #close
> > >>
> > >> Some helpers for character writing are
> > >>
> > >> #space
> > >> #tab
> > >> #cr
> > >> #crlf
> > >> #lf
> > >>
> > >> Maybe #newline
> > >
> > > :)
> > >
> > >
> > >>
> > >> #<< is a handy method too.
> > >>
> > >> For reading that means
> > >>
> > >> #atEnd
> > >> #next
> > >> #next:
> > >> #next:into:
> > >> #next:into:startingAt:
> > >> #nextInto:
> > >> #peek
> > >> #skip:
> > >> #upToEnd
> > >> #upTo:
> > >> #readInto:startingAt:count:
> > >>
> > >> Again, they can all be written in terms of #next, but
> #readInto:startingAt:count: is the core, efficient one.
> > >> Note that #peek allows a one character lookahead, which should be
> sufficient for almost all parsing needs.
> > >>
> > >> #close is also a necessary operation, #peekFor: a handy one,
> #nextLine is popular too.
> > >>
> > >> There is a discussion about positioning (#position , #position: and
> related) but these cannot be supported _in general_ by the kind of streams
> described above.
> > >>
> > >> If you absolutely need these, read #upToEnd and use a regular
> ReadStream (over a fixed collection).
> > >>
> > >> The collection based classic Streams should always remain in the
> system, they are too handy. But have you seen for example, #nextInt32 on
> PositionableStream ? Good luck with that when the the underlying collection
> is anything other than bytes.
> > >>
> > >> All this being said, there is no one, single correct answer.
> > >>
> > >> But if we all try to simplify what we expect of streams (use a more
> limited API), we'll be more nimble to make implementation changes later on.
> > >>
> > >> Sven
> > >>
> > >>> On 13 Nov 2017, at 19:58, Stephane Ducasse 
> wrote:
> > >>>
> > >>> Hi Evan
> > >>>
> > >>> I think 

Re: [Pharo-users] Stream API

[Sven Van Caekenberghe]

> On 14 Nov 2017, at 10:20, Prof. Andrew P. Black  wrote:
> 
> 
>> On 13 Nov 2017, at 20:27 , Sven Van Caekenberghe  wrote:
>> 
>> There is a discussion about positioning (#position , #position: and related) 
>> but these cannot be supported _in general_ by the kind of streams described 
>> above.
> 
> I agree with that.  But I think that general streams can, and should support:
> 
>   # saveState “answers an opaque cookie” 
>   # restoreState: aCookieObtainedFromTheSameStream
> 
> This enables pone to read ahead, and then reset the state to the way that it 
> was.  The implementation of the cookie will depend on the implementation of 
> the stream.  In the simplest case it may be an integer position (sufficient 
> for an in-core stream); in the more general case it may include a copy of the 
> stream’s buffer, and the cookie obtained by saving the state of any wrapped 
> stream.
> 
>   Andrew

Yes and no: #saveState / #restoreState: need a possibly unlimited 
memory/buffer, similar to #position / #position:

They cannot be offered in general (a socket stream is infinite, has no 
begin/end, in most cases).

But I do think that a wrapper stream could add such feature, we only have to 
implement one and agree on the API (and the buffer size should probably be 
limited in size).

I am curious though, why do you need it ?

I mean, I got away (and try hard) to only use 1-element peeking and managed to 
implement STON, NeoJSON, NeoCSV, Stomp, PostgresSQL, Redis, and other protocols.

A syntax that really requires multi element peeking is not so common.

Sven

Re: [Pharo-users] Iterating through two collections in parallel

[Denis Kudriashov]

Hi
Try this one:
#(1 2 3) with: 'abc' do:  [ :aNumber :aLetter |  do
something first with 1 and $a,

 then with 2 and $b,

 and finally with 3 and $c ]

2017-11-14 10:10 GMT+01:00 Prof. Andrew P. Black :

> What method will execute a two-parameter block with corresponding pairs of
> elements from two separate Ordered Collections.
>
> something like  this example:
>
> #(1 2 3) and: 'abc' do:  [ :aNumber :aLetter |  do
> something first with 1 and $a,
>
>then with 2 and $b,
>
>and finally with 3 and $c ]
>
> I searched for ‘corresponding’  and ‘pairs’ and failed to find what I’m
> looking for.  I tried ‘zip’.  It’s hard to search for this with an example.
>
> Andrew
>
>
>
>
>
>

Re: [Pharo-users] Stream API

[Prof. Andrew P. Black]

> On 13 Nov 2017, at 20:27 , Sven Van Caekenberghe  wrote:
> 
> There is a discussion about positioning (#position , #position: and related) 
> but these cannot be supported _in general_ by the kind of streams described 
> above.

I agree with that.  But I think that general streams can, and should support:

# saveState “answers an opaque cookie” 
# restoreState: aCookieObtainedFromTheSameStream

This enables pone to read ahead, and then reset the state to the way that it 
was.  The implementation of the cookie will depend on the implementation of the 
stream.  In the simplest case it may be an integer position (sufficient for an 
in-core stream); in the more general case it may include a copy of the stream’s 
buffer, and the cookie obtained by saving the state of any wrapped stream.

Andrew

Re: [Pharo-users] RBRuleIfNotNilDo usage

[Henrik Sperre Johansen]

Stephane Ducasse-3 wrote
> I wonder if we packaged somewhere the removed deprecated method.
> We should do that but since we do it manually I guess that this is ad-hoc.
> 
> Stef
> 
> On Sun, Nov 12, 2017 at 2:45 PM, Alistair Grant 

> akgrant0710@

>  wrote:
>> Hi Stef,
>>
>> On 12 November 2017 at 14:34, Stephane Ducasse 

> stepharo.self@

>  wrote:
>>> Hi alistair
>>>
>>>
>>> If you run your program the code will be automatically transformed (I
>>> cannot check the deprecation definitino right now)
>>>
>>> Else have a look at tests of the ParseTreeRewriter.
>>>
>>> Stef
>>>
>>> On Sun, Nov 12, 2017 at 2:12 PM, Alistair Grant 

> akgrant0710@

>  wrote:
 Hi Everyone,

 I'm loading some code in to Pharo 7 that tries to use #ifNotNilDo:.

 There's already a transformation to re-write it to the correct
 #ifNotNil: - RBRuleIfNotNilDo.

 How can I apply the transformation to all existing methods in the
 image that call #ifNotNilDo:?

 Thanks,
 Alistair
>>
>> Thanks!
>>
>> #ifNotNilDo: was deprecated in Pharo 6, and the method was removed
>> completely in Pharo 7.
>>
>> The easiest thing to do is to port #ifNotNilDo: forward to Pharo 7 so
>> that the methods are automatically re-written.
>>
>> And then get the offending libraries to be updated.  But that's another
>> story.
>>
>> Thanks again,
>> Alistair
>>

It would also be possible to force the issue, and instead of keeping the
definitions in image + rewrite on use, add the rules to a CompilerPlugin,
either loaded by default when importing code, or as a "rewrite deprecated
sends on import" toggle in the settings somewhere.

Cheers,
Henry



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] Iterating through two collections in parallel

[Prof. Andrew P. Black]

What method will execute a two-parameter block with corresponding pairs of 
elements from two separate Ordered Collections.

something like  this example:

#(1 2 3) and: 'abc' do:  [ :aNumber :aLetter |  do 
something first with 1 and $a, 

 then with 2 and $b, 

 and finally with 3 and $c ]

I searched for ‘corresponding’  and ‘pairs’ and failed to find what I’m looking 
for.  I tried ‘zip’.  It’s hard to search for this with an example.  

Andrew

Re: [Pharo-users] Stream API

[Pavel Krivanek]

2017-11-14 9:53 GMT+01:00 Denis Kudriashov :

> I look at the code, So Zinc provides only binary/character streams. Right?
>
> About contribution: it is in external repository of Sven. Can we
> contribute with normal process, create pull request into Pharo repo?
>

yes, time to time we make sync with Zinc upstream.

-- Pavel


>
> 2017-11-14 9:36 GMT+01:00 Guillermo Polito :
>
>> To a package next to block?
>>
>> On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov 
>> wrote:
>>
>>> What about contributing to zinc streams? Imaging that I will create
>>> block based streams, collecting:/selecting streams like in XSteam. Where I
>>> should put them?
>>>
>>>
>>> 2017-11-13 23:51 GMT+01:00 Norbert Hartl :
>>>


 > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse <
 stepharo.s...@gmail.com>:
 >
 >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe 
 wrote:
 >> The idea is to have much simpler streams which can be composed to
 get more sophisticated behaviour.
 >>
 >> The most primitive streams should be binary read or write streams,
 like a raw file or network connection.
 >>
 >> To add a character encoding/decoding you wrap them in a
 ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer,
 cleaner ZnCharacterEncoders).
 >
 > Yes really nice :)
 >
 > And Guille started to use them and we are slowly rewriting all the
 > stream internal users to use Zn and after we will be free.
 >
 >
 No, you will depend on zinc classes. How is that supposed to work in
 bootstrap?

 Norbert
 >> If you want buffering, you wrap a ZnBufferedReadStream or
 ZnBufferedWriteStream around them.
 >>
 >> And there are some other examples in the system too.
 >>
 >> Have a look at BinaryFileStream and ZdcSocketStream.
 >>
 >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must
 die, because they try to be everything at once and are impossible to 
 change.
 >
 >
 > YES YES YES and celebrate. I could never understand anything. My brain
 > is too limited for these kind of games :)
 >
 >
 >
 >> The contract of a stream should be much, much simpler than it is
 today.
 >
 > Fully agree.
 >
 >>
 >> For writing that means
 >>
 >> #nextPut:
 >> #nextPutAll:
 >> #next:putAll:
 >> #next:putAll:startingAt:
 >>
 >> the 3 last ones can be written in terms of of the first one, but the
 last one is key because it can be the most efficient.
 >> And maybe also
 >>
 >> #flush
 >> #close
 >>
 >> Some helpers for character writing are
 >>
 >> #space
 >> #tab
 >> #cr
 >> #crlf
 >> #lf
 >>
 >> Maybe #newline
 >
 > :)
 >
 >
 >>
 >> #<< is a handy method too.
 >>
 >> For reading that means
 >>
 >> #atEnd
 >> #next
 >> #next:
 >> #next:into:
 >> #next:into:startingAt:
 >> #nextInto:
 >> #peek
 >> #skip:
 >> #upToEnd
 >> #upTo:
 >> #readInto:startingAt:count:
 >>
 >> Again, they can all be written in terms of #next, but
 #readInto:startingAt:count: is the core, efficient one.
 >> Note that #peek allows a one character lookahead, which should be
 sufficient for almost all parsing needs.
 >>
 >> #close is also a necessary operation, #peekFor: a handy one,
 #nextLine is popular too.
 >>
 >> There is a discussion about positioning (#position , #position: and
 related) but these cannot be supported _in general_ by the kind of streams
 described above.
 >>
 >> If you absolutely need these, read #upToEnd and use a regular
 ReadStream (over a fixed collection).
 >>
 >> The collection based classic Streams should always remain in the
 system, they are too handy. But have you seen for example, #nextInt32 on
 PositionableStream ? Good luck with that when the the underlying collection
 is anything other than bytes.
 >>
 >> All this being said, there is no one, single correct answer.
 >>
 >> But if we all try to simplify what we expect of streams (use a more
 limited API), we'll be more nimble to make implementation changes later on.
 >>
 >> Sven
 >>
 >>> On 13 Nov 2017, at 19:58, Stephane Ducasse 
 wrote:
 >>>
 >>> Hi Evan
 >>>
 >>> I think that we will use the ZnStreams.
 >>> If we use Xtreams we will transform their API because some messages
 >>> are not really good.
 >>> Stef
 >>>
  On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue 
 wrote:
  I've heard mention once or twice on this list and in some release
 notes of
  what sounded like possible coming 

Re: [Pharo-users] Open Debugger, Save and Quit

[Guillermo Polito]

Hi Sean,

You can always try:

exception freeze.
  freeze will copy the stack so it is usable in a posterior debug session
even if the original contexts died.

exception debug.
  Opens a debugger :)

On Mon, Nov 13, 2017 at 5:20 PM, Sean P. DeNigris 
wrote:

> Tim Mackinnon wrote
> > you can override this and Fuel out the debug context to a file
>
> Thanks, Tim! I do know about that, but I was thinking/hoping that maybe
> there was a way to keep the debug context alive without fueling out…
>
>
>
> -
> 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
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Stream API

[Denis Kudriashov]

I look at the code, So Zinc provides only binary/character streams. Right?

About contribution: it is in external repository of Sven. Can we contribute
with normal process, create pull request into Pharo repo?

2017-11-14 9:36 GMT+01:00 Guillermo Polito :

> To a package next to block?
>
> On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov 
> wrote:
>
>> What about contributing to zinc streams? Imaging that I will create block
>> based streams, collecting:/selecting streams like in XSteam. Where I should
>> put them?
>>
>>
>> 2017-11-13 23:51 GMT+01:00 Norbert Hartl :
>>
>>>
>>>
>>> > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse <
>>> stepharo.s...@gmail.com>:
>>> >
>>> >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe 
>>> wrote:
>>> >> The idea is to have much simpler streams which can be composed to get
>>> more sophisticated behaviour.
>>> >>
>>> >> The most primitive streams should be binary read or write streams,
>>> like a raw file or network connection.
>>> >>
>>> >> To add a character encoding/decoding you wrap them in a
>>> ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer,
>>> cleaner ZnCharacterEncoders).
>>> >
>>> > Yes really nice :)
>>> >
>>> > And Guille started to use them and we are slowly rewriting all the
>>> > stream internal users to use Zn and after we will be free.
>>> >
>>> >
>>> No, you will depend on zinc classes. How is that supposed to work in
>>> bootstrap?
>>>
>>> Norbert
>>> >> If you want buffering, you wrap a ZnBufferedReadStream or
>>> ZnBufferedWriteStream around them.
>>> >>
>>> >> And there are some other examples in the system too.
>>> >>
>>> >> Have a look at BinaryFileStream and ZdcSocketStream.
>>> >>
>>> >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must
>>> die, because they try to be everything at once and are impossible to change.
>>> >
>>> >
>>> > YES YES YES and celebrate. I could never understand anything. My brain
>>> > is too limited for these kind of games :)
>>> >
>>> >
>>> >
>>> >> The contract of a stream should be much, much simpler than it is
>>> today.
>>> >
>>> > Fully agree.
>>> >
>>> >>
>>> >> For writing that means
>>> >>
>>> >> #nextPut:
>>> >> #nextPutAll:
>>> >> #next:putAll:
>>> >> #next:putAll:startingAt:
>>> >>
>>> >> the 3 last ones can be written in terms of of the first one, but the
>>> last one is key because it can be the most efficient.
>>> >> And maybe also
>>> >>
>>> >> #flush
>>> >> #close
>>> >>
>>> >> Some helpers for character writing are
>>> >>
>>> >> #space
>>> >> #tab
>>> >> #cr
>>> >> #crlf
>>> >> #lf
>>> >>
>>> >> Maybe #newline
>>> >
>>> > :)
>>> >
>>> >
>>> >>
>>> >> #<< is a handy method too.
>>> >>
>>> >> For reading that means
>>> >>
>>> >> #atEnd
>>> >> #next
>>> >> #next:
>>> >> #next:into:
>>> >> #next:into:startingAt:
>>> >> #nextInto:
>>> >> #peek
>>> >> #skip:
>>> >> #upToEnd
>>> >> #upTo:
>>> >> #readInto:startingAt:count:
>>> >>
>>> >> Again, they can all be written in terms of #next, but
>>> #readInto:startingAt:count: is the core, efficient one.
>>> >> Note that #peek allows a one character lookahead, which should be
>>> sufficient for almost all parsing needs.
>>> >>
>>> >> #close is also a necessary operation, #peekFor: a handy one,
>>> #nextLine is popular too.
>>> >>
>>> >> There is a discussion about positioning (#position , #position: and
>>> related) but these cannot be supported _in general_ by the kind of streams
>>> described above.
>>> >>
>>> >> If you absolutely need these, read #upToEnd and use a regular
>>> ReadStream (over a fixed collection).
>>> >>
>>> >> The collection based classic Streams should always remain in the
>>> system, they are too handy. But have you seen for example, #nextInt32 on
>>> PositionableStream ? Good luck with that when the the underlying collection
>>> is anything other than bytes.
>>> >>
>>> >> All this being said, there is no one, single correct answer.
>>> >>
>>> >> But if we all try to simplify what we expect of streams (use a more
>>> limited API), we'll be more nimble to make implementation changes later on.
>>> >>
>>> >> Sven
>>> >>
>>> >>> On 13 Nov 2017, at 19:58, Stephane Ducasse 
>>> wrote:
>>> >>>
>>> >>> Hi Evan
>>> >>>
>>> >>> I think that we will use the ZnStreams.
>>> >>> If we use Xtreams we will transform their API because some messages
>>> >>> are not really good.
>>> >>> Stef
>>> >>>
>>>  On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue 
>>> wrote:
>>>  I've heard mention once or twice on this list and in some release
>>> notes of
>>>  what sounded like possible coming changes to the stream API. Could
>>> anyone
>>>  point me to any concrete details about that? I haven't been able to
>>> dig
>>>  anything up myself by searching. I'm about to write something that
>>> I'd like
>>>  to be polymorphic with the stream API, but if that's about to
>>> 

Re: [Pharo-users] Embedded PDF viewer?

[Christian Haider]

In the end, you need to have bitmaps for the screen.
Rendering is the projection of vectors onto pixels.

But you don't want to lose the vectors, because you need them for interactions 
(mouse, keyboard focus).

I think that it is extremely sexy to have an interactive viewer for PDF!

Writing a renderer is a lot of work, although the newer Windows and Apple APIs 
make it a lot easier nowadays.
Still, you need to have an answer to color composition and irregular clipping 
paths (the hardest problems I think of. But there may be more).
And it must be fast enough for interactive applications...

I was hoping to use some existing renderer. I imagine that Bens approach can 
work well.

Although I didn’t do anything towards rendering myself, I am thinking of using 
PDF.js in an embedded browser.
PDF.js is used by many browsers and seems to be good enough by now.
And it would be not too bad to fiddle with JavaScript to connect it with the 
model in Smalltalk, I guess.
The problem is the browser embedding. Is this feasible in Pharo?

Happy hacking,
Christian


> -Ursprüngliche Nachricht-
> Von: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] Im Auftrag
> von K K Subbu
> Gesendet: Dienstag, 14. November 2017 06:43
> An: Ben Coman 
> Cc: Any question about pharo is welcome 
> Betreff: Re: [Pharo-users] Embedded PDF viewer?
> 
> On Monday 13 November 2017 05:29 PM, Ben Coman wrote:
> > Yes, I've certainly considered it.  Pragmatically, in my electrical
> > career I deal with a lot of single page A3 PDF scans of schematic
> > drawings, so pre-converting to a bitmap format outside of Pharo
> > wouldn't lose much.
> 
> PDF deals with vector graphics, so bitmap conversion will be lossy. You could
> import them as SVG instead use the existing classes for handling SVG and
> XML.
> 
> HTH .. Subbu

Re: [Pharo-users] when a subclass is loaded, is super-class-side>>initialize executed?

[Pavel Krivanek]

Hi,

the #initialize message is sent only to the classes that implement this
method. In *.st files it is an explicit call, Monticello does it slightly
smarter way, see MCMethodDefinition>>#postloadOver:

Cheers,
-- Pavel

2017-11-14 3:08 GMT+01:00 Ben Coman :

> Because I'm lazy to experiment this instant (not wanting to get distracted
> from my current track), and also its probably a useful remainder for others
> I'll just ask...
>
> When MyClass is loaded, #initialize is sent to it.  Typically the
> class-side>>initialize should not call "super initialize" to avoid
> re-initializing the superclaass, but what if MyClass doesn't implement
> #initialize?  Does the message fall through to the superclass, or is
> #initialize only sent if MyClass implements it?
>
> Concrete example...
> FFIExternalEnumeration subclass MyEnumeration needs to be sent
> #initializeEnumeration when it is loaded.  We have...
>
> FFIExternalEnustmeration>>#initialize
> self initializeEnumeration
>
> so is MyEnumeration *required* to implement its own
> MyEnumeration>>#initialize, or can it rely 
> FFIExternalEnustmeration>>#initialize.
>  I believe it is the former, but just wanted to confirm my understanding.
>
> cheers -ben
>
>
>