Re: [Pharo-users] How to make pharo find sqlite?

[Alistair Grant]

On Sat, Sep 30, 2017 at 01:28:06PM +0200, Herby Vojk wrote:
> p...@highoctane.be wrote:
> >What about
> >
> >LD_LIBRARY_PATH=;$LD_LIBRARYPATH  ./pharo-ui some.image
> >
> >Phil
> 
> Thanks for answer, did not help.
> 
> In fact it must be something different. As can be seen in the stack, it
> fails during finalizers, and as can be seen by looking at
> UDBCSQLite3DatabaseExternalObject class>>finalizeResourceData: code, the
> method it calls is sqlite close. It is hardly the first method that is
> should call...
> 
> I suspect something around image save / load. Again. Lots of errors in those
> parts. But may be something else, as it kicks in only when SQLite-using
> tests starts to run. :-(
> 
> Herby
> 
> P.S.: I saw there is a similar thread out there, but it has problems with
> 32bit loaded by 64bit vm; but here, I have 32bit linux, so the vm installed
> should be 32bit.


Sorry I'm a bit late to the party...

I'm using Glorp / UDBCSQLite3 on Ubuntu 16.04 without any problems
(admittedly 64 bit Ubuntu, but as you say, that shouldn't matter).

Just in case you copy-and-pasted the code, Phil's example has a typo:
the path separator is a colon (:), not semicolon (;).

Install libsqlite3-dev and adding /usr/lib/i386-linux-gnu to
LD_LIBRARY_PATH is all I had to do to get it to work (no changes to
UDBCSQLite3Library>>library).  Actually LD_LIBRARY_PATH normally
shouldn't be required, but I'm running inside a snap container, which is
an unusual environment.



> root@32bit-agent:~# find / -name '*libsqlite*' -type f 
> 2>>/dev/null
> /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6

It seems strange that there isn't libsqlite3.so.  I think the real
solution would be to find out why libsqlite3.so doesn't exist, but after
installing libsqlite3-dev, a workaround would be to try creating a
symbolic link from libsqlite3.so.0.8.6 to libsqlite3.so.



Cheers,
Alistair

[Pharo-users] Problem with input to XML Parser - 'Invalid UTF8 encoding'

[PBKResearch]

In another thread (on SVG Icons) Sven referred to ways of getting input from
a URL for XMLDOMParser. I have recently had some problems doing this. I have
found a workaround, so it is not urgent, but I thought I should put it on
record in case anyone else is bitten by it, and so maybe Monty can look at
it.

 

I am using the subclass XMLHTMLParser, and my usual way of invoking it was:

1.  XMLHTMLParser parseURL: .

This works in most cases, but with one particular site -
http://www.corriere.it/., which is an Italian newspaper - I had frequent
failures, with the error message 'Invalid UTF8 encoding'. The parser has the
option of parsing a string, which is obtained by other means, so I tried
reading it in with Zinc:

2.  XMLHTMLParser parse:  asZnUrl retrieveContents.

And this worked, so clearly the encoding on the site is OK. I realised that
the XML-Parser package has its own methods, which reproduce a lot of the
functionality of Zinc, so I tried the equivalent:

3.  XMLHTMLParser parse:  asXMLURI get.

To my surprise, this worked equally well. I had expected problems, because
presumably forms (1) and (3) use the same UTF8 decoding.

 

For now, I am using the form (3) for all my work, and have not had any
problems since. So the message to anyone who is using the form (1) and
getting problems is to try (2) or (3) instead.

 

I am using Moose 6.1 (Pharo 6.0 Latest update: #60486) on Windows 10. I
think most articles on the Corriere web site will generate the error, but
one which has always failed for me is:

http://www.corriere.it/esteri/17_ottobre_03/felipe-spagna-catalogna-discorso
-8f7ac0d6-a86d-11e7-a090-96160224e787.shtml

I tried to trace through the error using the debugger, but it got too
confusing. However, I did establish that the failure occurred early in
decoding the HTML , in the line beginning 

Re: [Pharo-users] FileReference#entries caching?

[Guillermo Polito]

Hi,

I don't think that FileSystem is caching entries... However, we found
somehow related bug the other day with Mariano and Pablo while running
OSSupprocess tests on travis/linux. The bug is as follows. The test was
doing:

'/tmp' asFileReference entries do: [...]

And then it was calling 'lsof' over pharo's pid to know files that pharo
has open.

funny thing is that lsof was telling us that '/tmp' was open! When we
already retrieved the entries and the file reference was collected...

The same in osx or local linux mate running in a virtual box did not happen
:/.



On Sat, Oct 7, 2017 at 5:44 PM, Steven R. Baker 
wrote:

>
>
> On 07/10/17 14:22, Peter Uhnák wrote:
>
> On Sat, Oct 7, 2017 at 1:02 PM, Steven R. Baker 
> wrote:
>
>> Is it cached or something? How do I guarantee that I'm *definitely*
>> getting the current state of the directory on disk?
>
>
> This looks extremely strange, I've never seen that inspecting
> files/directories would be somehow "out of sync" with the disk, because it
> is always asking the disk.
>
>
>
> Should I not even be using FileReference for this?
>>
>
> If you are loading png icons into Pharo, you can consider using
> https://github.com/peteruhnak/IconFactory/ instead (shameless self
> promotion :) )
>
>
> Will definitely switch to this; I wasn't aware of the pattern, but
> obviously I want to follow them where possible. :)
>
> Peter
>
>
>


