Re: [Pharo-dev] Pharo 7 new file stream encoders

[Guillermo Polito]

Hi,

Yes, I'll provide a PR with that functionality soon. Probably in that
case *ZnCrPortableWriteStream*
is not the right name for that class. Sven, do you think renaming it now
(before it has lots of users) would be acceptable towards backwards
compatibility? Otherwise I would name it ZnNewLineConverterStream...

Keep you updated,
Guille

On Thu, Mar 15, 2018 at 3:11 PM, Sven Van Caekenberghe  wrote:

> I think the idea is to use ZnCrPortableWriteStream for that.
>
> > On 15 Mar 2018, at 14:58, Thierry Goubier 
> wrote:
> >
> > Hi all,
> >
> > how does one create a file stream in Pharo 7 that forces a specific
> > line end convention ? For example, for forcing all end of lines to be
> > Character lf.
> >
> > The old way,
> >
> > fileStream lineEndConvention: #'lf'.
> >
> > does not work anymore.
> >
> > Thanks,
> >
> > Thierry
> >
>
>
>


-- 



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-dev] Pharo 7 new file stream encoders

[Sven Van Caekenberghe]

> On 16 Mar 2018, at 11:29, Guillermo Polito  wrote:
> 
> Hi,
> 
> Yes, I'll provide a PR with that functionality soon. Probably in that case 
> *ZnCrPortableWriteStream* is not the right name for that class. Sven, do you 
> think renaming it now (before it has lots of users) would be acceptable 
> towards backwards compatibility? Otherwise I would name it 
> ZnNewLineConverterStream...

Renaming is OK/better, if it works (critical class in IO)

Note #forPlatformLineEnding should do: OSPlatform current lineEnding

> Keep you updated,
> Guille
> 
> On Thu, Mar 15, 2018 at 3:11 PM, Sven Van Caekenberghe  wrote:
> I think the idea is to use ZnCrPortableWriteStream for that.
> 
> > On 15 Mar 2018, at 14:58, Thierry Goubier  wrote:
> >
> > Hi all,
> >
> > how does one create a file stream in Pharo 7 that forces a specific
> > line end convention ? For example, for forcing all end of lines to be
> > Character lf.
> >
> > The old way,
> >
> > fileStream lineEndConvention: #'lf'.
> >
> > does not work anymore.
> >
> > Thanks,
> >
> > Thierry
> >
> 
> 
> 
> 
> 
> -- 
>
> 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-dev] Executive Summary of the recent FileStream Changes

[Sven Van Caekenberghe]

> On 15 Mar 2018, at 23:36, Nicolas Cellier 
>  wrote:
> 
> Very good initiative!
> It's worth a few hick-ups.

Thanks, the really hard work is in the all the using code, writing against 
simpler APIs.

It will be a while before all the dust settles and all performance issues are 
covered, but we are already quite far.

> I've tried to reduce RWBinaryOrTextStream usage in Squeak maybe 10 years ago, 
> but you know it very well, the last places which are resisting are the more 
> intricated and convoluted.
> I call it the SwiisKnifeStream and allways wandered why we would have to 
> carry so many subclasses of Stream, since we have one capable of almost 
> everything!
> Managing the states in such a hierarchy was an art, if ever torture is an 
> art... and we are loosing a great can of worms for fishing the bugs.
> So, R.I.P. and no regret!
> 
> 2018-03-15 21:01 GMT+01:00 Sven Van Caekenberghe :
> Executive Summary of the recent FileStream Changes
> 
> In Pharo 7 Guille Polito recently committed a heroic set of changes that we 
> were planning to do for a long time but were afraid to take on.
> 
> The idea is to replace a couple of fat, overly complex, multi-functional, 
> do-all classes with a set of simpler single purpose classes that can be 
> combined as needed.
> 
> The classes that we want to get rid of can be found in the package 
> DeprecatedFileSystem, in particular FileStream, StandardFileStream, 
> MultiByteFileStream, MultiByteBinaryOrTextStream and RWBinaryOrTextStream.
> 
> The replacements are can be found in packages Files and 
> Zinc-Character-Encoding-Core.
> 
> Encoding and decoding characters to and from bytes is done using classes that 
> you wrap around a more primitive binary stream. The same goes for buffering 
> or translating line endings.
> 
> For example,
> 
>  '/Users/sven/Desktop/foo.txt' asFileReference binaryReadStream.
> 
> gives you a ZnBufferedWriteStream wrapping a BinaryWriteStream.
> 
> While,
> 
>  '/Users/sven/Desktop/foo.txt' asFileReference readStream.
> 
> gives a ZnCharacterReadStream wrapping a ZnBufferedWriteStream wrapping a 
> BinaryWriteStream.
> 
> To translate line endings, we would wrap a ZnCharacterWriteStream using a 
> ZnCrPortableWriteStream.
> 
> There are a couple of more specialised streams to cover special cases (like 
> read and writing at the same time).
> 
> SocketStream remains another fat, overly complex, multi-functional, do-all 
> class, for which usable replacements exist in the form of ZdcSocketStream and 
> ZdcSecureSocketStream, which are simpler, cleaner and binary only.
> 
> Of course, switching is more than replacing one class with a 100% compatible 
> alternative, that would give us the same complex result. The challenge is to 
> use a simpler API as well, to rethink how the streams are used. You know, 
> KISS.
> 
> Of course, we are far from done and need more testing, debugging and help 
> from as many people as possible.
> 
> Sven
> 
> 
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
> 
> 
> 
> 
> 
> 

Re: [Pharo-dev] Executive Summary of the recent FileStream Changes

[Sven Van Caekenberghe]

> On 16 Mar 2018, at 07:05, monty  wrote:
> 
>> Sent: Thursday, March 15, 2018 at 4:01 PM
>> From: "Sven Van Caekenberghe" 
>> To: "Pharo Development List" 
>> Subject: [Pharo-dev] Executive Summary of the recent FileStream Changes
>> 
>> Executive Summary of the recent FileStream Changes
>> 
>> In Pharo 7 Guille Polito recently committed a heroic set of changes that we 
>> were planning to do for a long time but were afraid to take on.
>> 
>> The idea is to replace a couple of fat, overly complex, multi-functional, 
>> do-all classes with a set of simpler single purpose classes that can be 
>> combined as needed.
>> 
>> The classes that we want to get rid of can be found in the package 
>> DeprecatedFileSystem, in particular FileStream, StandardFileStream, 
>> MultiByteFileStream, MultiByteBinaryOrTextStream and RWBinaryOrTextStream.
> 
> StandardFileStream, at least, should remain for backwards compatibility and 
> cross-platform compatibility with Squeak. It's a no-frills, non-decoding, 
> non-LE normalizing stream that is heavily depended on.

Hmm, maybe.

The standard (no pun intended) interface to the file system in Pharo has been 
FileSystem (FileReference) for quite a while. Many packages dealing with either 
different Pharo versions or different Smalltalk implementations have 
constructed their own portability facade (heck, I even did it in 
ZnFileSystemUtils myself).

Note however that some aspects (API, behaviour) about the streams themselves 
changed as well (no longer being bivalent, separating reading/writing, 
smaller/simpler API, sometimes no positioning).

>> The replacements are can be found in packages Files and 
>> Zinc-Character-Encoding-Core.
>> 
>> Encoding and decoding characters to and from bytes is done using classes 
>> that you wrap around a more primitive binary stream. The same goes for 
>> buffering or translating line endings.
>> 
>> For example,
>> 
>> '/Users/sven/Desktop/foo.txt' asFileReference binaryReadStream.
>> 
>> gives you a ZnBufferedWriteStream wrapping a BinaryWriteStream.
>> 
>> While,
>> 
>> '/Users/sven/Desktop/foo.txt' asFileReference readStream.
> 
> What do you think about this algorithm for encoding detection: 
> http://www.yaml.org/spec/1.2/spec.html#id2771184
> 
> I have an implementation (with tests), if you're interested. (I was waiting 
> to propose it until the FileSystem API switched over to using Zn streams and 
> encoders. The TextConverter API doesn't support UTF-32.)

I did a primitive one in ZnCharacterEncoding class>>#detectEncoding: but I am 
not happy with it. I will read your reference and I am certainly interested in 
seeing your code !

>> gives a ZnCharacterReadStream wrapping a ZnBufferedWriteStream wrapping a 
>> BinaryWriteStream.
>> 
>> To translate line endings, we would wrap a ZnCharacterWriteStream using a 
>> ZnCrPortableWriteStream.
>> 
>> There are a couple of more specialised streams to cover special cases (like 
>> read and writing at the same time).
>> 
>> SocketStream remains another fat, overly complex, multi-functional, do-all 
>> class, for which usable replacements exist in the form of ZdcSocketStream 
>> and ZdcSecureSocketStream, which are simpler, cleaner and binary only.
>> 
>> Of course, switching is more than replacing one class with a 100% compatible 
>> alternative, that would give us the same complex result. The challenge is to 
>> use a simpler API as well, to rethink how the streams are used. You know, 
>> KISS.
>> 
>> Of course, we are far from done and need more testing, debugging and help 
>> from as many people as possible.
>> 
>> Sven
>> 
>> 
>> --
>> Sven Van Caekenberghe
>> Proudly supporting Pharo
>> http://pharo.org
>> http://association.pharo.org
>> http://consortium.pharo.org

Re: [Pharo-dev] Pharo 7 new file stream encoders

[Guillermo Polito]

Thierry, Sven,

Can you review https://github.com/pharo-project/pharo/pull/1116 ?

Tx,
Guille

On Fri, Mar 16, 2018 at 11:29 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Hi,
>
> Yes, I'll provide a PR with that functionality soon. Probably in that case
> *ZnCrPortableWriteStream* is not the right name for that class. Sven, do
> you think renaming it now (before it has lots of users) would be acceptable
> towards backwards compatibility? Otherwise I would name it
> ZnNewLineConverterStream...
>
> Keep you updated,
> Guille
>
> On Thu, Mar 15, 2018 at 3:11 PM, Sven Van Caekenberghe 
> wrote:
>
>> I think the idea is to use ZnCrPortableWriteStream for that.
>>
>> > On 15 Mar 2018, at 14:58, Thierry Goubier 
>> wrote:
>> >
>> > Hi all,
>> >
>> > how does one create a file stream in Pharo 7 that forces a specific
>> > line end convention ? For example, for forcing all end of lines to be
>> > Character lf.
>> >
>> > The old way,
>> >
>> > fileStream lineEndConvention: #'lf'.
>> >
>> > does not work anymore.
>> >
>> > Thanks,
>> >
>> > Thierry
>> >
>>
>>
>>
>
>
> --
>
>
>
> 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 <+33%206%2052%2070%2066%2013>
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

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


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

