Re: [Pharo-users] Problems loading XML System ( was [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding)

[monty]

Something went wrong during your upgrade with class initialization.

Installing the latest versions of these projects into a clean image would work, 
and so would installing the latest XMLParserHTML and XMLParserStAX into the 
newest Moose-6.1 image (which has the latest XMLParser and XPath).

But if you insist on upgrading your old image, try the latest 
ConfigurationOfXMLParser (.303.mcz) and ConfigurationOfXPath (.149.mcz) from 
their PharoExtras repos and install their latest project versions, and do the 
same with XMLParserHTML and XMLParserStAX (the older versions aren't compatible 
with newer XMLParser versions). Then open the test runner and run all 
"XML|XPath" tests. If you get any failures, evaluate this:

#('XML-Parser' 'XPath-Core') do: [:package |
(SystemNavigation default allClassesInPackageNamed: package) do: 
[:class |
class initialize]]

and try running the tests again.

> Sent: Monday, May 15, 2017 at 6:50 PM
> From: PBKResearch 
> To: "'Any question about pharo is welcome'" 
> Subject: [Pharo-users] Problems loading XML System ( was Re: [Zinc] 
> ZnInvalidUTF8: Illegal leading byte for utf-8 encoding)
>
> Monty
> 
> As an update, I have rebuilt from the Moose 6.0 download. The version of 
> XML-Parser in that was dated 18 July 2016 (configuration monty.233), so I 
> installed versions of XML-Parser-HTML and XML-Parser-StAX contemporary with 
> that. (The respective configurations are monty.48 and monty.39). With these 
> versions all my previous XMLHTMLParser operations work as before, and I have 
> been able to use the StAX parser in a simple way. So I can start exploring as 
> I intended.
> 
> I have made repeated attempts to update this rebuilt image to more recent 
> versions of the HTML and StAX parsers, and every time I run into the same 
> error reported below. I started from the latest version and worked backwards, 
> but gave up quickly; it takes about 6 minutes on my machine to load and 
> compile a version, and it soon gets tedious. If I feel more enthusiastic 
> tomorrow, I might start working forwards from my current versions.
> 
> Anyway, I now have a working system with the StaX and HTML parsers, so I can 
> continue to explore.
> 
> Best wishes
> 
> Peter Kenny
> 
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
> PBKResearch
> Sent: 15 May 2017 20:44
> To: 'Any question about pharo is welcome' 
> Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for 
> utf-8 encoding
> 
> Monty
> 
> I have just started trying to use the StAX parsers, and I have found that the 
> update has introduced a problem, which means that XMLHTMLParser no longer 
> works on examples I have used before. I updated to 
> ConfigurationOfXMLParser(monty.302), which is the latest version on the 
> smalltalkhub repository, and then used the load version in the class comment, 
> which loads the stable default. Similarly, I loaded 
> ConfigurationOfXMLParserHTML(monty.62) and 
> ConfigurationOfXMLParserStAX(monty.51), again using stable and default. When 
> I try to run the XMLHTMLParser example I quoted below, I get an error message 
> 'MessageNotunderstood: receiver of "critical:" is nil'. The same message 
> comes up with anything else I try with XMLHTMLParser or with StAXHTMLParser.
> 
> I am not really up to using the debugger on someone else's code, but the one 
> thing I can see is that the problem lies in XMLKeyValueCache>>critical:, 
> which has the code:
> ^ self mutex critical: aBlock
> The problem being that mutex is nil. 
> 
> In my enthusiasm, I saved the updated image with the same name as the old 
> image, which is now therefore overwritten. If I cannot solve this problem, my 
> only way out is to rebuild my image from the Moose 6.0 download. Any 
> suggestions gratefully received.
> 
> Thanks in advance
> 
> Peter Kenny
> 
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
> PBKResearch
> Sent: 15 May 2017 19:16
> To: 'Any question about pharo is welcome' 
> Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for 
> utf-8 encoding
> 
> Monty
> 
> Many thanks for this. My original purpose was just to answer Paul 
> deBruicker's query, namely to parse an html file and stop reading at the end 
> of the  section. I solved this by trial and error using the code shown 
> below ( which actually stops at the opening tag of the body). This was not my 
> problem at all, but Paul's; I just tackled it for fun.
> 
> However, you note has prompted me to update my version of the whole XML 
> system - I was using the version I downloaded with Moose 6.0, which was dated 
> August 2016. I am looking at the StAX parsers as a possible way of 
> simplifying what I currently do, which involves downloading an entire web 
> 