-- 



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] Futures, in Scale (was: Re: Embeddable Smalltalk (was: Re: Behold Pharo: The Modern Smalltalk))

[Guillermo Polito]

Hi Herby,

Scale does not implement futures by itself. It uses the ones implemented in
taskit:

https://github.com/sbragagnolo/taskit

On Sat, Oct 7, 2017 at 2:22 PM, Herby Vojčík  wrote:

> Hi,
>
> I have looked at Scale b/c of different question, and I see it uses
> futures.
>
> I'd like to ask if those futures are one-off, or is there any consensus on
> how futures should look like in Pharo. The reason I ask is b/c Amber
> already has something like that - Promises, which do not use the native JS
> API directly (though it is inspired), but do have an API of their own; and
> since those concepts seems to be similar (or maybe are the same, just
> called differently), if the API used shouldn't be sort-of standardized /
> used the same way in all occasions.
>
> Herby
>
> P.S.: Including state-of-the-art Promises.st from Amber master branch to
> get a picture:
>
> Smalltalk createPackage: 'Kernel-Promises'!
> Object subclass: #Promise
> instanceVariableNames: ''
> package: 'Kernel-Promises'!
>
> !Promise class methodsFor: 'composites'!
>
> all: aCollection
> "Returns a Promise resolved with results of sub-promises."
> 
> !
>
> any: aCollection
> "Returns a Promise resolved with first result of sub-promises."
> 
> ! !
>
> !Promise class methodsFor: 'instance creation'!
>
> forBlock: aBlock
> "Returns a Promise that is resolved with the value of aBlock,
> and rejected if error happens while evaluating aBlock."
> ^ self new then: aBlock
> !
>
> new
> "Returns a dumb Promise resolved with nil."
> 
> !
>
> new: aBlock
> "Returns a Promise that is eventually resolved or rejected.
> Pass a block that is called with one argument, model.
> You should call model value: ... to resolve the promise
> and model signal: ... to reject the promise.
> If error happens during run of the block,
> promise is rejected with that error as well."
>  var model = {value: resolve, signal: reject};
> aBlock._value_(model);
> })'>
> !
>
> signal: anObject
> "Returns a Promise rejected with anObject."
>  Promise.reject(x)})'>
> !
>
> value: anObject
> "Returns a Promise resolved with anObject."
>  Promise.resolve(x)})'>
> ! !
>
> Trait named: #TThenable
> package: 'Kernel-Promises'!
>
> !TThenable methodsFor: 'promises'!
>
> catch: aBlock
>  $core.seamless(function () {
> return aBlock._value_(err);
> })})'>
> !
>
> on: aClass do: aBlock
>  $core.seamless(function () {
> if (err._isKindOf_(aClass)) return aBlock._value_(err);
> else throw err;
> })})'>
> !
>
> on: aClass do: aBlock catch: anotherBlock
> ^ (self on: aClass do: aBlock) catch: anotherBlock
> !
>
> then: aBlockOrArray
> "Accepts a block or array of blocks.
> Each of blocks in the array or the singleton one is
> used in .then call to a promise, to accept a result
> and transform it to the result for the next one.
> In case a block has more than one argument
> and result is an array, first n-1 elements of the array
> are put into additional arguments beyond the first.
> The first argument always contains the result as-is."
>  var array = Array.isArray(aBlockOrArray) ? aBlockOrArray : [aBlockOrArray];
> return array.reduce(function (soFar, aBlock) {
> return soFar.then(typeof aBlock === "function" && aBlock.length > 1 ?
> function (result) {return $core.seamless(function () {
> if (Array.isArray(result)) {
> return aBlock._valueWithPossibleArgum
> ents_([result].concat(result.slice(0, aBlock.length-1)));
> } else {
> return aBlock._value_(result);
> }
> })} :
> function (result) {return $core.seamless(function () {
> return aBlock._value_(result);
> })}
> );
> }, self)'>
> !
>
> then: aBlockOrArray catch: anotherBlock
> ^ (self then: aBlockOrArray) catch: anotherBlock
> !
>
> then: aBlockOrArray on: aClass do: aBlock
> ^ (self then: aBlockOrArray) on: aClass do: aBlock
> !
>
> then: aBlockOrArray on: aClass do: aBlock catch: anotherBlock
> ^ ((self then: aBlockOrArray) on: aClass do: aBlock) catch:
> anotherBlock
> ! !
>
> Promise setTraitComposition: {TThenable} asTraitComposition!
> ! !
>
>
>
> p...@highoctane.be wrote:
>
>> https://github.com/guillep/Scale  is
>> quite cool for quick scripts on *nix.
>>
>> Now for embeddable, yes it would help. Bootstrapping will be helpful but
>> the current main issue is the VM interpret loop that is in the current
>> VMs.
>>
>> It is not an intrinsic problem. Telepharo is also a great step to enable
>> that to exist.
>>
>> Phil
>>
>> On Oct 7, 2017 13:05, "Herby Vojčík" > > wrote:
>>
>> Ben Coman wrote:
>>
>> Nice article. I like the way you've structured it and pushed the
>> "updated" angle.
>>
>> I feel a bit too strong a claim is laid on Pharo producing the
>> CogVM.
>> Much of the Cog + Spur + 64bit VM work was originally done for
>> 