*Phone: *+33 06 52 70 66 13

[Pharo-dev] Windows PharoLauncher cannot create "C:\Program Files (x86)\Pharo\Pharo.image"

[Ben Coman]

I popped over to Windows for a moment to try to make my CloudflareUn
crossplatform,
and installed PharoLauncher from the downloads page...
http://files.pharo.org/pharo-launcher/1.1/pharo-launcher-installer-1.1-x86.exe

I logged in as an Admin to do this, but when I open it I get an error...
   "PrimitiveFailed: primitive #createDirectory: in WindowsStore failed"

where...
path ==> "Path / 'C:' / 'Program Files (x86)' / 'Pharo' / 'pharo-local'"
encodedPath ==> C:\Program Files (x86)\Pharo\pharo-local
(self isDirectory: parent)  ==> true

in...
WindowsStore(DiskStore) >> createDirectory: path
| parent encodedPathString pathString result |
pathString := self stringFromPath: path.
encodedPathString := Primitives encode: pathString.
result := Primitives createDirectory: encodedPathString.
result
ifNil: [
parent := path parent.
(self exists: path)
ifTrue: [
(self isFile: path)
ifTrue: [ self signalFileExists: path ]
ifFalse: [ self signalDirectoryExists: path ] ].
(self isDirectory: parent)
ifFalse: [ ^ self signalDirectoryDoesNotExist: parent ].
self primitiveFailed ].
^ self

A few calls down the stack is  OmSessioNStore>>resetWithStoreNamed:

Does this happen for anyone else?

Version Info...

OS
-
Windows 10

Image
-
C:\Program Files (x86)\Pharo\Pharo.image
Pharo6.0
Latest update: #60528
Unnamed

Virtual Machine
---
C:\Program Files (x86)\Pharo\Pharo.exe
CoInterpreter VMMaker.oscog-eem.2254 uuid:
4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:
2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017
VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $

Win32 built on Jul 20 2017 20:21:26 GMT Compiler: 5.4.0
VMMaker versionString VM: 201707201942
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20
12:42:21 2017 -0700 $ Plugins: 201707201942
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
CoInterpreter VMMaker.oscog-eem.2254 uuid:
4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:
2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017


Also, I would expect trouble for Non-Admin users trying to use the Admin
installed Pharo Launcher.trying to write to "pharo-local" under "Program
Files".Does PharoLauncher have its own CI testing to ensure it can open
okay and run an image?   I'm glad to see it promoted in importance but with
this it probably needs such CI testing of its own separate to the usual
Pharo CI testing.  On Windows such CI testing *should* run as a Non-Admin
user.

btw, requiring Administrative privileges to install PharoLauncher is going
to lock out people who don't have administrative control over their PCs
e.g. University student labs. Wanting to run a quick demo for someone in a
corporate office.  Why don't we make it the same as OSX and Linux and be
usable without Admin privileges.   That would lower a barrier to entry.

cheers -ben

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Stephane Ducasse]

I do not see why this is a problem to have the launcher and Pharo.
The launcher is an App and Pharo another.
Yesterday the launcher crashed on Windows when I tried to pair program
with someone so we downloaded
the default Pharo version.
Why do we want to make things complex.

You want Pharo
- donwload it

You want to manage your pharo devs and access jenkins and other services
- use the launcher.

Stef

On Thu, Mar 15, 2018 at 3:38 PM, Marcus Denker  wrote:
> -> better structure
> -> simplified the large print (no need to talk about downloading zip files)
>
> TODO:
> - add back a section about downloading images.
>
>> On 14 Mar 2018, at 18:18, Marcus Denker  wrote:
>>
>> Ok, I will fix that in the next pass.
>>
>>> On 9 Mar 2018, at 18:10, Sean P. DeNigris  wrote:
>>>
>>> Marcus Denker-4 wrote
 comments welcome…
>>>
>>> IHMO the structure is a little confusing because the first heading "Usage"
>>> (Launcher implied) is on the same level as other methods like "Linux
>>> Packages". I think there needs to be something like a header one level
>>> higher like "Other Options" between these two sections.
>>>
>>>
>>>
>>> -
>>> Cheers,
>>> Sean
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>>
>>
>
>

Re: [Pharo-dev] FileHandle creates a buffered stream on a buffered stream

[Guillermo Polito]

Nice catch. The write stream is well defined in comparison.

https://pharo.fogbugz.com/f/cases/21604/FileHandle-creates-a-buffered-stream-on-a-buffered-stream

https://github.com/pharo-project/pharo/pull/1118

Can somebody review please?

Tx,
Guille

On Thu, Mar 15, 2018 at 4:00 PM, Sven Van Caekenberghe  wrote:

> Hi (Guille),
>
> FileHandle creates a buffered stream on a buffered stream when sent
> #readStream.
>
> Note how #binaryReadStream adds a bufferer stream as well as
> #readStreamEncoded:
>
> Probably the latter should not do this
>
> Sven
>



-- 



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-dev] FileHandle creates a buffered stream on a buffered stream

[Sven Van Caekenberghe]

> On 16 Mar 2018, at 11:46, Guillermo Polito  wrote:
> 
> Nice catch. The write stream is well defined in comparison.
> 
> https://pharo.fogbugz.com/f/cases/21604/FileHandle-creates-a-buffered-stream-on-a-buffered-stream
> 
> https://github.com/pharo-project/pharo/pull/1118
> 
> Can somebody review please?

OK by me

> Tx,
> Guille
> 
> On Thu, Mar 15, 2018 at 4:00 PM, Sven Van Caekenberghe  wrote:
> Hi (Guille),
> 
> FileHandle creates a buffered stream on a buffered stream when sent 
> #readStream.
> 
> Note how #binaryReadStream adds a bufferer stream as well as 
> #readStreamEncoded:
> 
> Probably the latter should not do this
> 
> Sven
> 
> 
> 
> -- 
>
> 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-dev] Experiment: New Download page based on Pharo Launcher

[Christophe Demarey]

> Le 15 mars 2018 à 09:27, Esteban Lorenzano  a écrit :
> 
> - OBS for the launcher (to have linux packaging)

yes, would be nice

> - signing the launcher on mac (we already did this for the VM, we can do the 
> same for launcher).

you sign the executable, so it mean signe the VM with another certificate => 
rebuild the VM

> And distribute it as dmg, not zip (a dmg is just a zip renamed so no problem 
> here).

It is already a dmg. Did you try it? ;)

> - a windows installer

Here also, it is already like that.
You forgot to mention: sign Windows app so that Windows Defender does not warn 
you that it is a malicious software and you should not install it

Christophe

Re: [Pharo-dev] Executive Summary of the recent FileStream Changes

[Stephane Ducasse]

+ 1
Ah what a relief. Thanks a lot guille for all this good energy.
BTW I also like the pattern. We should apply the same to OPAL. Do not
mix API and add a wrapper for the backward compatible so that the new
API is untouched.
I really like that way.

Now we should replace cr by newline :)

Stef

On Thu, Mar 15, 2018 at 11:36 PM, Nicolas Cellier
 wrote:
> Very good initiative!
> It's worth a few hick-ups.
>
> I've tried to reduce RWBinaryOrTextStream usage in Squeak maybe 10 years
> ago, but you know it very well, the last places which are resisting are the
> more intricated and convoluted.
> I call it the SwiisKnifeStream and allways wandered why we would have to
> carry so many subclasses of Stream, since we have one capable of almost
> everything!
> Managing the states in such a hierarchy was an art, if ever torture is an
> art... and we are loosing a great can of worms for fishing the bugs.
> So, R.I.P. and no regret!
>
> 2018-03-15 21:01 GMT+01:00 Sven Van Caekenberghe :
>>
>> Executive Summary of the recent FileStream Changes
>>
>> In Pharo 7 Guille Polito recently committed a heroic set of changes that
>> we were planning to do for a long time but were afraid to take on.
>>
>> The idea is to replace a couple of fat, overly complex, multi-functional,
>> do-all classes with a set of simpler single purpose classes that can be
>> combined as needed.
>>
>> The classes that we want to get rid of can be found in the package
>> DeprecatedFileSystem, in particular FileStream, StandardFileStream,
>> MultiByteFileStream, MultiByteBinaryOrTextStream and RWBinaryOrTextStream.
>>
>> The replacements are can be found in packages Files and
>> Zinc-Character-Encoding-Core.
>>
>> Encoding and decoding characters to and from bytes is done using classes
>> that you wrap around a more primitive binary stream. The same goes for
>> buffering or translating line endings.
>>
>> For example,
>>
>>  '/Users/sven/Desktop/foo.txt' asFileReference binaryReadStream.
>>
>> gives you a ZnBufferedWriteStream wrapping a BinaryWriteStream.
>>
>> While,
>>
>>  '/Users/sven/Desktop/foo.txt' asFileReference readStream.
>>
>> gives a ZnCharacterReadStream wrapping a ZnBufferedWriteStream wrapping a
>> BinaryWriteStream.
>>
>> To translate line endings, we would wrap a ZnCharacterWriteStream using a
>> ZnCrPortableWriteStream.
>>
>> There are a couple of more specialised streams to cover special cases
>> (like read and writing at the same time).
>>
>> SocketStream remains another fat, overly complex, multi-functional, do-all
>> class, for which usable replacements exist in the form of ZdcSocketStream
>> and ZdcSecureSocketStream, which are simpler, cleaner and binary only.
>>
>> Of course, switching is more than replacing one class with a 100%
>> compatible alternative, that would give us the same complex result. The
>> challenge is to use a simpler API as well, to rethink how the streams are
>> used. You know, KISS.
>>
>> Of course, we are far from done and need more testing, debugging and help
>> from as many people as possible.
>>
>> Sven
>>
>>
>> --
>> Sven Van Caekenberghe
>> Proudly supporting Pharo
>> http://pharo.org
>> http://association.pharo.org
>> http://consortium.pharo.org
>>
>>
>>
>>
>>
>