[Pharo-users] Problems loading XML System ( was Re: [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding)

[PBKResearch]

Monty

As an update, I have rebuilt from the Moose 6.0 download. The version of 
XML-Parser in that was dated 18 July 2016 (configuration monty.233), so I 
installed versions of XML-Parser-HTML and XML-Parser-StAX contemporary with 
that. (The respective configurations are monty.48 and monty.39). With these 
versions all my previous XMLHTMLParser operations work as before, and I have 
been able to use the StAX parser in a simple way. So I can start exploring as I 
intended.

I have made repeated attempts to update this rebuilt image to more recent 
versions of the HTML and StAX parsers, and every time I run into the same error 
reported below. I started from the latest version and worked backwards, but 
gave up quickly; it takes about 6 minutes on my machine to load and compile a 
version, and it soon gets tedious. If I feel more enthusiastic tomorrow, I 
might start working forwards from my current versions.

Anyway, I now have a working system with the StaX and HTML parsers, so I can 
continue to explore.

Best wishes

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
PBKResearch
Sent: 15 May 2017 20:44
To: 'Any question about pharo is welcome' 
Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 
encoding

Monty

I have just started trying to use the StAX parsers, and I have found that the 
update has introduced a problem, which means that XMLHTMLParser no longer works 
on examples I have used before. I updated to 
ConfigurationOfXMLParser(monty.302), which is the latest version on the 
smalltalkhub repository, and then used the load version in the class comment, 
which loads the stable default. Similarly, I loaded 
ConfigurationOfXMLParserHTML(monty.62) and 
ConfigurationOfXMLParserStAX(monty.51), again using stable and default. When I 
try to run the XMLHTMLParser example I quoted below, I get an error message 
'MessageNotunderstood: receiver of "critical:" is nil'. The same message comes 
up with anything else I try with XMLHTMLParser or with StAXHTMLParser.

I am not really up to using the debugger on someone else's code, but the one 
thing I can see is that the problem lies in XMLKeyValueCache>>critical:, which 
has the code:
^ self mutex critical: aBlock
The problem being that mutex is nil. 

In my enthusiasm, I saved the updated image with the same name as the old 
image, which is now therefore overwritten. If I cannot solve this problem, my 
only way out is to rebuild my image from the Moose 6.0 download. Any 
suggestions gratefully received.

Thanks in advance

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
PBKResearch
Sent: 15 May 2017 19:16
To: 'Any question about pharo is welcome' 
Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 
encoding

Monty

Many thanks for this. My original purpose was just to answer Paul deBruicker's 
query, namely to parse an html file and stop reading at the end of the  
section. I solved this by trial and error using the code shown below ( which 
actually stops at the opening tag of the body). This was not my problem at all, 
but Paul's; I just tackled it for fun.

However, you note has prompted me to update my version of the whole XML system 
- I was using the version I downloaded with Moose 6.0, which was dated August 
2016. I am looking at the StAX parsers as a possible way of simplifying what I 
currently do, which involves downloading an entire web page as a DOM and then 
manipulating it with XPath to extract the bits I am interested in. I may be 
able to use StAX to do some of the selection and manipulation as I am reading.

It's all a new topic to me, so I foresee a lot of experimentation. It all helps 
to keep the grey matter active.

Thanks again

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
monty
Sent: 15 May 2017 12:15
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 
encoding

For that kind of incremental parsing, you could also use XMLParserStAX, a 
pull-parser that parses a document as a stream of event objects you control 
with #next, #peek, and #atEnd. It also supports pull-DOM parsing with messages 
like #nextNode, #nextElement, and #nextElementNamed:, which return the next 
event object(s) as DOM subtrees (searchable with XPath). See the StAXParser 
class comment for an example. (The StAXHTMLParser class requires XMLParserHTML 
be installed to work.)

Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding

[PBKResearch]

Monty

I have just started trying to use the StAX parsers, and I have found that the 
update has introduced a problem, which means that XMLHTMLParser no longer works 
on examples I have used before. I updated to 
ConfigurationOfXMLParser(monty.302), which is the latest version on the 
smalltalkhub repository, and then used the load version in the class comment, 
which loads the stable default. Similarly, I loaded 
ConfigurationOfXMLParserHTML(monty.62) and 
ConfigurationOfXMLParserStAX(monty.51), again using stable and default. When I 
try to run the XMLHTMLParser example I quoted below, I get an error message 
'MessageNotunderstood: receiver of "critical:" is nil'. The same message comes 
up with anything else I try with XMLHTMLParser or with StAXHTMLParser.

I am not really up to using the debugger on someone else's code, but the one 
thing I can see is that the problem lies in XMLKeyValueCache>>critical:, which 
has the code:
^ self mutex critical: aBlock
The problem being that mutex is nil. 

In my enthusiasm, I saved the updated image with the same name as the old 
image, which is now therefore overwritten. If I cannot solve this problem, my 
only way out is to rebuild my image from the Moose 6.0 download. Any 
suggestions gratefully received.

Thanks in advance

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
PBKResearch
Sent: 15 May 2017 19:16
To: 'Any question about pharo is welcome' 
Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 
encoding

Monty

Many thanks for this. My original purpose was just to answer Paul deBruicker's 
query, namely to parse an html file and stop reading at the end of the  
section. I solved this by trial and error using the code shown below ( which 
actually stops at the opening tag of the body). This was not my problem at all, 
but Paul's; I just tackled it for fun.

However, you note has prompted me to update my version of the whole XML system 
- I was using the version I downloaded with Moose 6.0, which was dated August 
2016. I am looking at the StAX parsers as a possible way of simplifying what I 
currently do, which involves downloading an entire web page as a DOM and then 
manipulating it with XPath to extract the bits I am interested in. I may be 
able to use StAX to do some of the selection and manipulation as I am reading.

It's all a new topic to me, so I foresee a lot of experimentation. It all helps 
to keep the grey matter active.

Thanks again

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
monty
Sent: 15 May 2017 12:15
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 
encoding

For that kind of incremental parsing, you could also use XMLParserStAX, a 
pull-parser that parses a document as a stream of event objects you control 
with #next, #peek, and #atEnd. It also supports pull-DOM parsing with messages 
like #nextNode, #nextElement, and #nextElementNamed:, which return the next 
event object(s) as DOM subtrees (searchable with XPath). See the StAXParser 
class comment for an example. (The StAXHTMLParser class requires XMLParserHTML 
be installed to work.)

> Sent: Friday, May 12, 2017 at 5:30 AM
> From: PBKResearch 
> To: "'Any question about pharo is welcome'" 
> 
> Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte 
> for utf-8 encoding
>
> With reference to Norbert's comment, there /may/ be an ambiguity about 
> the word 'header' in Udo's reply. It could refer to the http HEAD 
> section, in which case Norbert is of course right. It could also refer 
> to the  section of the html file, which is part of the content of the 
> http response.
> If it is the latter, this is similar to a question that Paul 
> deBruicker posted last November ("[Pharo-users] ZnClient GET, but just 
> the  content of the  tag?"). I tried the method I devised for 
> Paul's case on Udo's problem website, and read the html header with no 
> problem. Incidentally, the header includes 'charset=iso-8859-1', which 
> does not agree with Sven's findings.
> 
> In case it is of interest, I used XMLHTMLParser to read and parse the 
> header. Try the following in a Playground:
> 
> par := XMLHTMLParser onURL:
> 'http://www.darkreading.com/partner-perspectives/malwarebytes/locky-re
> turns- with-a-new-(borrowed)-distribution-method/a/d-id/1328723'.
> par parseDocumentUntil: [|top|(top := par topNode) notNil and: [ top 
> isElement and:[ top isNamed: 'body']]].
> par parsingResult findElementNamed: 'head'.
> 
> If you 'Do it and go', the full header appears. The way I get it to 
> stop after the header may not be quite correct, because it uses
> XMLHTMLParser>>topNode, which is a private method. On the other hand, 
> XMLHTMLParser>>I
> can't see how to make 

Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding

[PBKResearch]

Monty

Many thanks for this. My original purpose was just to answer Paul deBruicker's 
query, namely to parse an html file and stop reading at the end of the  
section. I solved this by trial and error using the code shown below ( which 
actually stops at the opening tag of the body). This was not my problem at all, 
but Paul's; I just tackled it for fun.

However, you note has prompted me to update my version of the whole XML system 
- I was using the version I downloaded with Moose 6.0, which was dated August 
2016. I am looking at the StAX parsers as a possible way of simplifying what I 
currently do, which involves downloading an entire web page as a DOM and then 
manipulating it with XPath to extract the bits I am interested in. I may be 
able to use StAX to do some of the selection and manipulation as I am reading.

It's all a new topic to me, so I foresee a lot of experimentation. It all helps 
to keep the grey matter active.

Thanks again

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
monty
Sent: 15 May 2017 12:15
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 
encoding

For that kind of incremental parsing, you could also use XMLParserStAX, a 
pull-parser that parses a document as a stream of event objects you control 
with #next, #peek, and #atEnd. It also supports pull-DOM parsing with messages 
like #nextNode, #nextElement, and #nextElementNamed:, which return the next 
event object(s) as DOM subtrees (searchable with XPath). See the StAXParser 
class comment for an example. (The StAXHTMLParser class requires XMLParserHTML 
be installed to work.)

> Sent: Friday, May 12, 2017 at 5:30 AM
> From: PBKResearch 
> To: "'Any question about pharo is welcome'" 
> 
> Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte 
> for utf-8 encoding
>
> With reference to Norbert's comment, there /may/ be an ambiguity about 
> the word 'header' in Udo's reply. It could refer to the http HEAD 
> section, in which case Norbert is of course right. It could also refer 
> to the  section of the html file, which is part of the content of the 
> http response.
> If it is the latter, this is similar to a question that Paul 
> deBruicker posted last November ("[Pharo-users] ZnClient GET, but just 
> the  content of the  tag?"). I tried the method I devised for 
> Paul's case on Udo's problem website, and read the html header with no 
> problem. Incidentally, the header includes 'charset=iso-8859-1', which 
> does not agree with Sven's findings.
> 
> In case it is of interest, I used XMLHTMLParser to read and parse the 
> header. Try the following in a Playground:
> 
> par := XMLHTMLParser onURL:
> 'http://www.darkreading.com/partner-perspectives/malwarebytes/locky-re
> turns- with-a-new-(borrowed)-distribution-method/a/d-id/1328723'.
> par parseDocumentUntil: [|top|(top := par topNode) notNil and: [ top 
> isElement and:[ top isNamed: 'body']]].
> par parsingResult findElementNamed: 'head'.
> 
> If you 'Do it and go', the full header appears. The way I get it to 
> stop after the header may not be quite correct, because it uses
> XMLHTMLParser>>topNode, which is a private method. On the other hand, 
> XMLHTMLParser>>I
> can't see how to make the stop condition for
> XMLHTMLParser>>parseDocumentUntil: depend on the parsed results 
> XMLHTMLParser>>without
> using a private method.
> 
> Hope this is helpful
> 
> Peter Kenny
> 
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On 
> Behalf Of Norbert Hartl
> Sent: 12 May 2017 08:04
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte 
> for
> utf-8 encoding
> 
> Just to mention. If you are not interested in the content body you 
> could do a HEAD request instead of GET.
> 
> Norbert
> 
> > Am 11.05.2017 um 22:44 schrieb Udo Schneider
> :
> > 
> > Hi Sven,
> > 
> > that's perfect. To be honest I don't care about the content - I'm 
> > just
> parsing the header. And even if there is a wrong decoding in there... 
> I can live with that.
> > 
> > Thank you very very much! For your help but also your stuff in general.
> > 
> > CU,
> > 
> > Udo
> > 
> > 
> >> Am 11/05/17 um 22:35 schrieb Sven Van Caekenberghe:
> >> Hi Udo,
> >>> On 11 May 2017, at 21:37, Udo Schneider 
> >>> 
> wrote:
> >>> 
> >>> All,
> >>> 
> >>> I'm hitting an error where fetching web content fails. The website 
> >>> does
> indeed use invalid characters.
> >>> 
> >>> The easiest way to reproduce:
> >>> 
> >>> ZnEasy get:
> 'http://www.darkreading.com/partner-perspectives/malwarebytes/locky-re
> turns- with-a-new-(borrowed)-distribution-method/a/d-id/1328723'
> >>> 
> >>> Is there any way to tell Zinc to simply 

[Pharo-users] Is there a bind key to go to next argument?

[Andreas Sunardi]

Is there a bind key to jump to the next argument slot? After using TAB for
method completion, I wonder if there's a key/command to jump to the next
argument slot. I checked the keymap browser and either it isn't there or I
missed it.

The closest I've done so far is Meta + Right, but this needs to be
performed 3 times to go to the next argument.

--
Andreas

[Pharo-users] HiDPI

[Steven R. Baker]

Heya folks,

I have a laptop with a 3K screen. Is it possible to tell Pharo to render
everything at a double resolution or something? I feel like this ought
to have been a solved problem already, sorry if it's really obvious and
I just haven't found it.

I use Debian if that matters; I suspect this just works out of the box
on Macs.

Cheers!

-Steven

[Pharo-users] Vm crash

[Cyril Ferlicot D.]

Hello,

At Synectique a client reported us a problem that we cannot reproduce.

The vm crash and the error displayed is:

stack page bytes 4096 available headroom 3300 minimum unused headroom 1880
launchServer.sh: line 2: 34556 Aborted (core dumped)
pharo-linux-vm/pharo Pharo.image serverDeployment

The vm is the stable vm for Pharo 4.

Does someone knows what can cause this kind of problem?

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding

[monty]

For that kind of incremental parsing, you could also use XMLParserStAX, a 
pull-parser that parses a document as a stream of event objects you control 
with #next, #peek, and #atEnd. It also supports pull-DOM parsing with messages 
like #nextNode, #nextElement, and #nextElementNamed:, which return the next 
event object(s) as DOM subtrees (searchable with XPath). See the StAXParser 
class comment for an example. (The StAXHTMLParser class requires XMLParserHTML 
be installed to work.)

> Sent: Friday, May 12, 2017 at 5:30 AM
> From: PBKResearch 
> To: "'Any question about pharo is welcome'" 
> Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for 
> utf-8 encoding
>
> With reference to Norbert's comment, there /may/ be an ambiguity about the
> word 'header' in Udo's reply. It could refer to the http HEAD section, in
> which case Norbert is of course right. It could also refer to the 
> section of the html file, which is part of the content of the http response.
> If it is the latter, this is similar to a question that Paul deBruicker
> posted last November ("[Pharo-users] ZnClient GET, but just the  content of
> the  tag?"). I tried the method I devised for Paul's case on Udo's
> problem website, and read the html header with no problem. Incidentally, the
> header includes 'charset=iso-8859-1', which does not agree with Sven's
> findings.
> 
> In case it is of interest, I used XMLHTMLParser to read and parse the
> header. Try the following in a Playground:
> 
> par := XMLHTMLParser onURL:
> 'http://www.darkreading.com/partner-perspectives/malwarebytes/locky-returns-
> with-a-new-(borrowed)-distribution-method/a/d-id/1328723'.
> par parseDocumentUntil: [|top|(top := par topNode) notNil and: [ top
> isElement and:[ top isNamed: 'body']]].
> par parsingResult findElementNamed: 'head'.
> 
> If you 'Do it and go', the full header appears. The way I get it to stop
> after the header may not be quite correct, because it uses
> XMLHTMLParser>>topNode, which is a private method. On the other hand, I
> can't see how to make the stop condition for
> XMLHTMLParser>>parseDocumentUntil: depend on the parsed results without
> using a private method.
> 
> Hope this is helpful
> 
> Peter Kenny
> 
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of
> Norbert Hartl
> Sent: 12 May 2017 08:04
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for
> utf-8 encoding
> 
> Just to mention. If you are not interested in the content body you could do
> a HEAD request instead of GET. 
> 
> Norbert
> 
> > Am 11.05.2017 um 22:44 schrieb Udo Schneider
> :
> > 
> > Hi Sven,
> > 
> > that's perfect. To be honest I don't care about the content - I'm just
> parsing the header. And even if there is a wrong decoding in there... I can
> live with that.
> > 
> > Thank you very very much! For your help but also your stuff in general.
> > 
> > CU,
> > 
> > Udo
> > 
> > 
> >> Am 11/05/17 um 22:35 schrieb Sven Van Caekenberghe:
> >> Hi Udo,
> >>> On 11 May 2017, at 21:37, Udo Schneider 
> wrote:
> >>> 
> >>> All,
> >>> 
> >>> I'm hitting an error where fetching web content fails. The website does
> indeed use invalid characters.
> >>> 
> >>> The easiest way to reproduce:
> >>> 
> >>> ZnEasy get:
> 'http://www.darkreading.com/partner-perspectives/malwarebytes/locky-returns-
> with-a-new-(borrowed)-distribution-method/a/d-id/1328723'
> >>> 
> >>> Is there any way to tell Zinc to simply ignore that error and to
> continue?
> >>> 
> >>> CU,
> >>> 
> >>> Udo
> >> That server/page has a mime-type text/plain with no explicit encoding
> (charset) setting, so we have to guess. Like utf-8, pure latin1/iso88591
> does not work. The following does work, but you can't be sure everything
> went well (beLenient takes some bytes as they are).
> >> ZnDefaultCharacterEncoder
> >>   value: ZnCharacterEncoder latin1 beLenient
> >>   during: [
> >> ZnClient new
> >>   get:
> 'http://www.darkreading.com/partner-perspectives/malwarebytes/locky-returns-
> with-a-new-(borrowed)-distribution-method/a/d-id/1328723';
> >>   yourself ].
> >> I added some API earlier today, so that the following should also work
> (you need to load Zn #bleedingEdge first).
> >>  ZnClient new
> >>   defaultEncoder: ZnCharacterEncoder latin1 beLenient;
> >>   get:
> 'http://www.darkreading.com/partner-perspectives/malwarebytes/locky-returns-
> with-a-new-(borrowed)-distribution-method/a/d-id/1328723';
> >>   yourself.
> >> HTH,
> >> Regards,
> >> Sven
> > 
> > 
> > 
> 
> 
> 
> 

Re: [Pharo-users] SSL/TLS plugin initailization failed (VM plugin missing ? OS libraries missing ?)

[Julien Delplanque]

Ok, I found a way to fix the problem.

Simply, I needed to install the package lib32-libopenssl-1.0-compat 
which contains
the library with "1.0.0" version. This should be added as dependency to 
the package

in AUR. (the command: # yaourt -S lib32-libopenssl-1.0-compat)

I can help for that if needed. Who manage the pharo-related packages for 
Arch?


Julien


On 09/05/17 11:24, Sven Van Caekenberghe wrote:

For Pharo 5, on the same machine:

$ curl get.pharo.org/50+vm | bash
...

$ ./pharo --version
5.0 #1 Wed May  4 11:54:28 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM]
CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 
May  4 2016
StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: 
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
https://github.com/pharo-project/pharo-vm.git Commit: 
b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban 
Lorenzano  Jenkins build #589
Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 
2012 i686 i686 i386 GNU/Linux

$ ./pharo Pharo.image printVersion
[version] 5.0 #50772
$ ./pharo Pharo.image eval "ZnClient new get: 'https://pharo.org'"
4149724864:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
handshake failure:s23_clnt.c:769:
ConnectionClosed: Connection closed while waiting for data.
...

This is normal, see 
https://pharo.fogbugz.com/f/cases/19864/Add-support-for-Server-Name-Indication-SNI-to-Zodiac-SSLPlugin
 which is integrated in 6 but not in 5.

Note that the error is different from yours (no linking error, a runtime error).

With other HTTPS sites, it still works on 5:

audio359@audio359:~/pharo-dev/pharo5$ ./pharo Pharo.image eval "ZnClient new get: 
'https://audio359.eu'"
...


On 9 May 2017, at 09:08, Julien Delplanque  wrote:

Hello,

I did the same thing as you and it works.

When I do:

./pharo --version

I get:

5.0-201705022326  Tue May  2 23:46:52 UTC 2017 gcc 4.6.3 [Production Spur ITHB 
VM]
CoInterpreter VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 
May  2 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2203 uuid: 
12d4afae-8498-4e76-8efe-60eba6ef4db2 May  2 2017
VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: 
Tue May 2 16:26:41 2017 -0700 $
Plugins: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Linux testing-gce-7a7e75c9-f535-4934-bad2-d5fb6fd60cee 3.13.0-103-generic 
#150~precise1-Ubuntu SMP Thu Nov 24 11:05:34 UTC 2016 i686 i686 i386 GNU/Linux
plugin path: /tmp/pharo/pharo-vm/lib/pharo/5.0-201705022326 [default: 
/tmp/pharo/pharo-vm/lib/pharo/5.0-201705022326/]

And when I check the version of the VM currently installed on my system:

pharo-spur

I get:

5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM]
CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 
16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 
16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
https://github.com/pharo-project/pharo-vm.git Commit: 
9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 By: GitHub 
 Jenkins build #594
Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 
2012 i686 i686 i386 GNU/Linux
plugin path: /usr/share/pharo/spur/ [default: /usr/share/pharo/spur/]

So apparently those are not the same VMs.

Nevertheless, when I open Pharo 6 image that I got using your curl command, it
using the network works with  both VM.

So, I tried to load a Pharo 5 image with the VM:

curl get.pharo.org/50+vm | bash

And when I do:

./pharo Pharo.image eval "ZnClient new get: 'https://pharo.org'"

I get:

ioLoadModule(/tmp/pharo2/pharo-vm/libSqueakSSL.so):
  /usr/lib32/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by 
/tmp/pharo2/pharo-vm/libSqueakSSL.so)
ZdcPluginMissing: SSL/TLS plugin initailization failed (VM plugin missing ? OS 
libraries missing ?)
[ :exception | ZdcPluginMissing signal ] in ZdcPluginSSLSession>>initialize in 
Block: [ :exception | ZdcPluginMissing signal ]
BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
PrimitiveFailed(Exception)>>signal
PrimitiveFailed class(SelectorException class)>>signalFor:
ZdcPluginSSLSession(Object)>>primitiveFailed:
ZdcPluginSSLSession(Object)>>primitiveFailed
ZdcPluginSSLSession>>primitiveSSLCreate
[ handle := self primitiveSSLCreate ] in ZdcPluginSSLSession>>initialize in 
Block: [ handle := self primitiveSSLCreate ]
BlockClosure>>on:do:
ZdcPluginSSLSession>>initialize
ZdcPluginSSLSession class(Behavior)>>new
ZdcSecureSocketStream>>sslSession
ZdcSecureSocketStream>>connect
ZnClient>>setupTLSTo:
ZnClient>>newConnectionTo:
ZnClient>>getConnectionAndExecute
ZnClient>>executeWithRedirectsRemaining:
[ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in 
ZnClient>>executeWithRetriesRemaining: 

Re: [Pharo-users] Windows equivalent of kill -s SIGUSR1?

[Alistair Grant]

Hi Subbu,

On Mon, May 15, 2017 at 11:16:45AM +0530, K K Subbu wrote:
> On Monday 15 May 2017 02:47 AM, Alistair Grant wrote:
> >The subject pretty much says it all: Is there an equivalent on Windows
> >to the linux
> >
> >kill -s SIGUSR1 
> >
> >that gets the VM to dump its current status?
> 
> signals is unix-specific IPC. On Windows, you should be able to "create dump
> file" from right-click menu on Task Manager's process list (if you have the
> perms, of course!).
> 
> If you do a lot of system work on windows, sysinternals suite could be very
> useful. It has many utilities for advanced operations (Procdump?) on
> processes and files.

It looks like "dump" was a poor choice of words, as I expanded on in my
reply to Henrik, it's about requesting the VM to print out its internal
information.  The VM continues to function "normally" after the request
has been processed.

Thanks,
Alistair