[Pharo-users] Performance Testing Tools

[Evan Donahue]

Hi,

I've been doing a lot of performance testing lately, and I've found myself
wanting to upgrade my methods from ad hoc use of bench and message tally.
Is there any kind of framework for like, statistically comparing
improvements in performance benchmarks across different versions of code,
or anything that generally helps manage the test-tweak-test loop? Just
curious what's out there before I go writing something. Too many useful
little libraries to keep track of!

Evan

Re: [Pharo-users] could not find module vm-display-X11

[Alistair Grant]

Hi Hilaire,

On 18 July 2017 at 22:27, Hilaire  wrote:
> Hi,
>
> On Ubuntu 16.04 (Ubuntu MAte), I ahve the following error with DR. Geo
> (release based on Pharo3). Of course the needed 32bits libs are installed.
> Could it be the new graphic back end of Ubuntu?
>
>
> hilaire@PCHome:~/DrGeo.app$ ./DrGeo.sh could not find module vm-display-X11
> Abandon (core dumped)

Is this something that was working and has suddenly stopped, or a new
install that doesn't work?

Assuming that it is installed correctly, can you provide the output of:

cd /to/where/the/pharo/exe/is
ldd pharo
ldd vm-display-X11


Cheers,
Alistair

Re: [Pharo-users] bitAnd: Documentation

[Stephane Ducasse]

I opened a bug entry.
https://pharo.fogbugz.com/f/cases/20257/bitAnd-description-is-wrong

On Tue, Jul 18, 2017 at 11:16 PM, Stephane Ducasse
 wrote:
> Thanks Koos. This description is indeed wrong.
>
>
> On Tue, Jul 18, 2017 at 8:47 PM, Koos Brandt  wrote:
>> Hi
>>
>>  I am new to this environment
>>
>> I am on Pharo 6.0 - 64 Mac OSX version, Downloaded over the weekend.
>>
>> Just did some learning and found that the description for bitAnd: is
>> probably wrong.
>>
>> It reads exactly the same as bitOr:
>>
>> here are some tests as performed in the workspace
>> Also included bitXor: for the fun of it
>>
>> bitAnd: arg
>> Primitive. Answer an Integer whose bits are the logical OR of the
>> receiver's bits and those of the argument, arg.
>> Numbers are interpreted as having 2's-complement representation.
>> Essential.  See Object documentation whatIsAPrimitive.
>> 
>> self >= 0 ifTrue: [^ arg bitAnd: self].
>> ^ (self bitInvert bitOr: arg bitInvert) bitInvert.
>> 0 bitAnd: 0 -> 0
>> 1 bitAnd: 0 -> 0
>> 2 bitAnd: 0 -> 0
>> 3 bitAnd: 0 -> 0
>> 0 bitAnd: 1 -> 0
>> 1 bitAnd: 1 -> 1
>> 2 bitAnd: 1 -> 0
>> 3 bitAnd: 1 -> 1
>>
>> bitOr: arg
>> Primitive. Answer an Integer whose bits are the logical OR of the
>> receiver's bits and those of the argument, arg.
>> Numbers are interpreted as having 2's-complement representation.
>> Essential.  See Object documentation whatIsAPrimitive.
>> 
>> self >= 0 ifTrue: [^ arg bitOr: self].
>> ^ arg < 0
>> ifTrue: [(self bitInvert bitAnd: arg bitInvert) bitInvert]
>> ifFalse: [(self bitInvert bitClear: arg) bitInvert]
>> 0 bitOr: 0 -> 0
>> 1 bitOr: 0 -> 1
>> 2 bitOr: 0 -> 2
>> 3 bitOr: 0 -> 3
>> 0 bitOr: 1 -> 1
>> 1 bitOr: 1 -> 1
>> 2 bitOr: 1 -> 3
>> 3 bitOr: 1 -> 3
>>
>> bitXor: arg
>> Primitive. Answer an Integer whose bits are the logical XOR of the
>> receiver's bits and those of the argument, arg.
>> Numbers are interpreted as having 2's-complement representation.
>> Essential.  See Object documentation whatIsAPrimitive.
>> 
>> self >= 0 ifTrue: [^ arg bitXor: self].
>> ^ arg < 0
>> ifTrue: [self bitInvert bitXor: arg bitInvert]
>> ifFalse: [(self bitInvert bitXor: arg) bitInvert].
>> 0 bitXor: 0 -> 0
>> 1 bitXor: 0 -> 1
>> 2 bitXor: 0 -> 2
>> 3 bitXor: 0 -> 3
>> 0 bitXor: 1 -> 1
>> 1 bitXor: 1 -> 0
>> 2 bitXor: 1 -> 3
>> 3 bitXor: 1 -> 2
>>
>> Picked it up when I was trying to explain the simplicity of the even method
>> on smallInteger.
>>
>> Methods work just fine, but the description is wrong
>>
>> regards
>> Koos brandt
>>