Re: [Pharo-dev] Executive Summary of the recent FileStream Changes

[Stephane Ducasse]

Hi Monty

We will keep the old stuff around in a kind of deprecated packages.
Now in the long term we do not intend to maintain them forever
because we will collapse under the load. You see it was either that
clean up or modules so at the end ***Pharo*** should move on
because this is our future.

In this vein, we are planning to migrate a selection of the old
deprecated methods (of Pharo 30, 40, 50, 60) into a MigrationPackage
with deprecatedWithTransform rule
to help the migration of the old code to new one.
Now of course nobody really stood up to give a hand. Normal this is
easier to give us order :)

Stef


On Fri, Mar 16, 2018 at 7:05 AM, monty  wrote:
>
>
>> Sent: Thursday, March 15, 2018 at 4:01 PM
>> From: "Sven Van Caekenberghe" 
>> To: "Pharo Development List" 
>> Subject: [Pharo-dev] Executive Summary of the recent FileStream Changes
>>
>> Executive Summary of the recent FileStream Changes
>>
>> In Pharo 7 Guille Polito recently committed a heroic set of changes that we 
>> were planning to do for a long time but were afraid to take on.
>>
>> The idea is to replace a couple of fat, overly complex, multi-functional, 
>> do-all classes with a set of simpler single purpose classes that can be 
>> combined as needed.
>>
>> The classes that we want to get rid of can be found in the package 
>> DeprecatedFileSystem, in particular FileStream, StandardFileStream, 
>> MultiByteFileStream, MultiByteBinaryOrTextStream and RWBinaryOrTextStream.
>
> StandardFileStream, at least, should remain for backwards compatibility and 
> cross-platform compatibility with Squeak. It's a no-frills, non-decoding, 
> non-LE normalizing stream that is heavily depended on.
>
>> The replacements are can be found in packages Files and 
>> Zinc-Character-Encoding-Core.
>>
>> Encoding and decoding characters to and from bytes is done using classes 
>> that you wrap around a more primitive binary stream. The same goes for 
>> buffering or translating line endings.
>>
>> For example,
>>
>>  '/Users/sven/Desktop/foo.txt' asFileReference binaryReadStream.
>>
>> gives you a ZnBufferedWriteStream wrapping a BinaryWriteStream.
>>
>> While,
>>
>>  '/Users/sven/Desktop/foo.txt' asFileReference readStream.
>
> What do you think about this algorithm for encoding detection: 
> http://www.yaml.org/spec/1.2/spec.html#id2771184
>
> I have an implementation (with tests), if you're interested. (I was waiting 
> to propose it until the FileSystem API switched over to using Zn streams and 
> encoders. The TextConverter API doesn't support UTF-32.)
>
>> gives a ZnCharacterReadStream wrapping a ZnBufferedWriteStream wrapping a 
>> BinaryWriteStream.
>>
>> To translate line endings, we would wrap a ZnCharacterWriteStream using a 
>> ZnCrPortableWriteStream.
>>
>> There are a couple of more specialised streams to cover special cases (like 
>> read and writing at the same time).
>>
>> SocketStream remains another fat, overly complex, multi-functional, do-all 
>> class, for which usable replacements exist in the form of ZdcSocketStream 
>> and ZdcSecureSocketStream, which are simpler, cleaner and binary only.
>>
>> Of course, switching is more than replacing one class with a 100% compatible 
>> alternative, that would give us the same complex result. The challenge is to 
>> use a simpler API as well, to rethink how the streams are used. You know, 
>> KISS.
>>
>> Of course, we are far from done and need more testing, debugging and help 
>> from as many people as possible.
>>
>> Sven
>>
>>
>> --
>> Sven Van Caekenberghe
>> Proudly supporting Pharo
>> http://pharo.org
>> http://association.pharo.org
>> http://consortium.pharo.org
>>
>>
>>
>>
>>
>>
>

Re: [Pharo-dev] Windows PharoLauncher cannot create "C:\Program Files (x86)\Pharo\Pharo.image"

[Christophe Demarey]

Hi Ben,

> Le 16 mars 2018 à 13:22, Ben Coman  a écrit :
> 
> I popped over to Windows for a moment to try to make my CloudflareUn 
> crossplatform,
> and installed PharoLauncher from the downloads page...
> http://files.pharo.org/pharo-launcher/1.1/pharo-launcher-installer-1.1-x86.exe
>  
> 
> 
> I logged in as an Admin to do this, but when I open it I get an error...
>"PrimitiveFailed: primitive #createDirectory: in WindowsStore failed »

Did you try to right-click on the installer and select « Run as administrator « 
? I’m not sure that apps are all run with admin privileges even if you are 
logged in with an admin account.

> Also, I would expect trouble for Non-Admin users trying to use the Admin 
> installed Pharo Launcher.trying to write to "pharo-local" under "Program 
> Files ». 

Yes, that for sure!
For now, if you are admin, you could install PharoLauncher under « Program 
Files » but then, you also need to be admin to run it. If you are not admin, 
you should install PharoLauncher elsewhere.

I did not yet had time to test what Vincent on app packaging but probably, it 
will solve the issue as Pharo Launcher does not need to write anything to the 
installation directory (was needed by tools like GT, epicea, stdout).

>   Does PharoLauncher have its own CI testing to ensure it can open okay and 
> run an image?   I'm glad to see it promoted in importance but with this it 
> probably needs such CI testing of its own separate to the usual Pharo CI 
> testing.  On Windows such CI testing *should* run as a Non-Admin user.

Functional testing like this is done by hand for this part. There are unit 
tests. you can check that on CI: 
https://ci.inria.fr/pharo-ci-jenkins2/job/PharoLauncher/
There is room for improvement here. If you have an idea on how to automate 
functional testing like this, it would be a great addition!

> btw, requiring Administrative privileges to install PharoLauncher is going to 
> lock out people who don't have administrative control over their PCs e.g. 
> University student labs.

It was like that before. I removed this check from the installer so that 
standard users can install PharoLauncher in a folder where they have write 
access. This way, PharoLauncher works.

> Wanting to run a quick demo for someone in a corporate office.  Why don't we 
> make it the same as OSX and Linux and be usable without Admin privileges.   
> That would lower a barrier to entry.

It is already possible. Just, do not install PharoLauncher in a folder 
requiring admin rights.

Thanks for feedbacks,
Christophe

[Pharo-dev] pharo bootstrap is in inconsistent state

[Alistair Grant]

Hi Pablo & Everyone,

The bootstrap process seems to be in an inconsistent state at the
moment as the scripts in:

- Jenkinsfile   and
- bootstrap/scripts/bootstrap.sh

don't match.

bootstrap/scripts/bootstrap.sh has an error in it:

./pharo Pharo.image eval "PBBootstrap fromCommandLine bootstrap" --quit

fails because the "--quit" option is valid for the st handler
(executing a smalltalk file), but isn't recognised by the eval
handler.

Can someone, Pablo?, confirm what the status is, what it should be and
what the next steps are? :-)

Thanks,
Alistair

Re: [Pharo-dev] pharo bootstrap is in inconsistent state

[teso...@gmail.com]

Hi,
 sorry my mistake when updating the scripts. As the bootstrap.sh is not
executed during the Jenkins process it has not been validated (locally I'm
not using that script, because is trying to download each time the VM and
the bootstraping process image)
The correct line is the one from the JenkinsFile, it should be something
like:

./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --ARCH=${architecture}
--BUILD_NUMBER=${env.BUILD_ID} --quit

I will submit a PR to fix it, as soon as the CI infrastructure is less on
fire.
Until the fix, if you are building the image locally you can change the
error line with:

./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --quit

And it will work.

The idea is to migrate more parts of the process to pure Pharo code,
everything is implemented in a project PharoBootstrapProcess, which is
located in bootstrap/src in the same Pharo repository.
The best way to check what is there is to do the same as the process.

1) Take an image with VMMaker, Espell and Ficus (we have them already made
in
https://github.com/guillep/PharoBootstrap/releases/download/v1.4/bootstrapImage.zip
).
2) Execute bootstrap/scripts/prepare_image.st

That is the same image used to bootstrap Pharo.
I will do another pass on this first part of the process and generate some
documentation about the changes and how to modify the whole process.
We decided to migrate the process by parts to be able to review it easily
than waiting to have a whole migration of the process.

The next step is to do the same with the build.sh file, as you can see it,
is a little complex and have lots of steps.
The idea is again convert them into Pharo code.

Again sorry if the partial change made some problems in your local
execution of the bootstrap.

Cheers.


On Fri, Mar 16, 2018 at 2:02 PM, Alistair Grant 
wrote:

> Hi Pablo & Everyone,
>
> The bootstrap process seems to be in an inconsistent state at the
> moment as the scripts in:
>
> - Jenkinsfile   and
> - bootstrap/scripts/bootstrap.sh
>
> don't match.
>
> bootstrap/scripts/bootstrap.sh has an error in it:
>
> ./pharo Pharo.image eval "PBBootstrap fromCommandLine bootstrap" --quit
>
> fails because the "--quit" option is valid for the st handler
> (executing a smalltalk file), but isn't recognised by the eval
> handler.
>
> Can someone, Pablo?, confirm what the status is, what it should be and
> what the next steps are? :-)
>
> Thanks,
> Alistair
>
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Idea to manager package comment in better way

[Denis Kudriashov]

And at the end I found that #packageComment: is not really work because it
expects already formatted string suitable for source code insertion.
So you can't  just call:

aPackage packageComment: 'my comment'.

Instead all users (only Nautilus exists) should write

aPackage packageComment: 'my comment' printString

I will create pull request with all this changes

2018-03-14 16:51 GMT+01:00 Denis Kudriashov :