[Pharo-users] Can't find Cairo

[Steven R. Baker]

Heya,

I need some help telling Pharo where to find things. I've installed Bloc
into my image, and it can't find cairo. Cairo is installed, but as far
as I can tell Bloc is not looking for it in /usr/lib/x86_64-linux-gnu/
which is where it can be found.

I don't care to go making symlinks around my system: is there a sensible
way to tell Pharo where to find libcairo?

Thanks!

-Steven

Re: [Pharo-users] FileReference#entries caching?

[Alistair Grant]

On Sun, Oct 08, 2017 at 06:33:08PM +0200, Guillermo Polito wrote:
> Hi,
> 
> I don't think that FileSystem is caching entries...

I haven't seen any code in the Pharo image or FilePlugin that caches
data.


> However, we found somehow
> related bug the other day with Mariano and Pablo while running OSSupprocess
> tests on travis/linux. The bug is as follows. The test was doing:
> 
> '/tmp' asFileReference entries do: [...]
> 
> And then it was calling 'lsof' over pharo's pid to know files that pharo has
> open.
> 
> funny thing is that lsof was telling us that '/tmp' was open! When we already
> retrieved the entries and the file reference was collected...
> 
> The same in osx or local linux mate running in a virtual box did not happen 
> :/.

I was able to reproduce the issue on Ubuntu 16.04 using
Pharo7.0-32bit-d13eed2.image.

I haven't tracked the cause down, but the problem doesn't exist with the
proposed fix I have for symbolic links (fogbugz 18279
https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Linux).
This patch also updates the code responsible for iterating over
directories, which is why it can resolve this issue as well.


Cheers,
Alistair