Re: [Pharo-users] bitAnd: Documentation

[Stephane Ducasse]

Thanks Koos. This description is indeed wrong.


On Tue, Jul 18, 2017 at 8:47 PM, Koos Brandt  wrote:
> Hi
>
>  I am new to this environment
>
> I am on Pharo 6.0 - 64 Mac OSX version, Downloaded over the weekend.
>
> Just did some learning and found that the description for bitAnd: is
> probably wrong.
>
> It reads exactly the same as bitOr:
>
> here are some tests as performed in the workspace
> Also included bitXor: for the fun of it
>
> bitAnd: arg
> Primitive. Answer an Integer whose bits are the logical OR of the
> receiver's bits and those of the argument, arg.
> Numbers are interpreted as having 2's-complement representation.
> Essential.  See Object documentation whatIsAPrimitive.
> 
> self >= 0 ifTrue: [^ arg bitAnd: self].
> ^ (self bitInvert bitOr: arg bitInvert) bitInvert.
> 0 bitAnd: 0 -> 0
> 1 bitAnd: 0 -> 0
> 2 bitAnd: 0 -> 0
> 3 bitAnd: 0 -> 0
> 0 bitAnd: 1 -> 0
> 1 bitAnd: 1 -> 1
> 2 bitAnd: 1 -> 0
> 3 bitAnd: 1 -> 1
>
> bitOr: arg
> Primitive. Answer an Integer whose bits are the logical OR of the
> receiver's bits and those of the argument, arg.
> Numbers are interpreted as having 2's-complement representation.
> Essential.  See Object documentation whatIsAPrimitive.
> 
> self >= 0 ifTrue: [^ arg bitOr: self].
> ^ arg < 0
> ifTrue: [(self bitInvert bitAnd: arg bitInvert) bitInvert]
> ifFalse: [(self bitInvert bitClear: arg) bitInvert]
> 0 bitOr: 0 -> 0
> 1 bitOr: 0 -> 1
> 2 bitOr: 0 -> 2
> 3 bitOr: 0 -> 3
> 0 bitOr: 1 -> 1
> 1 bitOr: 1 -> 1
> 2 bitOr: 1 -> 3
> 3 bitOr: 1 -> 3
>
> bitXor: arg
> Primitive. Answer an Integer whose bits are the logical XOR of the
> receiver's bits and those of the argument, arg.
> Numbers are interpreted as having 2's-complement representation.
> Essential.  See Object documentation whatIsAPrimitive.
> 
> self >= 0 ifTrue: [^ arg bitXor: self].
> ^ arg < 0
> ifTrue: [self bitInvert bitXor: arg bitInvert]
> ifFalse: [(self bitInvert bitXor: arg) bitInvert].
> 0 bitXor: 0 -> 0
> 1 bitXor: 0 -> 1
> 2 bitXor: 0 -> 2
> 3 bitXor: 0 -> 3
> 0 bitXor: 1 -> 1
> 1 bitXor: 1 -> 0
> 2 bitXor: 1 -> 3
> 3 bitXor: 1 -> 2
>
> Picked it up when I was trying to explain the simplicity of the even method
> on smallInteger.
>
> Methods work just fine, but the description is wrong
>
> regards
> Koos brandt
>

[Pharo-users] could not find module vm-display-X11

[Hilaire]

Hi,