> And I found that manifest classes are already commented as package comment.
>
> 2018-03-14 16:40 GMT+01:00 Denis Kudriashov :
>
>> Hi.
>>
>> I look at hierarchy of PackageManifest and I was wondering that all these
>> classes are commented but most of packages which they describe are not.
>>
>> Also interesting that most of manifest comments are same.
>>
>> Then I found that package comment is managed as special class side method
>> #description which is generated when you call "aPackage packageComment:
>> 'test'".
>>
>> Now the idea: will not it be better to manage package comment as manifest
>> class comment?
>>
>> Manifest is already responsible to describe the package. So it looks
>> logical to have "manifest comment = package comment".
>> Also it will simplify code and remove duplication of texts.
>> In addition it will add extra place indicating that package needs to be
>> commented because uncommented classes are marked in the browser.
>>
>> What you think?
>>
>>
>

Re: [Pharo-dev] Pharo 7 new file stream encoders

[Guillermo Polito]

That should be fixed now. I proposed also the rename. I can revert it if
needed.

On Fri, Mar 16, 2018 at 1:04 PM, Sven Van Caekenberghe  wrote:

>
>
> > On 16 Mar 2018, at 11:29, Guillermo Polito 
> wrote:
> >
> > Hi,
> >
> > Yes, I'll provide a PR with that functionality soon. Probably in that
> case *ZnCrPortableWriteStream* is not the right name for that class. Sven,
> do you think renaming it now (before it has lots of users) would be
> acceptable towards backwards compatibility? Otherwise I would name it
> ZnNewLineConverterStream...
>
> Renaming is OK/better, if it works (critical class in IO)
>
> Note #forPlatformLineEnding should do: OSPlatform current lineEnding
>
> > Keep you updated,
> > Guille
> >
> > On Thu, Mar 15, 2018 at 3:11 PM, Sven Van Caekenberghe 
> wrote:
> > I think the idea is to use ZnCrPortableWriteStream for that.
> >
> > > On 15 Mar 2018, at 14:58, Thierry Goubier 
> wrote:
> > >
> > > Hi all,
> > >
> > > how does one create a file stream in Pharo 7 that forces a specific
> > > line end convention ? For example, for forcing all end of lines to be
> > > Character lf.
> > >
> > > The old way,
> > >
> > > fileStream lineEndConvention: #'lf'.
> > >
> > > does not work anymore.
> > >
> > > Thanks,
> > >
> > > Thierry
> > >
> >
> >
> >
> >
> >
> > --
> >
> > 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
>
>
>


-- 



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-dev] Windows PharoLauncher cannot create "C:\Program Files (x86)\Pharo\Pharo.image"

[Peter Uhnák]

> For now, if you are admin, you could install PharoLauncher under «
Program Files » but then, you also need to be admin to run it. If you are
not admin, you should install PharoLauncher elsewhere.

As I see this recommendation for the Nth time, maybe it is time the default
location to C:\Pharo (or C:\PharoLauncher) ...

other languages don't seem to have any problem with that whatsoever (I see
in my dir C:\Python27, C:\Ruby24-x64, cygwin, msys, mingw, ...)

If the installer cannot escalate on its own, it shouldn't try in the first
place. Otherwise it's just bad experience in literally the first step
people will take with Pharo.

Interestingly Python 3 has installed itself in
%APPDATA%\Local\Programs\Python\Python36-32 ... so maybe that's also a
location to consider which doesn't require admin rights.

Peter

On Fri, Mar 16, 2018 at 1:53 PM, Christophe Demarey <
christophe.dema...@inria.fr> wrote:

> Hi Ben,
>
> Le 16 mars 2018 à 13:22, Ben Coman  a écrit :
>
> I popped over to Windows for a moment to try to make my CloudflareUn
> crossplatform,
> and installed PharoLauncher from the downloads page...
> http://files.pharo.org/pharo-launcher/1.1/pharo-launcher-
> installer-1.1-x86.exe
>
> I logged in as an Admin to do this, but when I open it I get an error...
>"PrimitiveFailed: primitive #createDirectory: in WindowsStore failed »
>
>
> Did you try to right-click on the installer and select « Run as
> administrator « ? I’m not sure that apps are all run with admin privileges
> even if you are logged in with an admin account.
>
> Also, I would expect trouble for Non-Admin users trying to use the Admin
> installed Pharo Launcher.trying to write to "pharo-local" under "Program
> Files ».
>
>
> Yes, that for sure!
> For now, if you are admin, you could install PharoLauncher under « Program
> Files » but then, you also need to be admin to run it. If you are not
> admin, you should install PharoLauncher elsewhere.
>
> I did not yet had time to test what Vincent on app packaging but probably,
> it will solve the issue as Pharo Launcher does not need to write anything
> to the installation directory (was needed by tools like GT, epicea, stdout).
>
>   Does PharoLauncher have its own CI testing to ensure it can open okay
> and run an image?   I'm glad to see it promoted in importance but with this
> it probably needs such CI testing of its own separate to the usual Pharo CI
> testing.  On Windows such CI testing *should* run as a Non-Admin user.
>
>
> Functional testing like this is done by hand for this part. There are unit
> tests. you can check that on CI: https://ci.inria.fr/pharo-
> ci-jenkins2/job/PharoLauncher/
> There is room for improvement here. If you have an idea on how to automate
> functional testing like this, it would be a great addition!
>
> btw, requiring Administrative privileges to install PharoLauncher is going
> to lock out people who don't have administrative control over their PCs
> e.g. University student labs.
>
>
> It was like that before. I removed this check from the installer so that
> standard users can install PharoLauncher in a folder where they have write
> access. This way, PharoLauncher works.
>
> Wanting to run a quick demo for someone in a corporate office.  Why don't
> we make it the same as OSX and Linux and be usable without Admin
> privileges.   That would lower a barrier to entry.
>
>
> It is already possible. Just, do not install PharoLauncher in a folder
> requiring admin rights.
>
> Thanks for feedbacks,
> Christophe
>

Re: [Pharo-dev] pharo bootstrap is in inconsistent state

[Alistair Grant]

Hi Pablo,

Thanks for your quick reply.

On 16 March 2018 at 14:38, teso...@gmail.com  wrote:
> Hi,
>  sorry my mistake when updating the scripts. As the bootstrap.sh is not
> executed during the Jenkins process it has not been validated (locally I'm
> not using that script, because is trying to download each time the VM and
> the bootstraping process image)

Right.  Can we make one of the goals of the refactoring to avoid any
code duplication?

e.g. at the moment (ignoring changes proposed below), Jenkins should
be calling bootstrap.sh.


> The correct line is the one from the JenkinsFile, it should be something
> like:
>
> ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --ARCH=${architecture}
> --BUILD_NUMBER=${env.BUILD_ID} --quit
>
> I will submit a PR to fix it, as soon as the CI infrastructure is less on
> fire.
> Until the fix, if you are building the image locally you can change the
> error line with:
>
> ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --quit
>
> And it will work.

Shall do.


> The idea is to migrate more parts of the process to pure Pharo code,

+1


> everything is implemented in a project PharoBootstrapProcess, which is
> located in bootstrap/src in the same Pharo repository.
> The best way to check what is there is to do the same as the process.
> 1) Take an image with VMMaker, Espell and Ficus (we have them already made
> in
> https://github.com/guillep/PharoBootstrap/releases/download/v1.4/bootstrapImage.zip).
> 2) Execute bootstrap/scripts/prepare_image.st
>
> That is the same image used to bootstrap Pharo.
> I will do another pass on this first part of the process and generate some
> documentation about the changes and how to modify the whole process.
> We decided to migrate the process by parts to be able to review it easily
> than waiting to have a whole migration of the process.
>
> The next step is to do the same with the build.sh file, as you can see it,
> is a little complex and have lots of steps.
> The idea is again convert them into Pharo code.

Can we also re-order the bootstrap and break it into several distinct phases.

1. Clean up (this ensures a clean environment for Jenkins)
2. Download all pre-requisites.
The main change here is moving the call to download_vm.sh out of build.sh.
This would allow a particular VM to be installed by hand for step
4, see below.
3. Initial preparation, i.e. all the execution prior to build.sh, e.g.
prepare_image.st.
   Currently this is done with the Pharo 6 VM and image, which makes sense as it
   provides stability.
4. Main image bootstrap.  Which is done with the Pharo 7 VM (currently
what is in build.sh).

That will allow the first three steps to be run once and then skipped
when doing personal development / testing.

I want to be able to manually load the VM to be used in step 4 as part
of some stability testing so we can promote a new Pharo 7 VM to
stable.

Are you open to me submitting some PRs that do this restructure to the
phases listed above and removing duplicate code from Jenkinsfile?


> Again sorry if the partial change made some problems in your local execution
> of the bootstrap.

No problem.

Thanks,
Alistair



> Cheers.
>
>
> On Fri, Mar 16, 2018 at 2:02 PM, Alistair Grant 
> wrote:
>>
>> Hi Pablo & Everyone,
>>
>> The bootstrap process seems to be in an inconsistent state at the
>> moment as the scripts in:
>>
>> - Jenkinsfile   and
>> - bootstrap/scripts/bootstrap.sh
>>
>> don't match.
>>
>> bootstrap/scripts/bootstrap.sh has an error in it:
>>
>> ./pharo Pharo.image eval "PBBootstrap fromCommandLine bootstrap" --quit
>>
>> fails because the "--quit" option is valid for the st handler
>> (executing a smalltalk file), but isn't recognised by the eval
>> handler.
>>
>> Can someone, Pablo?, confirm what the status is, what it should be and
>> what the next steps are? :-)
>>
>> Thanks,
>> Alistair
>>
>
>
>
> --
> Pablo Tesone.
> teso...@gmail.com

Re: [Pharo-dev] pharo bootstrap is in inconsistent state

[teso...@gmail.com]

On Fri, Mar 16, 2018 at 3:26 PM, Alistair Grant 
wrote:

> Hi Pablo,
>
> Thanks for your quick reply.
>
> On 16 March 2018 at 14:38, teso...@gmail.com  wrote:
> > Hi,
> >  sorry my mistake when updating the scripts. As the bootstrap.sh is
> not
> > executed during the Jenkins process it has not been validated (locally
> I'm
> > not using that script, because is trying to download each time the VM and
> > the bootstraping process image)
>
> Right.  Can we make one of the goals of the refactoring to avoid any
> code duplication?
>
> e.g. at the moment (ignoring changes proposed below), Jenkins should
> be calling bootstrap.sh.
>
>
Yes that is part of the plan.