> On Sat, Oct 7, 2017 at 5:44 PM, Steven R. Baker 
> wrote:
> 
>
> 
> 
> On 07/10/17 14:22, Peter Uhn?k wrote:
> 
> On Sat, Oct 7, 2017 at 1:02 PM, Steven R. Baker <
> ste...@stevenrbaker.com> wrote:
> 
> Is it cached or something? How do I guarantee that I'm 
> *definitely*
> getting the current state of the directory on disk?
> 
> 
> This looks extremely strange, I've never seen that inspecting files/
> directories would be somehow "out of sync" with the disk, because it 
> is
> always asking the disk.
> 
> 
> 
> 
> Should I not even be using FileReference for this?
> 
> 
> If you are loading png icons into Pharo, you can consider using 
> https:/
> /github.com/peteruhnak/IconFactory/ instead (shameless self promotion
> :) )
> 
> 
> Will definitely switch to this; I wasn't aware of the pattern, but
> obviously I want to follow them where possible. :)
> 
> 
> Peter
> 
> 
> 
> 
> 
> 
> --
>[presentation] Guille Polito
> [CNRS-filaire]
>   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] How to make pharo find sqlite?

[p...@highoctane.be]

Oh my, am doing too much Windows at the moment.

Phil

On Sat, Oct 7, 2017 at 11:47 PM, Alistair Grant 
wrote:

> On Sat, Sep 30, 2017 at 01:28:06PM +0200, Herby Vojk wrote:
> > p...@highoctane.be wrote:
> > >What about
> > >
> > >LD_LIBRARY_PATH=;$LD_LIBRARYPATH  ./pharo-ui some.image
> > >
> > >Phil
> >
> > Thanks for answer, did not help.
> >
> > In fact it must be something different. As can be seen in the stack, it
> > fails during finalizers, and as can be seen by looking at
> > UDBCSQLite3DatabaseExternalObject class>>finalizeResourceData: code, the
> > method it calls is sqlite close. It is hardly the first method that is
> > should call...
> >
> > I suspect something around image save / load. Again. Lots of errors in
> those
> > parts. But may be something else, as it kicks in only when SQLite-using
> > tests starts to run. :-(
> >
> > Herby
> >
> > P.S.: I saw there is a similar thread out there, but it has problems with
> > 32bit loaded by 64bit vm; but here, I have 32bit linux, so the vm
> installed
> > should be 32bit.
>
>
> Sorry I'm a bit late to the party...
>
> I'm using Glorp / UDBCSQLite3 on Ubuntu 16.04 without any problems
> (admittedly 64 bit Ubuntu, but as you say, that shouldn't matter).
>
> Just in case you copy-and-pasted the code, Phil's example has a typo:
> the path separator is a colon (:), not semicolon (;).
>
> Install libsqlite3-dev and adding /usr/lib/i386-linux-gnu to
> LD_LIBRARY_PATH is all I had to do to get it to work (no changes to
> UDBCSQLite3Library>>library).  Actually LD_LIBRARY_PATH normally
> shouldn't be required, but I'm running inside a snap container, which is
> an unusual environment.
>
>
>
> > root@32bit-agent:~# find / -name '*libsqlite*' -type f
> 2>>/dev/null
> > /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6
>
> It seems strange that there isn't libsqlite3.so.  I think the real
> solution would be to find out why libsqlite3.so doesn't exist, but after
> installing libsqlite3-dev, a workaround would be to try creating a
> symbolic link from libsqlite3.so.0.8.6 to libsqlite3.so.
>
>
>
> Cheers,
> Alistair
>
>
>

Re: [Pharo-users] Can't find Cairo

[Peter Uhnák]

Make sure you have the same image and lib version (64bit vs 32bit).

The paths where Pharo looks are described in CairoLibrary class.

CairoLibrary>>unix32ModuleName
"On different flavors of linux the path to library may differ
depending on OS distro or whether system is 32 or 64 bit.
Packages such as snapcraft can also change the path.
Look in a number of known locations, or LD_LIBRARY_PATH."

(#('/usr/lib/i386-linux-gnu' '/usr/lib32' '/usr/lib'),
(((OSEnvironment current getEnv: 'LD_LIBRARY_PATH') ifNil: [ '' ])
substrings: ':'))
do: [ :path |
| libraryPath |
libraryPath := path asFileReference / 'libcairo.so.2'.
libraryPath exists
ifTrue: [ ^ libraryPath fullName ] ].
self error: 'Cannot locate cairo library. Please check if it installed on
your system'

CairoLibrary>>unix64ModuleName
"On different flavors of linux the path to library may differ
depending on OS distro or whether system is 32 or 64 bit.
Packages such as snapcraft can also change the path.
Look in a number of known locations, or LD_LIBRARY_PATH."

(#('/lib/x86_64-linux-gnu' '/usr/lib'),
(((OSEnvironment current getEnv: 'LD_LIBRARY_PATH') ifNil: [ '' ])
substrings: ':'))
do: [ :path |
| libraryPath |
libraryPath := path asFileReference / 'libcairo.so.2'.
libraryPath exists
ifTrue: [ ^ libraryPath fullName ] ].
self error: 'Cannot locate cairo library. Please check if it installed on
your system'

Cheers,
Peter

On Sun, Oct 8, 2017 at 6:34 PM, Steven R. Baker 
wrote:

> Heya,
>
> I need some help telling Pharo where to find things. I've installed Bloc
> into my image, and it can't find cairo. Cairo is installed, but as far
> as I can tell Bloc is not looking for it in /usr/lib/x86_64-linux-gnu/
> which is where it can be found.
>
> I don't care to go making symlinks around my system: is there a sensible
> way to tell Pharo where to find libcairo?
>
> Thanks!
>
> -Steven
>
>
>
>

Re: [Pharo-users] FileReference#entries caching?

[Guillermo Polito]

On Sun, Oct 8, 2017 at 7:01 PM, Alistair Grant 
wrote:

> On Sun, Oct 08, 2017 at 06:33:08PM +0200, Guillermo Polito wrote:
> > Hi,
> >
> > I don't think that FileSystem is caching entries...
>
> I haven't seen any code in the Pharo image or FilePlugin that caches
> data.
>
>
> > However, we found somehow
> > related bug the other day with Mariano and Pablo while running
> OSSupprocess
> > tests on travis/linux. The bug is as follows. The test was doing:
> >
> > '/tmp' asFileReference entries do: [...]
> >
> > And then it was calling 'lsof' over pharo's pid to know files that pharo
> has
> > open.
> >
> > funny thing is that lsof was telling us that '/tmp' was open! When we
> already
> > retrieved the entries and the file reference was collected...
> >
> > The same in osx or local linux mate running in a virtual box did not
> happen :/.
>
> I was able to reproduce the issue on Ubuntu 16.04 using
> Pharo7.0-32bit-d13eed2.image.
>
> I haven't tracked the cause down, but the problem doesn't exist with the
> proposed fix I have for symbolic links (fogbugz 18279
> https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-
> to-be-broken-on-Linux).
> This patch also updates the code responsible for iterating over
> directories, which is why it can resolve this issue as well.
>
>
Nice! How much time until we can integrate such thing ? :D


>
> Cheers,
> Alistair
>
>
> > On Sat, Oct 7, 2017 at 5:44 PM, Steven R. Baker  >
> > wrote:
> >
> >
> >
> >
> > On 07/10/17 14:22, Peter Uhn?k wrote:
> >
> > On Sat, Oct 7, 2017 at 1:02 PM, Steven R. Baker <
> > ste...@stevenrbaker.com> wrote:
> >
> > Is it cached or something? How do I guarantee that I'm
> *definitely*
> > getting the current state of the directory on disk?
> >
> >
> > This looks extremely strange, I've never seen that inspecting
> files/
> > directories would be somehow "out of sync" with the disk,
> because it is
> > always asking the disk.
> >
> >
> >
> >
> > Should I not even be using FileReference for this?
> >
> >
> > If you are loading png icons into Pharo, you can consider using
> https:/
> > /github.com/peteruhnak/IconFactory/ instead (shameless self
> promotion
> > :) )
> >
> >
> > Will definitely switch to this; I wasn't aware of the pattern, but
> > obviously I want to follow them where possible. :)
> >
> >
> > Peter
> >
> >
> >
> >
> >
> >
> > --
> >[presentation] Guille Polito
> > [CNRS-filaire]
> >   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
> >
>
>


-- 



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] FileReference#entries caching?

[Alistair Grant]