On Ubuntu 16.04 (Ubuntu MAte), I ahve the following error with DR. Geo 
(release based on Pharo3). Of course the needed 32bits libs are 
installed. Could it be the new graphic back end of Ubuntu?



hilaire@PCHome:~/DrGeo.app$ ./DrGeo.sh could not find module 
vm-display-X11 Abandon (core dumped)


Hilaire

Re: [Pharo-users] Mysterious problem in loading Pharo

[Herby Vojčík]

Herby Vojčík wrote:

It is a real problem (I was getting it in 100% of the cases, restart
did not help, restore of system disk image from last (this monday, so


s/from last/from last backup/


including the recent update) helped.

What I wanted to point to, is, at stack overflow they mentioned this
error happens when dlls depend on each other, are loaded via
LoadLibrary and access their memory before they are actually loaded
(something like that).

Maybe it would be beneficial to look at how dlls (especially in
combination with FT2Plugin.dll) are loaded, and somehow force some
order there.

Herby

Re: [Pharo-users] [Pharo-dev] [Ann] Keccak hashing algorithm

[Santiago Bragagnolo]

Hahahaha, Thanks for the feedback. Sven, I am quite new in this domain.
I'll study your questions and come with solutions tomorrow :). Thanks, i
really need this interaction.

On Tue, 18 Jul 2017 at 20:28 Sven Van Caekenberghe  wrote:

> Great work. I love libraries like these.
>
> I am a bit confused though, in your #updateString: you seem to be
> implementing UTF-8 encoding, something we already have. Normally, hashing
> algorithms are defined on bytes and result in bytes (yours returns a plain
> Array, which is also strange).
>
> It seems
>
> (Keccak hashMessage: 'foo bar') = (Keccak hashMessage: 'foo bar'
> asByteArray).
>
> is true, but
>
> (Keccak hashMessage: 'Les élèves Françaises') = (Keccak hashMessage: 'Les
> élèves Françaises' utf8Encoded).
>
> is false. How come ?
>
> Is this UTF-8 encoding really part of the algorithm ?
>
> Do your tests cover it ?
>
> Another question, how would you compute the invariants given here ?
>
> https://en.wikipedia.org/wiki/SHA-3#Examples_of_SHA-3_variants
>
> SHAKE128("The quick brown fox jumps over the lazy dog", 256)
>
> f4202e3c5852f9182a0430fd8144f0a74b95e7417ecae17db0f8cfeed0e3e66e
>
> SHAKE128("The quick brown fox jumps over the lazy dof", 256)
>
> 853f4538be0db9621a6cea659a06c1107b1f83f02b13d18297bd39d7411cf10c
>
> > On 18 Jul 2017, at 18:32, Santiago Bragagnolo <
> santiagobragagn...@gmail.com> wrote:
> >
> > Hi there!
> >
> > I am just releasing the first version of the Keccak-256 hashing
> algorithm. https://en.wikipedia.org/wiki/SHA-3
> >
> > You can find it at: https://github.com/sbragagnolo/Keccak
> >
> > This  version is based on a javascript implementation:
> https://github.com/emn178/js-sha3
> >
> > This implementation supports  as message: bytearray and ascii and utf-8
> strings.
> >
> >
> > Soon i will be adding support to the rest of the Keccak family of
> hashing functions, since the implementations is quite configurable, is just
> need to add some constructors with specific configurations and tests for
> this other cases of usage.
> >
> >
> > Here a onliner for building an image with the version v0.1:
> >
> >  wget -O-
> https://raw.githubusercontent.com/sbragagnolo/Keccak/v0.1/build.sh | bash
> >
> > Hope you find it useful :)
> >
> >
> > Santiago
> >
> >
>
>
>

[Pharo-users] bitAnd: Documentation

[Koos Brandt]

Hi

 I am new to this environment

I am on Pharo 6.0 - 64 Mac OSX version, Downloaded over the weekend.

Just did some learning and found that the description for bitAnd: is probably 
wrong.

It reads exactly the same as bitOr:

here are some tests as performed in the workspace
Also included bitXor: for the fun of it

bitAnd: arg
Primitive. Answer an Integer whose bits are the logical OR of the
receiver's bits and those of the argument, arg.
Numbers are interpreted as having 2's-complement representation.
Essential.  See Object documentation whatIsAPrimitive.

self >= 0 ifTrue: [^ arg bitAnd: self].
^ (self bitInvert bitOr: arg bitInvert) bitInvert.

0 bitAnd: 0 -> 0
1 bitAnd: 0 -> 0
2 bitAnd: 0 -> 0
3 bitAnd: 0 -> 0
0 bitAnd: 1 -> 0
1 bitAnd: 1 -> 1
2 bitAnd: 1 -> 0
3 bitAnd: 1 -> 1

bitOr: arg
Primitive. Answer an Integer whose bits are the logical OR of the
receiver's bits and those of the argument, arg.
Numbers are interpreted as having 2's-complement representation.
Essential.  See Object documentation whatIsAPrimitive.

self >= 0 ifTrue: [^ arg bitOr: self].
^ arg < 0
ifTrue: [(self bitInvert bitAnd: arg bitInvert) bitInvert]
ifFalse: [(self bitInvert bitClear: arg) bitInvert]
0 bitOr: 0 -> 0 
1 bitOr: 0 -> 1 
2 bitOr: 0 -> 2 
3 bitOr: 0 -> 3 
0 bitOr: 1 -> 1 
1 bitOr: 1 -> 1 
2 bitOr: 1 -> 3 
3 bitOr: 1 -> 3 

bitXor: arg
Primitive. Answer an Integer whose bits are the logical XOR of the
receiver's bits and those of the argument, arg.
Numbers are interpreted as having 2's-complement representation.
Essential.  See Object documentation whatIsAPrimitive.

self >= 0 ifTrue: [^ arg bitXor: self].
^ arg < 0
ifTrue: [self bitInvert bitXor: arg bitInvert]
ifFalse: [(self bitInvert bitXor: arg) bitInvert].

0 bitXor: 0 -> 0 
1 bitXor: 0 -> 1 
2 bitXor: 0 -> 2 
3 bitXor: 0 -> 3 
0 bitXor: 1 -> 1 
1 bitXor: 1 -> 0 
2 bitXor: 1 -> 3 
3 bitXor: 1 -> 2 

Picked it up when I was trying to explain the simplicity of the even method on 
smallInteger.

Methods work just fine, but the description is wrong

regards
Koos brandt

Re: [Pharo-users] [Pharo-dev] [Ann] Keccak hashing algorithm

[Sven Van Caekenberghe]

Great work. I love libraries like these.

I am a bit confused though, in your #updateString: you seem to be implementing 
UTF-8 encoding, something we already have. Normally, hashing algorithms are 
defined on bytes and result in bytes (yours returns a plain Array, which is 
also strange).

It seems

(Keccak hashMessage: 'foo bar') = (Keccak hashMessage: 'foo bar' asByteArray).

is true, but

(Keccak hashMessage: 'Les élèves Françaises') = (Keccak hashMessage: 'Les 
élèves Françaises' utf8Encoded).

is false. How come ?

Is this UTF-8 encoding really part of the algorithm ? 

Do your tests cover it ?

Another question, how would you compute the invariants given here ? 

https://en.wikipedia.org/wiki/SHA-3#Examples_of_SHA-3_variants

SHAKE128("The quick brown fox jumps over the lazy dog", 256)

f4202e3c5852f9182a0430fd8144f0a74b95e7417ecae17db0f8cfeed0e3e66e

SHAKE128("The quick brown fox jumps over the lazy dof", 256)

853f4538be0db9621a6cea659a06c1107b1f83f02b13d18297bd39d7411cf10c

> On 18 Jul 2017, at 18:32, Santiago Bragagnolo  
> wrote:
> 
> Hi there! 
> 
> I am just releasing the first version of the Keccak-256 hashing algorithm. 
> https://en.wikipedia.org/wiki/SHA-3
> 
> You can find it at: https://github.com/sbragagnolo/Keccak
>  
> This  version is based on a javascript implementation: 
> https://github.com/emn178/js-sha3
> 
> This implementation supports  as message: bytearray and ascii and utf-8 
> strings.
> 
> 
> Soon i will be adding support to the rest of the Keccak family of hashing 
> functions, since the implementations is quite configurable, is just need to 
> add some constructors with specific configurations and tests for this other 
> cases of usage.
> 
> 
> Here a onliner for building an image with the version v0.1:
> 
>  wget -O- https://raw.githubusercontent.com/sbragagnolo/Keccak/v0.1/build.sh 
> | bash
> 
> Hope you find it useful :) 
> 
> 
> Santiago 
> 
> 

[Pharo-users] [Ann] Keccak hashing algorithm

[Santiago Bragagnolo]

Hi there!

I am just releasing the first version of the Keccak-256 hashing algorithm.
https://en.wikipedia.org/wiki/SHA-3

You can find it at: https://github.com/sbragagnolo/Keccak

This  version is based on a javascript implementation:
https://github.com/emn178/js-sha3

This implementation supports  as message: bytearray and ascii and utf-8
strings.


Soon i will be adding support to the rest of the Keccak family of hashing
functions, since the implementations is quite configurable, is just need to
add some constructors with specific configurations and tests for this other
cases of usage.


Here a onliner for building an image with the version v0.1:

 wget -O- https://raw.githubusercontent.com/sbragagnolo/Keccak/v0.1/build.sh
| bash

Hope you find it useful :)


