March 2018 - Pharo-dev - lists.pharo.org

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

by 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 <dionisiydk(a)gmail.com>: > And I found that manifest classes are already commented as package comment. > > 2018-03-14 16:40 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> 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? >> >> >

March 16, 2018

pharo bootstrap is in inconsistent state

by 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

March 16, 2018

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

by Christophe Demarey

Hi Ben, > Le 16 mars 2018 Ã 13:22, Ben Coman <btc(a)openinworld.com> 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.… <http://files.pharo.org/pharo-launcher/1.1/pharo-launcher-installer-1.1-x86.…> > > 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

March 16, 2018

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

by Christophe Demarey

> Le 15 mars 2018 Ã 09:27, Esteban Lorenzano <estebanlm(a)gmail.com> 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

March 16, 2018

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

by Sven Van Caekenberghe

> On 16 Mar 2018, at 11:46, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Nice catch. The write stream is well defined in comparison. > > https://pharo.fogbugz.com/f/cases/21604/FileHandle-creates-a-buffered-strea… > > 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 <sven(a)stfx.eu> 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

March 16, 2018

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

by 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.… 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

March 16, 2018

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

by Sven Van Caekenberghe

> On 16 Mar 2018, at 11:29, Guillermo Polito <guillermopolito(a)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... 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 <sven(a)stfx.eu> wrote: > I think the idea is to use ZnCrPortableWriteStream for that. > > > On 15 Mar 2018, at 14:58, Thierry Goubier <thierry.goubier(a)gmail.com> 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

March 16, 2018

Re: [Pharo-dev] [Vm-dev] Reproducible VM crash from commit 4749358 onwards

by Alistair Grant

Hi Eliot, On 15 March 2018 at 23:53, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Alistair, > > I can reproduce this on Mac OS too. Thanks very much for the report. Looking at it now. Thanks! No more crashes with the latest VM (Thu Mar 15 19:15:05 2018 -0700) (and the correct FileAttributesPlugin version :-)). Cheers, Alistair > On Thu, Mar 15, 2018 at 2:43 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> >> Hi Everyone, >> >> If I download a recent Pharo 64 bit image, e.g.: >> >> http://files.pharo.org/image/70/latest-64.zip >> >> And use a Pharo VM from commit: >> >> commit 4749358b5717b9a2f7e1d44f9baac48ed5d80431 >> Author: Eliot Miranda <eliot.miranda(a)gmail.com> >> Date: Wed Mar 7 15:11:21 2018 -0800 >> >> or later, the following will reliably crash the VM: >> >> >> ./pharo Pharo7.0-64bit-a26248b.image eval "OCBytecodeGeneratorTest >> run: #testExample2" >> >> >> Earlier VMs don't crash. >> >> Stack dump below my signature. >> >> I'm a bit out of my depth beyond that... >> >> OS: Ubuntu 16.04 64 bit >> >> ...

March 16, 2018

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

by Guillermo Polito

Nice catch. The write stream is well defined in comparison. https://pharo.fogbugz.com/f/cases/21604/FileHandle-creates-a-buffered-strea… 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 <sven(a)stfx.eu> 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 16, 2018

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

by Sven Van Caekenberghe

> On 16 Mar 2018, at 07:05, monty <monty2(a)programmer.net> wrote: > >> Sent: Thursday, March 15, 2018 at 4:01 PM >> From: "Sven Van Caekenberghe" <sven(a)stfx.eu> >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> 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

March 16, 2018