On Sun, Oct 08, 2017 at 07:08:41PM +0200, Guillermo Polito wrote:
> 
> 
> On Sun, Oct 8, 2017 at 7:01 PM, Alistair Grant  wrote:
> 
> On Sun, Oct 08, 2017 at 06:33:08PM +0200, Guillermo Polito wrote:
> > Hi,
> >
> > I don't think that FileSystem is caching entries...
> 
> I haven't seen any code in the Pharo image or FilePlugin that caches
> data.
>
> 
> > However, we found somehow
> > related bug the other day with Mariano and Pablo while running
> OSSupprocess
> > tests on travis/linux. The bug is as follows. The test was doing:
> >
> > '/tmp' asFileReference entries do: [...]
> >
> > And then it was calling 'lsof' over pharo's pid to know files that pharo
> has
> > open.
> >
> > funny thing is that lsof was telling us that '/tmp' was open! When we
> already
> > retrieved the entries and the file reference was collected...
> >
> > The same in osx or local linux mate running in a virtual box did not
> happen :/.
> 
> I was able to reproduce the issue on Ubuntu 16.04 using
> Pharo7.0-32bit-d13eed2.image.
> 
> I haven't tracked the cause down, but the problem doesn't exist with the
> proposed fix I have for symbolic links (fogbugz 18279
> https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-
> to-be-broken-on-Linux).
> This patch also updates the code responsible for iterating over
> directories, which is why it can resolve this issue as well.
> 
> 
> 
> Nice! How much time until we can integrate such thing ? :D

I submitted the code in August.  Eliot kindly provided some great
feedback with lots of details.  I submitted updated code on 6 September.
Since then I haven't seen anything from Eliot, so I hope everything is
OK.

Cheers,
Alistair



> Cheers,
> Alistair
>
> 
> > On Sat, Oct 7, 2017 at 5:44 PM, Steven R. Baker 
> 
> > wrote:
> >
> >
> >
> >
> > On 07/10/17 14:22, Peter Uhn?k wrote:
> >
> > On Sat, Oct 7, 2017 at 1:02 PM, Steven R. Baker <
> > ste...@stevenrbaker.com> wrote:
> >
> > Is it cached or something? How do I guarantee that I'm
> *definitely*
> > getting the current state of the directory on disk?
> >
> >
> > This looks extremely strange, I've never seen that inspecting
> files/
> > directories would be somehow "out of sync" with the disk, 
> because
> it is
> > always asking the disk.
> >
> >
> >
> >
> > Should I not even be using FileReference for this?
> >
> >
> > If you are loading png icons into Pharo, you can consider using
> https:/
> > /github.com/peteruhnak/IconFactory/ instead (shameless self
> promotion
> > :) )
> >
> >
> > Will definitely switch to this; I wasn't aware of the pattern, but
> > obviously I want to follow them where possible. :)
> >
> >
> > Peter
> >
> >
> >
> >
> >
> >
> > --
> >[presentation] Guille Polito
> > [CNRS-filaire]
> >   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
> >
> 
> 
> 
> 
> 
> --
>[presentation] Guille Polito
> [CNRS-filaire]
>   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] Problem with input to XML Parser - 'Invalid UTF8 encoding'

[Paul DeBruicker]

in the HEAD tag of that page with the article they declare it is ISO-8859-1
and not UTF-8.  In the page they have a  

C’è 