>
> > The correct line is the one from the JenkinsFile, it should be something
> > like:
> >
> > ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st
> --ARCH=${architecture}
> > --BUILD_NUMBER=${env.BUILD_ID} --quit
> >
> > I will submit a PR to fix it, as soon as the CI infrastructure is less on
> > fire.
> > Until the fix, if you are building the image locally you can change the
> > error line with:
> >
> > ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --quit
> >
> > And it will work.
>
> Shall do.
>
>
> > The idea is to migrate more parts of the process to pure Pharo code,
>
> +1
>
>
> > everything is implemented in a project PharoBootstrapProcess, which is
> > located in bootstrap/src in the same Pharo repository.
> > The best way to check what is there is to do the same as the process.
> > 1) Take an image with VMMaker, Espell and Ficus (we have them already
> made
> > in
> > https://github.com/guillep/PharoBootstrap/releases/
> download/v1.4/bootstrapImage.zip).
> > 2) Execute bootstrap/scripts/prepare_image.st
> >
> > That is the same image used to bootstrap Pharo.
> > I will do another pass on this first part of the process and generate
> some
> > documentation about the changes and how to modify the whole process.
> > We decided to migrate the process by parts to be able to review it easily
> > than waiting to have a whole migration of the process.
> >
> > The next step is to do the same with the build.sh file, as you can see
> it,
> > is a little complex and have lots of steps.
> > The idea is again convert them into Pharo code.
>
> Can we also re-order the bootstrap and break it into several distinct
> phases.
>
> 1. Clean up (this ensures a clean environment for Jenkins)
> 2. Download all pre-requisites.
> The main change here is moving the call to download_vm.sh out of
> build.sh.
> This would allow a particular VM to be installed by hand for step
> 4, see below.
> 3. Initial preparation, i.e. all the execution prior to build.sh, e.g.
> prepare_image.st.
>Currently this is done with the Pharo 6 VM and image, which makes sense
> as it
>provides stability.
> 4. Main image bootstrap.  Which is done with the Pharo 7 VM (currently
> what is in build.sh).
>
> That will allow the first three steps to be run once and then skipped
> when doing personal development / testing.
>
> I want to be able to manually load the VM to be used in step 4 as part
> of some stability testing so we can promote a new Pharo 7 VM to
> stable.
>
> Are you open to me submitting some PRs that do this restructure to the
> phases listed above and removing duplicate code from Jenkinsfile?
>
> Yes of course. Thanks

>
> > Again sorry if the partial change made some problems in your local
> execution
> > of the bootstrap.
>
> No problem.
>
> Thanks,
> Alistair
>
>
>
> > Cheers.
> >
> >
> > On Fri, Mar 16, 2018 at 2:02 PM, Alistair Grant 
> > wrote:
> >>
> >> Hi Pablo & Everyone,
> >>
> >> The bootstrap process seems to be in an inconsistent state at the
> >> moment as the scripts in:
> >>
> >> - Jenkinsfile   and
> >> - bootstrap/scripts/bootstrap.sh
> >>
> >> don't match.
> >>
> >> bootstrap/scripts/bootstrap.sh has an error in it:
> >>
> >> ./pharo Pharo.image eval "PBBootstrap fromCommandLine bootstrap" --quit
> >>
> >> fails because the "--quit" option is valid for the st handler
> >> (executing a smalltalk file), but isn't recognised by the eval
> >> handler.
> >>
> >> Can someone, Pablo?, confirm what the status is, what it should be and
> >> what the next steps are? :-)
> >>
> >> Thanks,
> >> Alistair
> >>
> >
> >
> >
> > --
> > Pablo Tesone.
> > teso...@gmail.com
>
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Pharo 7 new file stream encoders

[Thierry Goubier]

2018-03-16 15:01 GMT+01:00 Guillermo Polito :

> That should be fixed now. I proposed also the rename. I can revert it if
> needed.
>

Thanks.

I'll have a look later.

Thierry


>
> On Fri, Mar 16, 2018 at 1:04 PM, Sven Van Caekenberghe 
> wrote:
>
>>
>>
>> > On 16 Mar 2018, at 11:29, Guillermo Polito 
>> wrote:
>> >
>> > Hi,
>> >
>> > Yes, I'll provide a PR with that functionality soon. Probably in that
>> case *ZnCrPortableWriteStream* is not the right name for that class. Sven,
>> do you think renaming it now (before it has lots of users) would be
>> acceptable towards backwards compatibility? Otherwise I would name it
>> ZnNewLineConverterStream...
>>
>> Renaming is OK/better, if it works (critical class in IO)
>>
>> Note #forPlatformLineEnding should do: OSPlatform current lineEnding
>>
>> > Keep you updated,
>> > Guille
>> >
>> > On Thu, Mar 15, 2018 at 3:11 PM, Sven Van Caekenberghe 
>> wrote:
>> > I think the idea is to use ZnCrPortableWriteStream for that.
>> >
>> > > On 15 Mar 2018, at 14:58, Thierry Goubier 
>> wrote:
>> > >
>> > > Hi all,
>> > >
>> > > how does one create a file stream in Pharo 7 that forces a specific
>> > > line end convention ? For example, for forcing all end of lines to be
>> > > Character lf.
>> > >
>> > > The old way,
>> > >
>> > > fileStream lineEndConvention: #'lf'.
>> > >
>> > > does not work anymore.
>> > >
>> > > Thanks,
>> > >
>> > > Thierry
>> > >
>> >
>> >
>> >
>> >
>> >
>> > --
>> >
>> > 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
>>
>>
>>
>
>
> --
>
>
>
> 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 <+33%206%2052%2070%2066%2013>
>

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Esteban Lorenzano]

but thing is: default download should be the launcher. 
because this is the “newbie-friendly” approach. 

All the rest can be in under a link (or a subtitle, doesn’t matters). 

Esteban

> On 16 Mar 2018, at 08:50, Stephane Ducasse  wrote:
> 
> I do not see why this is a problem to have the launcher and Pharo.
> The launcher is an App and Pharo another.
> Yesterday the launcher crashed on Windows when I tried to pair program
> with someone so we downloaded
> the default Pharo version.
> Why do we want to make things complex.
> 
> You want Pharo
> - donwload it
> 
> You want to manage your pharo devs and access jenkins and other services
> - use the launcher.
> 
> Stef
> 
> On Thu, Mar 15, 2018 at 3:38 PM, Marcus Denker  wrote:
>> -> better structure
>> -> simplified the large print (no need to talk about downloading zip files)
>> 
>> TODO:
>>- add back a section about downloading images.
>> 
>>> On 14 Mar 2018, at 18:18, Marcus Denker  wrote:
>>> 
>>> Ok, I will fix that in the next pass.
>>> 
 On 9 Mar 2018, at 18:10, Sean P. DeNigris  wrote:
 
 Marcus Denker-4 wrote
> comments welcome…
 
 IHMO the structure is a little confusing because the first heading "Usage"
 (Launcher implied) is on the same level as other methods like "Linux
 Packages". I think there needs to be something like a header one level
 higher like "Other Options" between these two sections.
 
 
 
 -
 Cheers,
 Sean
 --
 Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
 
>>> 
>> 
>> 
> 

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Ben Coman]

On 15 March 2018 at 16:01, Marcus Denker  wrote:

>
>
> On 15 Mar 2018, at 00:08, Cyril Ferlicot  wrote:
>
>
> On mer. 14 mars 2018 at 18:18, Marcus Denker 
> wrote:
>
>>
>>
>> > On 9 Mar 2018, at 23:34, Torsten Bergmann  wrote:
>> >
>> > Additional portable versions would be nice too (based on a simple ZIP)
>> instead of only the installable apps
>> >
>>
>> Is there a deeper reason for this? If I look at “other systems”, they
>> manage to have *one* download, *one* way of installing.
>> For me, offering *a lot* of possible different ways means that the user
>> has to choose without knowing why there is even the option to choose…
>>
>
> The problem is that Pharo is different from other systems. When you
> install eclipse, you'll use the installed eclipse for all your projects for
> a long time.
>
> Pharo images are more like a "disposable". You'll not use the same Pharo
> image for multiple big projects and you'll more easily throw away an image
> to take a new one from time to time.
>
> Actually I think I download and delete around 5 images/day sometime.
>
> This complicate a little things because sometime you want to directly
> download one image. Sometime you want to have one application to manage
> your images (Pharo launcher)
>
> For me, the Launcher should be the “VM Download”, that comes with a) a
> default template image of the release and b) the launcher too to discover
> images.
>
> *But* it should be done in a way that you can of course just download more
> images (and I would love to have images actually being “one file”) and,
> having Pharo installed, you can run them, using the “Pharo” that you have
> installed (the launcher).
>
> The “Launcher” should feel more like “I have installed Pharo, now I can
> run images”.
>
> As such, I think we should add back links that point to single image
> downloads on the download page.
>
> Marcus
>


I'm really glad PharoLauncher has been promoted to the download page,
but it seems some people want to push PharoLauncher to *be* Pharo.
To me this seems a poor strategy.

The README file in the PharoLauncher zip downloads says...
   "Pharo 1.1-2018.01.16 This distribution was built January 16, 2018."

This seems strange to me and highly likely to confuse newcomers.
Pharo 1.1 more than a few years old.   How can something built in 2018 be
named "Pharo 1.1" ?

And if PharoLauncher is instead published as Pharo 7, then it seems strange
to use it to run Pharo 5 images and later Pharo 8 images.
Why not have the Downloads page just say "The recommended way to manage
Pharo downloads is with PharoLauncher"
and allow PharoLauncher to exist as a separate entity.  This would be
similar similar to those applications where you download
an initial 500kB installer, which then grabs the other 100MB from the net
to complete the install.

Also, when maybe one day we can use Pharo as a command line shell, how will
that relate to PharoLauncher being presented "as" Pharo.


cheers -ben



P.S.  Perhaps the idea of App Store has some similarities to
PharoLauncher,
since in an App Store you search for programs to download and run.
A further evolution of PharoLauncher might become PharoStore
Now Apple's app store is not called "OSX" and Microsoft's app store is not
called "Windows".
They are separate entities .