Santiago

Re: [Pharo-users] Mysterious problem in loading Pharo

[Herby Vojčík]

It is a real problem (I was getting it in 100% of the cases, restart did not
help, restore of system disk image from last (this monday, so including the
recent update) helped.

What I wanted to point to, is, at stack overflow they mentioned this error
happens when dlls depend on each other, are loaded via LoadLibrary and
access their memory before they are actually loaded (something like that).

Maybe it would be beneficial to look at how dlls (especially in combination
with FT2Plugin.dll) are loaded, and somehow force some order there.

Herby




--
View this message in context: 
http://forum.world.st/Mysterious-problem-in-loading-Pharo-tp4954998p4955544.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Encoding and conversion problem

[Cyril Ferlicot]

On Tue, Jul 18, 2017 at 4:27 PM, Sven Van Caekenberghe  wrote:
>
> In general, the stream API is much, much too wide, IMHO. Not all streams 
> (hence the word stream) can see all their content all the time (think of 
> network or encrypted streams, most work with a sliding buffer, but in general 
> the idea of a stream is to *not* hold everything in memory at the same time). 
> If you look at it that way, many operations stop making sense. Positioning is 
> one of them. Even in Java not every stream is positionable, and even if they 
> are positionable, the positioning can fail because you go too far (back).
>
> In all parsing code that I write I try to only use 1 item look ahead (a 
> single item buffer), which means you can #peek 1 item, that's it.
>
> I know that we have parsing code that was written with other assumptions. 
> Such code is not stream based, IMHO.
>
> The solution (or rather workaround) is easy: read everything #upToEnd and 
> turn it into a good old ReadStream again. You will give the use infinite 
> positioning over all of the content, at the cost of more memory usage.


When I'll have time I'll check if we can avoid the use of #position:,
but in any case we cannot use #upToEnd because we need to stay
optimized.

At the begining we where doing that but it's too long for our algos.
Sometime we just want to read what it between the line 3, column 5 and
the line 6, column 9. If the file has thousands of line we lose to
much time to read everything.


-- 
Cyril Ferlicot
https://ferlicot.fr

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

Re: [Pharo-users] Encoding and conversion problem

[Sven Van Caekenberghe]

> On 18 Jul 2017, at 16:10, Cyril Ferlicot  wrote:
> 
> On Tue, Jul 18, 2017 at 3:54 PM, Sven Van Caekenberghe  wrote:
>> 
>> These are all aliases [ see: https://en.wikipedia.org/wiki/ISO/IEC_8859-1 ].
>> 
>> So you could add it, yes
>> 
>> But why use TextConverter at all ?
>> 
> 
> I used this because this is what I found while browsing for code. When
> I did this code the CI was down I could not access to EnterprisePharo.
> 
>> You could keep on using the alternative (more modern, cleaner) 
>> ZnCharacterEncoder hierarchy.
>> 
>> Just open your streams binary and wrap a ZnCharacterReadStream around them 
>> with the encoding of your choice.
>> 
>> fileReference binaryReadStreamDo: [ :in | (ZnCharacterReadStream on: in 
>> encoding: #latin1) ... ]
>> 
> 
> I just tried to use this but it broke my code. For example,
> ZnCharacterReadStream does not understand #position: while the
> ReadStream hierarchy understand it.

In general, the stream API is much, much too wide, IMHO. Not all streams (hence 
the word stream) can see all their content all the time (think of network or 
encrypted streams, most work with a sliding buffer, but in general the idea of 
a stream is to *not* hold everything in memory at the same time). If you look 
at it that way, many operations stop making sense. Positioning is one of them. 
Even in Java not every stream is positionable, and even if they are 
positionable, the positioning can fail because you go too far (back).

In all parsing code that I write I try to only use 1 item look ahead (a single 
item buffer), which means you can #peek 1 item, that's it.

I know that we have parsing code that was written with other assumptions. Such 
code is not stream based, IMHO.

The solution (or rather workaround) is easy: read everything #upToEnd and turn 
it into a good old ReadStream again. You will give the use infinite positioning 
over all of the content, at the cost of more memory usage.

> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 

Re: [Pharo-users] Encoding and conversion problem

[Cyril Ferlicot]

On Tue, Jul 18, 2017 at 3:54 PM, Sven Van Caekenberghe  wrote:
>
> These are all aliases [ see: https://en.wikipedia.org/wiki/ISO/IEC_8859-1 ].
>
> So you could add it, yes
>
> But why use TextConverter at all ?
>

I used this because this is what I found while browsing for code. When
I did this code the CI was down I could not access to EnterprisePharo.

> You could keep on using the alternative (more modern, cleaner) 
> ZnCharacterEncoder hierarchy.
>
> Just open your streams binary and wrap a ZnCharacterReadStream around them 
> with the encoding of your choice.
>
> fileReference binaryReadStreamDo: [ :in | (ZnCharacterReadStream on: in 
> encoding: #latin1) ... ]
>

I just tried to use this but it broke my code. For example,
ZnCharacterReadStream does not understand #position: while the
ReadStream hierarchy understand it.



-- 
Cyril Ferlicot
https://ferlicot.fr

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

Re: [Pharo-users] Encoding and conversion problem

[Sven Van Caekenberghe]

> On 18 Jul 2017, at 15:42, Cyril Ferlicot  wrote:
> 
> Hi,
> 
> I did a refactoring in Moose in order to use the encoding detector
> that Sven did some weeks ago while reading a file.
> 
> With the latest stable version of ZincHTTPComponent, I can get the
> encoding like this:
> 
> fileReference binaryReadStreamDo: [ :in | (ZnCharacterEncoder
> detectEncoding: in upToEnd) ]
> 
> Since we need to read the files a lot, I save the identifier of the
> encoder using the #identifier method. Then when I read I just want to
> get the TextConverter corresponding to the encoder in order to read
> the stream.
> 
> The problem is that in the case of a file encoded in ISO-8859-1, my
> instance of ZnSimplifiedByteEncoder return 'iso88591' as identifier
> and Latin1TextConverter does not have this encoding name in its
> possibilities. Only 'iso-8859-1'.
> 
> Should we add 'iso88591' to the Latin1TextConverter? If yes, could we
> backport this to Pharo 6 please?

These are all aliases [ see: https://en.wikipedia.org/wiki/ISO/IEC_8859-1 ].

So you could add it, yes

But why use TextConverter at all ? 

You could keep on using the alternative (more modern, cleaner) 
ZnCharacterEncoder hierarchy.

Just open your streams binary and wrap a ZnCharacterReadStream around them with 
the encoding of your choice.

fileReference binaryReadStreamDo: [ :in | (ZnCharacterReadStream on: in 
encoding: #latin1) ... ]

> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 

[Pharo-users] Encoding and conversion problem

[Cyril Ferlicot]

Hi,

I did a refactoring in Moose in order to use the encoding detector
that Sven did some weeks ago while reading a file.

With the latest stable version of ZincHTTPComponent, I can get the
encoding like this:

fileReference binaryReadStreamDo: [ :in | (ZnCharacterEncoder
detectEncoding: in upToEnd) ]

Since we need to read the files a lot, I save the identifier of the
encoder using the #identifier method. Then when I read I just want to
get the TextConverter corresponding to the encoder in order to read
the stream.

The problem is that in the case of a file encoded in ISO-8859-1, my
instance of ZnSimplifiedByteEncoder return 'iso88591' as identifier
and Latin1TextConverter does not have this encoding name in its
possibilities. Only 'iso-8859-1'.

Should we add 'iso88591' to the Latin1TextConverter? If yes, could we
backport this to Pharo 6 please?

-- 
Cyril Ferlicot
https://ferlicot.fr

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

Re: [Pharo-users] get output of a forked process on windows

[Thierry Goubier]

Hi Christophe,

You have to use ProcessWrapper.

Metacello new
  configuration: 'ProcessWrapper';
  repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main';
  load

(as extracted from the baseline of GitFileTree for Pharo4)

Regards,

Thierry


2017-07-18 15:34 GMT+02:00 Christophe Demarey :

> PharoConsole.exe is only available for image versions > 50.
> I need a solution that works on older image versions.
>
> Thanks for the advice,
> Christophe
>
> Le 18 juil. 2017 à 14:26, Guillermo Polito  a
> écrit :
>
> Have you checked the Console version of the windows VM?
>
> On Tue, Jul 18, 2017 at 10:48 AM, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
>
>> Hi,
>>
>> I would like to evaluate a Smalltalk expression in a forked process (i.e.
>> something like OSProcess thisOSProcess waitForCommandOutput: 'pharo
>> Pharo.image eval "SystemVersion current dottedMajorMinor"').
>> It is doable on linux/mac with OSProcess but not on Windows. Is there
>> another way to do that on Windows? I would prefer to avoid to write to a
>> file.
>>
>> Thanks,
>> Christophe
>>
>
>
>
> --
>
> Guille Polito
>
> Research Engineer
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
> *Web:* *http://guillep.github.io* 
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>
>
>

Re: [Pharo-users] get output of a forked process on windows

[Christophe Demarey]

PharoConsole.exe is only available for image versions > 50.
I need a solution that works on older image versions.

Thanks for the advice,
Christophe

> Le 18 juil. 2017 à 14:26, Guillermo Polito  a 
> écrit :
> 
> Have you checked the Console version of the windows VM?
> 
> On Tue, Jul 18, 2017 at 10:48 AM, Christophe Demarey 
> > wrote:
> Hi,
> 
> I would like to evaluate a Smalltalk expression in a forked process (i.e. 
> something like OSProcess thisOSProcess waitForCommandOutput: 'pharo 
> Pharo.image eval "SystemVersion current dottedMajorMinor"').
> It is doable on linux/mac with OSProcess but not on Windows. Is there another 
> way to do that on Windows? I would prefer to avoid to write to a file.
> 
> Thanks,
> Christophe
> 
> 
> 
> -- 
>
> Guille Polito
> 
> Research Engineer
> 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] get output of a forked process on windows

[Guillermo Polito]

Have you checked the Console version of the windows VM?

On Tue, Jul 18, 2017 at 10:48 AM, Christophe Demarey <
christophe.dema...@inria.fr> wrote:

> Hi,
>
> I would like to evaluate a Smalltalk expression in a forked process (i.e.
> something like OSProcess thisOSProcess waitForCommandOutput: 'pharo
> Pharo.image eval "SystemVersion current dottedMajorMinor"').
> It is doable on linux/mac with OSProcess but not on Windows. Is there
> another way to do that on Windows? I would prefer to avoid to write to a
> file.
>
> Thanks,
> Christophe
>



-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




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

*Phone: *+33 06 52 70 66 13

[Pharo-users] get output of a forked process on windows

[Christophe Demarey]

Hi,

I would like to evaluate a Smalltalk expression in a forked process (i.e. 
something like OSProcess thisOSProcess waitForCommandOutput: 'pharo Pharo.image 
eval "SystemVersion current dottedMajorMinor"').
It is doable on linux/mac with OSProcess but not on Windows. Is there another 
way to do that on Windows? I would prefer to avoid to write to a file.

Thanks,
Christophe