The little back-tick next to the C is UTF8 8217
(http://www.codetable.net/decimal/8217)


So their encoding is messed up, and maybe the XMLHTMLParser should throw a
warning or something if there is a mismatch.  


Glad you found a work around. 








In another thread (on SVG Icons) Sven referred to ways of getting input from
a URL for XMLDOMParser. I have recently had some problems doing this. I have
found a workaround, so it is not urgent, but I thought I should put it on
record in case anyone else is bitten by it, and so maybe Monty can look at
it.

 

I am using the subclass XMLHTMLParser, and my usual way of invoking it was:

1.  XMLHTMLParser parseURL: .

This works in most cases, but with one particular site -
http://www.corriere.it/., which is an Italian newspaper - I had frequent
failures, with the error message 'Invalid UTF8 encoding'. The parser has the
option of parsing a string, which is obtained by other means, so I tried
reading it in with Zinc:

2.  XMLHTMLParser parse:  asZnUrl retrieveContents.

And this worked, so clearly the encoding on the site is OK. I realised that
the XML-Parser package has its own methods, which reproduce a lot of the
functionality of Zinc, so I tried the equivalent:

3.  XMLHTMLParser parse:  asXMLURI get.

To my surprise, this worked equally well. I had expected problems, because
presumably forms (1) and (3) use the same UTF8 decoding.

 

For now, I am using the form (3) for all my work, and have not had any
problems since. So the message to anyone who is using the form (1) and
getting problems is to try (2) or (3) instead.

 

I am using Moose 6.1 (Pharo 6.0 Latest update: #60486) on Windows 10. I
think most articles on the Corriere web site will generate the error, but
one which has always failed for me is:

http://www.corriere.it/esteri/17_ottobre_03/felipe-spagna-catalogna-discorso
-8f7ac0d6-a86d-11e7-a090-96160224e787.shtml

I tried to trace through the error using the debugger, but it got too
confusing. However, I did establish that the failure occurred early in
decoding the HTML , in the line beginning 




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

Re: [Pharo-users] Problem with input to XML Parser - 'Invalid UTF8 encoding'

[PBKResearch]

Paul

Good to have found the charset discrepancy - that may have something to do with 
it. But I don't think it has to do with the C’è in the body of the page. I have 
just parsed another page published today, with the same error, and again it 
fails in parsing the  node, so it has not even reached the body. The 
 contains a meta which describes the article - a sort of paraphrase of 
the article headline - and it fails in the middle of decoding that. The 
character at which it fails is again $«, so that is definitely the cause. Maybe 
the wrong charset is the explanation of why it messes up that - but I don't 
know enough about the different charsets to know. Does ISO-8859-1 even contain 
$«?

Peter

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Paul DeBruicker
Sent: 08 October 2017 18:41
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Problem with input to XML Parser - 'Invalid UTF8 
encoding'

in the HEAD tag of that page with the article they declare it is ISO-8859-1 and 
not UTF-8.  In the page they have a  

C’è 

The little back-tick next to the C is UTF8 8217
(http://www.codetable.net/decimal/8217)


So their encoding is messed up, and maybe the XMLHTMLParser should throw a 
warning or something if there is a mismatch.  


Glad you found a work around. 








In another thread (on SVG Icons) Sven referred to ways of getting input from a 
URL for XMLDOMParser. I have recently had some problems doing this. I have 
found a workaround, so it is not urgent, but I thought I should put it on 
record in case anyone else is bitten by it, and so maybe Monty can look at it.

 

I am using the subclass XMLHTMLParser, and my usual way of invoking it was:

1.  XMLHTMLParser parseURL: .

This works in most cases, but with one particular site - 
http://www.corriere.it/., which is an Italian newspaper - I had frequent 
failures, with the error message 'Invalid UTF8 encoding'. The parser has the 
option of parsing a string, which is obtained by other means, so I tried 
reading it in with Zinc:

2.  XMLHTMLParser parse:  asZnUrl retrieveContents.

And this worked, so clearly the encoding on the site is OK. I realised that the 
XML-Parser package has its own methods, which reproduce a lot of the 
functionality of Zinc, so I tried the equivalent:

3.  XMLHTMLParser parse:  asXMLURI get.

To my surprise, this worked equally well. I had expected problems, because 
presumably forms (1) and (3) use the same UTF8 decoding.

 

For now, I am using the form (3) for all my work, and have not had any problems 
since. So the message to anyone who is using the form (1) and getting problems 
is to try (2) or (3) instead.

 

I am using Moose 6.1 (Pharo 6.0 Latest update: #60486) on Windows 10. I think 
most articles on the Corriere web site will generate the error, but one which 
has always failed for me is:

http://www.corriere.it/esteri/17_ottobre_03/felipe-spagna-catalogna-discorso
-8f7ac0d6-a86d-11e7-a090-96160224e787.shtml

I tried to trace through the error using the debugger, but it got too 
confusing. However, I did establish that the failure occurred early in decoding 
the HTML , in the line beginning 




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

[Pharo-users] Job offers

[Stephane Ducasse]

Two jobs in Europe:

In Le Mans France, CGI is looking for an OO developer, ideally
Smalltalk.   CGI is a French IT services company and works in lots of
different domains.  One clearly needs to be able to work in France,
and, most likely in French as well.

https://cgi.njoyn.com/cgi/xweb/xweb.asp?CLID=21001&page=jobdetails&JobID=J0917-0676&brid=571682&lang=1

The second is in Kaiserslautern Germany with Bison.  Bison is a Swiss
and German IT services company similar in many ways to CGI above.

http://jobview.monster.com/Software-Developer-m-w-Job-Kaiserslautern-Rheinland-Pfalz-DE-187973839.aspx?WT.mc_n=RSS2005_JSR

Good Luck!