Re: [Pharo-dev] Idea to manager package comment in better way

[Stephane Ducasse]

Hi denis

Both solutions are ok for me.

STef

On Fri, Mar 16, 2018 at 2:38 PM, Denis Kudriashov  wrote:
> And at the end I found that #packageComment: is not really work because it
> expects already formatted string suitable for source code insertion.
> So you can't  just call:
>
> aPackage packageComment: 'my comment'.
>
> Instead all users (only Nautilus exists) should write
>
> aPackage packageComment: 'my comment' printString
>
> I will create pull request with all this changes
>
> 2018-03-14 16:51 GMT+01:00 Denis Kudriashov :
>>
>> And I found that manifest classes are already commented as package
>> comment.
>>
>> 2018-03-14 16:40 GMT+01:00 Denis Kudriashov :
>>>
>>> Hi.
>>>
>>> I look at hierarchy of PackageManifest and I was wondering that all these
>>> classes are commented but most of packages which they describe are not.
>>>
>>> Also interesting that most of manifest comments are same.
>>>
>>> Then I found that package comment is managed as special class side method
>>> #description which is generated when you call "aPackage packageComment:
>>> 'test'".
>>>
>>> Now the idea: will not it be better to manage package comment as manifest
>>> class comment?
>>>
>>> Manifest is already responsible to describe the package. So it looks
>>> logical to have "manifest comment = package comment".
>>> Also it will simplify code and remove duplication of texts.
>>> In addition it will add extra place indicating that package needs to be
>>> commented because uncommented classes are marked in the browser.
>>>
>>> What you think?
>>>
>>
>

[Pharo-dev] [Pharo 7.0-dev] Build #698: 21595 Use "instance creation" protocol in OSVMWindowHandle

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #698 was: FAILURE.

The Pull Request #1110 was integrated: "21595 Use "instance creation" protocol 
in OSVMWindowHandle"
Pull request url: https://github.com/pharo-project/pharo/pull/1110

Issue Url: https://pharo.fogbugz.com/f/cases/21595
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/698/

Re: [Pharo-dev] Windows PharoLauncher cannot create "C:\Program Files (x86)\Pharo\Pharo.image"

[Ben Coman]

On 16 March 2018 at 22:23, Peter Uhnák  wrote:

> > For now, if you are admin, you could install PharoLauncher under «
> Program Files » but then, you also need to be admin to run it. If you are
> not admin, you should install PharoLauncher elsewhere.
>
> As I see this recommendation for the Nth time, maybe it is time the
> default location to C:\Pharo (or C:\PharoLauncher) ...
>
> other languages don't seem to have any problem with that whatsoever (I see
> in my dir C:\Python27, C:\Ruby24-x64, cygwin, msys, mingw, ...)
>
> If the installer cannot escalate on its own, it shouldn't try in the first
> place. Otherwise it's just bad experience in literally the first step
> people will take with Pharo.
>
> Interestingly Python 3 has installed itself in 
> %APPDATA%\Local\Programs\Python\Python36-32
> ... so maybe that's also a location to consider which doesn't require admin
> rights.
>
> Peter
>

I think Python 3 has it right.  Its also where GitForWindows installs
itself.

Alternatively the parent %APPDATA%\Local\
(equivalently %LOCALAPPDATA% which can be typed into Windows Explorer)
is where many apps seem to put their main executable.
On my system I discover...
%LOCALAPPDATA% \ Discord \ app-0.0.298 \ Discord.exe
%LOCALAPPDATA% \ Atom \ atom.exe
%LOCALAPPDATA% \ GitHubDesktop \ GitHubDesktop.exe
%LOCALAPPDATA% \ slack \ slack.exe
%LOCALAPPDATA% \ Roblox \ Versions \ RobloxStudioLauncherBeta.exe


cheers -ben


>
>
> On Fri, Mar 16, 2018 at 1:53 PM, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
>
>> Hi Ben,
>>
>> Le 16 mars 2018 à 13:22, Ben Coman  a écrit :
>>
>> I popped over to Windows for a moment to try to make my CloudflareUn
>> crossplatform,
>> and installed PharoLauncher from the downloads page...
>> http://files.pharo.org/pharo-launcher/1.1/pharo-launcher-ins
>> taller-1.1-x86.exe
>>
>> I logged in as an Admin to do this, but when I open it I get an error...
>>"PrimitiveFailed: primitive #createDirectory: in WindowsStore failed »
>>
>>
>> Did you try to right-click on the installer and select « Run as
>> administrator « ? I’m not sure that apps are all run with admin privileges
>> even if you are logged in with an admin account.
>>
>> Also, I would expect trouble for Non-Admin users trying to use the Admin
>> installed Pharo Launcher.trying to write to "pharo-local" under "Program
>> Files ».
>>
>>
>> Yes, that for sure!
>> For now, if you are admin, you could install PharoLauncher under «
>> Program Files » but then, you also need to be admin to run it. If you are
>> not admin, you should install PharoLauncher elsewhere.
>>
>> I did not yet had time to test what Vincent on app packaging but
>> probably, it will solve the issue as Pharo Launcher does not need to write
>> anything to the installation directory (was needed by tools like GT,
>> epicea, stdout).
>>
>>   Does PharoLauncher have its own CI testing to ensure it can open okay
>> and run an image?   I'm glad to see it promoted in importance but with this
>> it probably needs such CI testing of its own separate to the usual Pharo CI
>> testing.  On Windows such CI testing *should* run as a Non-Admin user.
>>
>>
>> Functional testing like this is done by hand for this part. There are
>> unit tests. you can check that on CI: https://ci.inria.fr/pharo-
>> ci-jenkins2/job/PharoLauncher/
>> There is room for improvement here. If you have an idea on how to
>> automate functional testing like this, it would be a great addition!
>>
>> btw, requiring Administrative privileges to install PharoLauncher is
>> going to lock out people who don't have administrative control over their
>> PCs e.g. University student labs.
>>
>>
>> It was like that before. I removed this check from the installer so that
>> standard users can install PharoLauncher in a folder where they have write
>> access. This way, PharoLauncher works.
>>
>> Wanting to run a quick demo for someone in a corporate office.  Why don't
>> we make it the same as OSX and Linux and be usable without Admin
>> privileges.   That would lower a barrier to entry.
>>
>>
>> It is already possible. Just, do not install PharoLauncher in a folder
>> requiring admin rights.
>>
>> Thanks for feedbacks,
>> Christophe
>>
>
>

Re: [Pharo-dev] Windows PharoLauncher cannot create "C:\Program Files (x86)\Pharo\Pharo.image"

[Ben Coman]

On 16 March 2018 at 20:53, Christophe Demarey 
wrote:

> Hi Ben,
>
> Le 16 mars 2018 à 13:22, Ben Coman  a écrit :
>
> I popped over to Windows for a moment to try to make my CloudflareUn
> crossplatform,
> and installed PharoLauncher from the downloads page...
> http://files.pharo.org/pharo-launcher/1.1/pharo-launcher-
> installer-1.1-x86.exe
>
> I logged in as an Admin to do this, but when I open it I get an error...
>"PrimitiveFailed: primitive #createDirectory: in WindowsStore failed »
>
>
> Did you try to right-click on the installer and select « Run as
> administrator « ? I’m not sure that apps are all run with admin privileges
> even if you are logged in with an admin account.
>

I tried "Run as administrator" from Non-Admin account with the same result.
An Admin privileged that is no the "Administrator" account (which Microsoft
have hard to access)
only needs UAC to ask the question to approve things to happen.


>
> Also, I would expect trouble for Non-Admin users trying to use the Admin
> installed Pharo Launcher.trying to write to "pharo-local" under "Program
> Files ».
>
>
> Yes, that for sure!
> For now, if you are admin, you could install PharoLauncher under « Program
> Files » but then, you also need to be admin to run it. If you are not
> admin, you should install PharoLauncher elsewhere.
>

Strange. I tried and the Installer hung when I tried to Browse for a new
directory.  I'll try again later after a reboot.


>
> I did not yet had time to test what Vincent on app packaging but probably,
> it will solve the issue as Pharo Launcher does not need to write anything
> to the installation directory (was needed by tools like GT, epicea, stdout).
>
>   Does PharoLauncher have its own CI testing to ensure it can open okay
> and run an image?   I'm glad to see it promoted in importance but with this
> it probably needs such CI testing of its own separate to the usual Pharo CI
> testing.  On Windows such CI testing *should* run as a Non-Admin user.
>
>
> Functional testing like this is done by hand for this part. There are unit
> tests. you can check that on CI: https://ci.inria.fr/pharo-
> ci-jenkins2/job/PharoLauncher/
> There is room for improvement here. If you have an idea on how to automate
> functional testing like this, it would be a great addition!
>

I've not much time with my current 12 hour work roster and side
commitments, but I'll keep it in mind to look if I get the chance.


> tw, requiring Administrative pbrivileges to install PharoLauncher is going
> to lock out people who don't have administrative control over their PCs
> e.g. University student labs.
>
>
> It was like that before. I removed this check from the installer so that
> standard users can install PharoLauncher in a folder where they have write
> access. This way, PharoLauncher works.
>
> Wanting to run a quick demo for someone in a corporate office.  Why don't
> we make it the same as OSX and Linux and be usable without Admin
> privileges.   That would lower a barrier to entry.
>
>
> It is already possible. Just, do not install PharoLauncher in a folder
> requiring admin rights.
>

One improvement would be if there lack of Admin rights is detected, suggest
an alternate default install location,
but I guess thats highly dependent on what is available from the
installer-system.

cheers -ben



> Thanks for feedbacks,
> Christophe
>

[Pharo-dev] [Pharo 7.0-dev] Build #699: 21601 Use "instance creation" in FT classes

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #699 was: SUCCESS.

The Pull Request #1115 was integrated: "21601 Use "instance creation" in FT 
classes"
Pull request url: https://github.com/pharo-project/pharo/pull/1115

Issue Url: https://pharo.fogbugz.com/f/cases/21601
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/699/

Re: [Pharo-dev] Executive Summary of the recent FileStream Changes

[Sean P. DeNigris]

Stephane Ducasse-3 wrote
> we are planning to migrate a selection of the old
> deprecated methods (of Pharo 30, 40, 50, 60) into a MigrationPackage
> with deprecatedWithTransform rule
> to help the migration of the old code to new one.

Cool!!!



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

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Sean P. DeNigris]

Ben Coman wrote
> it seems some people want to push PharoLauncher to *be* Pharo.
> To me this seems a poor strategy… This seems strange to me and highly
> likely to confuse newcomers.

Yes, this was already discussed at length on the ML. 

The term Pharo already has a meaning: a vm + image containing both an OOP
language (is it Smalltalk or Smalltalk inspired? Please don't actually
answer that lol) and IDE written therein - or you could call it prototype
Dynabook software.

If we now try to redefine the above (or really overload, because the former
definition will still coexist) to mean an app that manages images, it may
just be the final straw to make sure that no one ever will be able to give
any acceptable answer in less than 2038 hours to the question: What is
Pharo? ;)

But just in case we step into the quicksand even further, in this dystopian
future you can just copy paste this definition:
Pharo is a Pharo app that manages Pharo images, which can be used to make
Pharo apps, which can be used to manage Pharo images, [which can be used to
make Pharo apps, which can be used to manage Pharo images]*



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

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Sven Van Caekenberghe]

> On 16 Mar 2018, at 17:59, Sean P. DeNigris  wrote:
> 
> Ben Coman wrote
>> it seems some people want to push PharoLauncher to *be* Pharo.
>> To me this seems a poor strategy… This seems strange to me and highly
>> likely to confuse newcomers.
> 
> Yes, this was already discussed at length on the ML. 
> 
> The term Pharo already has a meaning: a vm + image containing both an OOP
> language (is it Smalltalk or Smalltalk inspired? Please don't actually
> answer that lol) and IDE written therein - or you could call it prototype
> Dynabook software.
> 
> If we now try to redefine the above (or really overload, because the former
> definition will still coexist) to mean an app that manages images, it may
> just be the final straw to make sure that no one ever will be able to give
> any acceptable answer in less than 2038 hours to the question: What is
> Pharo? ;)
> 
> But just in case we step into the quicksand even further, in this dystopian
> future you can just copy paste this definition:
> Pharo is a Pharo app that manages Pharo images, which can be used to make
> Pharo apps, which can be used to manage Pharo images, [which can be used to
> make Pharo apps, which can be used to manage Pharo images]*

Haha, yes it is so fluid it cannot be described only be experienced through 
prolonged exposure, it is truly magical.

Actually, that is not so far from the truth.

> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Denis Kudriashov]

2018-03-05 16:17 GMT+01:00 Denis Kudriashov :

> 2018-03-05 16:13 GMT+01:00 Cyril Ferlicot :
>
>> On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov 
>> wrote:
>> > Hi Pablo.
>> >
>> > Dev branch approach not really works. Because any merge into master will
>> > break master baseline. (notice that baseline is in same repo).
>> > And managing merges by hand all the time is not a solution.
>> >
>> >
>> Hi!
>> If you don't want to manage the merges by hand you can maybe have two
>> bsaelines?
>> BaselineOfCalypso and BaselineOfCalypsoDev?
>>
>
At the end I found that this approach with two baselines is not really
working.
So I will adopt my projects to the following pattern:

Each release will point to static version of dependencies. They all in
master branch.
Floating version like 0.5.x will be maintained in separate branch instead
of floating tag. In this branch baseline will reference dependencies using
similar "floating" branch in their repositories.

So to get all minor fixes from all dependencies the code should be loaded
from such floating branch (0.5.x). The main project can be locked to fix
current version (only dependencies will be updated).
And all released versions (0.5.3 tag) will be completely reproducible.


> It should work. But is it right way that everybody should follow?
>
> With configurations it was easy to do in single class.
>
>
>>
>> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>>
>>
>

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Thierry Goubier]

Le 16/03/2018 à 18:37, Denis Kudriashov a écrit :


2018-03-05 16:17 GMT+01:00 Denis Kudriashov >:


2018-03-05 16:13 GMT+01:00 Cyril Ferlicot mailto:cyril.ferli...@gmail.com>>:

On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov
mailto:dionisi...@gmail.com>> wrote:
> Hi Pablo.
>
> Dev branch approach not really works. Because any merge into master 
will
> break master baseline. (notice that baseline is in same repo).
> And managing merges by hand all the time is not a solution.
>
>
Hi!
If you don't want to manage the merges by hand you can maybe
have two bsaelines?
BaselineOfCalypso and BaselineOfCalypsoDev?


At the end I found that this approach with two baselines is not really 
working.

So I will adopt my projects to the following pattern:

Each release will point to static version of dependencies. They all in 
master branch.
Floating version like 0.5.x will be maintained in separate branch 
instead of floating tag. In this branch baseline will reference 
dependencies using similar "floating" branch in their repositories.


So to get all minor fixes from all dependencies the code should be 
loaded from such floating branch (0.5.x). The main project can be locked 
to fix current version (only dependencies will be updated).

And all released versions (0.5.3 tag) will be completely reproducible.


That sounds like a nice scheme.

Thierry



It should work. But is it right way that everybody should follow?

With configurations it was easy to do in single class.


--
Cyril Ferlicot
https://ferlicot.fr

[Pharo-dev] [Pharo 7.0-dev] Build #700: 21600 Use "instance creation" protocol in Monticello

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #700 was: SUCCESS.

The Pull Request #1114 was integrated: "21600 Use "instance creation" protocol 
in Monticello"
Pull request url: https://github.com/pharo-project/pharo/pull/1114

Issue Url: https://pharo.fogbugz.com/f/cases/21600
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/700/

Re: [Pharo-dev] FileHandle creates a buffered stream on a buffered stream

[Stephane Ducasse]

Guille is a machine :)
I'm amazed and love to see all this energy pushed into Pharo.
Tx guille.


On Fri, Mar 16, 2018 at 1:37 PM, Sven Van Caekenberghe  wrote:
>
>
>> On 16 Mar 2018, at 11:46, Guillermo Polito  wrote:
>>
>> Nice catch. The write stream is well defined in comparison.
>>
>> https://pharo.fogbugz.com/f/cases/21604/FileHandle-creates-a-buffered-stream-on-a-buffered-stream
>>
>> https://github.com/pharo-project/pharo/pull/1118
>>
>> Can somebody review please?
>
> OK by me
>
>> Tx,
>> Guille
>>
>> On Thu, Mar 15, 2018 at 4:00 PM, Sven Van Caekenberghe  wrote:
>> Hi (Guille),
>>
>> FileHandle creates a buffered stream on a buffered stream when sent 
>> #readStream.
>>
>> Note how #binaryReadStream adds a bufferer stream as well as 
>> #readStreamEncoded:
>>
>> Probably the latter should not do this
>>
>> Sven
>>
>>
>>
>> --
>>
>> 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-dev] Executive Summary of the recent FileStream Changes

[Stephane Ducasse]

Sean

you can really help on this one.

Stef

On Fri, Mar 16, 2018 at 5:47 PM, Sean P. DeNigris  wrote:
> Stephane Ducasse-3 wrote
>> we are planning to migrate a selection of the old
>> deprecated methods (of Pharo 30, 40, 50, 60) into a MigrationPackage
>> with deprecatedWithTransform rule
>> to help the migration of the old code to new one.
>
> Cool!!!
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Re: [Pharo-dev] Base64MimeConverter class>>mimeDecodeToBytes: change breaks image load

[Stephane Ducasse]

Hi sven

can you open a bug entry?
Sven I have a APi question why we could not have decodeBase64: in
something else than ZnUtils.
I tend to stay away from class having Util in their names :) I still
have the scars on my body of my battle
against Utilities.

Stef


On Thu, Mar 15, 2018 at 1:08 PM, Sven Van Caekenberghe  wrote:
> BTW, for the record, we should deprecate Base64MimeConverter, and 
> remove/change the following convenience methods:
>
> Remove
>
> String>>#base64Encoded.
>
> Change
>
> ByteArray>>#base64Encoded
> "Encode the receiver using Base64, see ZnBase64Encoder"
>
> ^ ZnBase64Encoder new encode: self
>
> String>>#base64Decoded
> "Decode the receiver using Base64, see ZnBase64Encoder"
>
> ^ ZnBase64Encoder new decode: self
>
> The thing is, Base64 is defined as going from bytes -> characters and vice 
> versa. Not as going from characters -> characters. For that you need to use 
> an explicit character encoder as in ZnUtils class>>#decodeBase64: and 
> ZnUtils>>#encodeBase64:
>
> So yes, this would be a breaking change, but an easy one to follow since 
> Base64 is really very simple as a concept.
>
>> On 15 Mar 2018, at 12:47, Sven Van Caekenberghe  wrote:
>>
>>
>>
>>> On 15 Mar 2018, at 12:28, Alistair Grant  wrote:
>>>
>>> Hi Guille & Pavel,
>>>
>>> On 6 Feb Guille changed Base64MimeConverter class>>mimeDecodeToBytes:
>>> so that it doesn't reset the dataStream position back to the start of
>>> the stream.  This breaks Pavel's PlayingCard, part of FreeCell (you
>>> can see that I only load important stuff :-)).
>>>
>>> PlayingCard class>>initialize
>>> "PlayingCard initialize"
>>> | forms f |
>>> "Read the stored forms from mime-encoded data in imageData."
>>> f := Base64MimeConverter mimeDecodeToBytes: (ReadStream on: self imageData).
>>> forms := OrderedCollection new.
>>> f next = 2 ifFalse: [self error: 'corrupted imageData'].
>>> [f atEnd] whileFalse: [forms add: (Form new readFrom: f)].
>>> ...
>>>
>>>
>>> Previously, f would be at the start of the stream (which makes sense
>>> given this usage), but now it is at the end of the stream, so returns
>>> nil and "f next = 2" fails.
>>>
>>> Guille, can you explain the change.  The commit log just says "make tests 
>>> run".
>>>
>>> Note that a lot of users of this won't fail as they just call
>>> #contents of the stream after #mimeDecodeToBytes:, which works
>>> regardless of the current position.
>>
>> So doing
>>
>>  f reset
>>
>> at the caller site would fix it then ?
>>
>> Note that there is the newer ZnBase64Encoder that can be used as follows:
>>
>>  f := (ZnBase64Encoder new decode: self imageData) readStream.
>>
>> Sven
>
>

Re: [Pharo-dev] Base64MimeConverter class>>mimeDecodeToBytes: change breaks image load

[Stephane Ducasse]

Yes this is that you cannot have a png embedded in stream. Just at the
beginning.
What funny concept.

On Thu, Mar 15, 2018 at 2:14 PM, Sven Van Caekenberghe  wrote:
> And in PNGReadWriter>>nextImage we should remove stream reset and stream 
> binary.
>
> This probably goes for the other image readers as well.
>
>> On 15 Mar 2018, at 13:38, Sven Van Caekenberghe  wrote:
>>
>> Yeah, right, good catch.
>>
>> But what is this nonsense:
>>
>> PNGReadWriter>>on: aStream
>>   (stream := aStream) reset.
>>   stream binary
>>   "Note that 'reset' makes a file be text.  Must do this after."
>>
>> Of course you can only read an image from a binary stream, there should be 
>> nothing else there but
>>
>> stream := aStream
>>
>>> On 15 Mar 2018, at 13:31, Alistair Grant  wrote:
>>>
>>> Also:
>>>
>>> 'apicture.png' asFileReference inspect.
>>>
>>> Will raise a "image format not recognised" because:
>>>
>>> - AbstractFileReference>>binaryReadStreamDo: ultimately uses a
>>> ZnBufferedReadStream
>>> - ImageReadWriter>>on: sends #reset to the stream
>>>
>>> and ZnBufferedReadStream doesn't implement #reset.
>>>
>>> My guess is that ZnBufferedReadStream should implement #reset (it has
>>> #position:).  But I'm not familiar with the current thinking on stream
>>> rationalisation.
>>>
>>> I'll raise some fogbugz issues a bit later.
>>>
>>> Image downloaded today:
>>>
>>> Pharo 7.0
>>> Build information:
>>> Pharo-7.0+alpha.build.696.sha.a26248bb90ee8dfba131f2f4d71ba2bbbad5d00d
>>> (64 Bit)
>>>
>>>
>>>
>>> Thanks,
>>> Alistair
>>>
>>>
>>> On 15 March 2018 at 13:08, Sven Van Caekenberghe  wrote:
 BTW, for the record, we should deprecate Base64MimeConverter, and 
 remove/change the following convenience methods:

 Remove

 String>>#base64Encoded.

 Change

 ByteArray>>#base64Encoded
   "Encode the receiver using Base64, see ZnBase64Encoder"

   ^ ZnBase64Encoder new encode: self

 String>>#base64Decoded
   "Decode the receiver using Base64, see ZnBase64Encoder"

   ^ ZnBase64Encoder new decode: self

 The thing is, Base64 is defined as going from bytes -> characters and vice 
 versa. Not as going from characters -> characters. For that you need to 
 use an explicit character encoder as in ZnUtils class>>#decodeBase64: and 
 ZnUtils>>#encodeBase64:

 So yes, this would be a breaking change, but an easy one to follow since 
 Base64 is really very simple as a concept.

> On 15 Mar 2018, at 12:47, Sven Van Caekenberghe  wrote:
>
>
>
>> On 15 Mar 2018, at 12:28, Alistair Grant  wrote:
>>
>> Hi Guille & Pavel,
>>
>> On 6 Feb Guille changed Base64MimeConverter class>>mimeDecodeToBytes:
>> so that it doesn't reset the dataStream position back to the start of
>> the stream.  This breaks Pavel's PlayingCard, part of FreeCell (you
>> can see that I only load important stuff :-)).
>>
>> PlayingCard class>>initialize
>> "PlayingCard initialize"
>> | forms f |
>> "Read the stored forms from mime-encoded data in imageData."
>> f := Base64MimeConverter mimeDecodeToBytes: (ReadStream on: self 
>> imageData).
>> forms := OrderedCollection new.
>> f next = 2 ifFalse: [self error: 'corrupted imageData'].
>> [f atEnd] whileFalse: [forms add: (Form new readFrom: f)].
>> ...
>>
>>
>> Previously, f would be at the start of the stream (which makes sense
>> given this usage), but now it is at the end of the stream, so returns
>> nil and "f next = 2" fails.
>>
>> Guille, can you explain the change.  The commit log just says "make 
>> tests run".
>>
>> Note that a lot of users of this won't fail as they just call
>> #contents of the stream after #mimeDecodeToBytes:, which works
>> regardless of the current position.
>
> So doing
>
> f reset
>
> at the caller site would fix it then ?
>
> Note that there is the newer ZnBase64Encoder that can be used as follows:
>
> f := (ZnBase64Encoder new decode: self imageData) readStream.
>
> Sven


>>>
>>
>
>

[Pharo-dev] [Pharo 7.0-dev] Build #701: 21487 Lint clean #testAtWrapPut

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #701 was: SUCCESS.

The Pull Request #1125 was integrated: "21487 Lint clean #testAtWrapPut"
Pull request url: https://github.com/pharo-project/pharo/pull/1125

Issue Url: https://pharo.fogbugz.com/f/cases/21487
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/701/

[Pharo-dev] [Pharo 7.0-dev] Build #702: Remove extra buffered read stream

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #702 was: SUCCESS.

The Pull Request #1118 was integrated: "Remove extra buffered read stream"
Pull request url: https://github.com/pharo-project/pharo/pull/1118

Issue Url: https://pharo.fogbugz.com/f/cases/21604
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/702/

Re: [Pharo-dev] Executive Summary of the recent FileStream Changes

[monty]

The code is in XMLParser: see XMLEncodingDetector. I can port it, if you think 
the algorithm is appropriate.

The YAML algorithm is actually a less restrictive version of this XML one: 
https://www.w3.org/TR/REC-xml/#sec-guessing
The XML one is "Non-Normative" (ie optional), so I chose to implement the more 
general YAML algorithm instead.

> Sent: Friday, March 16, 2018 at 6:44 AM
> From: "Sven Van Caekenberghe" 
> To: "Pharo Development List" 
> Subject: Re: [Pharo-dev] Executive Summary of the recent FileStream Changes
>
> 
> 
> > On 16 Mar 2018, at 07:05, monty  wrote:
> > 
> >> Sent: Thursday, March 15, 2018 at 4:01 PM
> >> From: "Sven Van Caekenberghe" 
> >> To: "Pharo Development List" 
> >> Subject: [Pharo-dev] Executive Summary of the recent FileStream Changes
> >> 
> >> Executive Summary of the recent FileStream Changes
> >> 
> >> In Pharo 7 Guille Polito recently committed a heroic set of changes that 
> >> we were planning to do for a long time but were afraid to take on.
> >> 
> >> The idea is to replace a couple of fat, overly complex, multi-functional, 
> >> do-all classes with a set of simpler single purpose classes that can be 
> >> combined as needed.
> >> 
> >> The classes that we want to get rid of can be found in the package 
> >> DeprecatedFileSystem, in particular FileStream, StandardFileStream, 
> >> MultiByteFileStream, MultiByteBinaryOrTextStream and RWBinaryOrTextStream.
> > 
> > StandardFileStream, at least, should remain for backwards compatibility and 
> > cross-platform compatibility with Squeak. It's a no-frills, non-decoding, 
> > non-LE normalizing stream that is heavily depended on.
> 
> Hmm, maybe.
> 
> The standard (no pun intended) interface to the file system in Pharo has been 
> FileSystem (FileReference) for quite a while. Many packages dealing with 
> either different Pharo versions or different Smalltalk implementations have 
> constructed their own portability facade (heck, I even did it in 
> ZnFileSystemUtils myself).
> 
> Note however that some aspects (API, behaviour) about the streams themselves 
> changed as well (no longer being bivalent, separating reading/writing, 
> smaller/simpler API, sometimes no positioning).
> 
> >> The replacements are can be found in packages Files and 
> >> Zinc-Character-Encoding-Core.
> >> 
> >> Encoding and decoding characters to and from bytes is done using classes 
> >> that you wrap around a more primitive binary stream. The same goes for 
> >> buffering or translating line endings.
> >> 
> >> For example,
> >> 
> >> '/Users/sven/Desktop/foo.txt' asFileReference binaryReadStream.
> >> 
> >> gives you a ZnBufferedWriteStream wrapping a BinaryWriteStream.
> >> 
> >> While,
> >> 
> >> '/Users/sven/Desktop/foo.txt' asFileReference readStream.
> > 
> > What do you think about this algorithm for encoding detection: 
> > http://www.yaml.org/spec/1.2/spec.html#id2771184
> > 
> > I have an implementation (with tests), if you're interested. (I was waiting 
> > to propose it until the FileSystem API switched over to using Zn streams 
> > and encoders. The TextConverter API doesn't support UTF-32.)
> 
> I did a primitive one in ZnCharacterEncoding class>>#detectEncoding: but I am 
> not happy with it. I will read your reference and I am certainly interested 
> in seeing your code !
> 
> >> gives a ZnCharacterReadStream wrapping a ZnBufferedWriteStream wrapping a 
> >> BinaryWriteStream.
> >> 
> >> To translate line endings, we would wrap a ZnCharacterWriteStream using a 
> >> ZnCrPortableWriteStream.
> >> 
> >> There are a couple of more specialised streams to cover special cases 
> >> (like read and writing at the same time).
> >> 
> >> SocketStream remains another fat, overly complex, multi-functional, do-all 
> >> class, for which usable replacements exist in the form of ZdcSocketStream 
> >> and ZdcSecureSocketStream, which are simpler, cleaner and binary only.
> >> 
> >> Of course, switching is more than replacing one class with a 100% 
> >> compatible alternative, that would give us the same complex result. The 
> >> challenge is to use a simpler API as well, to rethink how the streams are 
> >> used. You know, KISS.
> >> 
> >> Of course, we are far from done and need more testing, debugging and help 
> >> from as many people as possible.
> >> 
> >> Sven
> >> 
> >> 
> >> --
> >> Sven Van Caekenberghe
> >> Proudly supporting Pharo
> >> http://pharo.org
> >> http://association.pharo.org
> >> http://consortium.pharo.org
> 
> 
>