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

Re: [Pharo-dev] STON updates/improvements

by Sven Van Caekenberghe

> On 12 Oct 2018, at 11:49, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Thanks Sven :) > > On Fri, Oct 12, 2018 at 11:38 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Now, AFTER the changes, the STON serialisation looks as follows: > > { > #datatype : MimeType [ 'application/json' ], > #background : Color [ #red ], > #home : URL [ 'https://pharo.org/experimental' ], > #workdir : FILE [ '/tmp/pharo/work' ] > } > > which is a huge improvement, IMO. > > Yes, I've suffered the things you explain before :) > > > What do you think ? Comments, feedback, remarks ? > Any other suggestions for other object that could use this treatment ? > > Question: is it a new mechanism or it is based on the existing mapping mechanisms? Can we override it/extend it? This is using the existing mechanism (with specific #stonName's that differ from the class name). Several class already used this mechanism (the Chronology classes for example). In the case of FileReference it is a bit more of a hack: FileReferences to other filesystems than disk are serialised as before. Furthermore I had to use FILE instead of File since that class already exists. On other platforms, other concrete classes might handle the same tags. It wouldn't hurt if others thought a bit about this too. In any case, I intend to work a bit on documentation later on.

Oct. 12, 2018

Re: [Pharo-dev] STON updates/improvements

by Guillermo Polito

Thanks Sven :) On Fri, Oct 12, 2018 at 11:38 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Now, AFTER the changes, the STON serialisation looks as follows: > > { > #datatype : MimeType [ 'application/json' ], > #background : Color [ #red ], > #home : URL [ 'https://pharo.org/experimental' ], > #workdir : FILE [ '/tmp/pharo/work' ] > } > > which is a huge improvement, IMO. > Yes, I've suffered the things you explain before :) > > What do you think ? Comments, feedback, remarks ? > Any other suggestions for other object that could use this treatment ? > Question: is it a new mechanism or it is based on the existing mapping mechanisms? Can we override it/extend it?

Oct. 12, 2018

STON updates/improvements

by Sven Van Caekenberghe

Hi, I have consolidated all repositories where STON code lives so that they are now all in sync, and in sync with changes from Pharo 7. http://ss3.gemtalksystems.com/ss/STON/ http://smalltalkhub.com/mc/SvenVanCaekenberghe/STON/main/ https://github.com/svenvc/ston There are 2 CI builds https://travis-ci.org/svenvc/ston https://ci.inria.fr/pharo-contribution/job/STON/ The project's format will remain FileTree (until Tonel is supported on other Smalltalk implementations). Last week I applied a couple of changes that I wanted to apply for a long time. Traits are no longer used in the implementation (which should help porting to other Smalltalk implementations). More specifically the following are used (again) - Class>>#stonOn: - ClassDescription>>#stonContainsSubObjects - Metaclass>>#stonName - Metaclass>>#stonOn: instead of - TClass>>#stonOn: - TClassDescription>>#stonContainsSubObjects - TApplyingOnClassSide>>#stonName - TApplyingOnClassSide>>#stonOn: use #instanceSide instead of #theNonMetaClass in MetaClass>>#stonOn: Reorganised the packages with sub tags. Add support for Fraction and ScaledDecimal literals (not in JSON mode). Previously a float conversion meant there was a loss of information. Change the representation of Date to include a timezone offset (since the current Date implementation is sensitive to this). 2018-10-11Z 2018-10-11+00:00 2018-10-11+02:00 A missing timezone offset is interpreted as being the local timezone offset. Add more special representations for common value style objects. One of STON's goals is to be a human readable and human editable representation of an object graph while remaining 100% correct (not losing information). The following were added for this reason: MimeType and URL using ZnMimeType and ZnUrl respectively as simplified values. MimeType['application/json'] URL['https://pharo.org'] Color Color[#red] Color{#red:1.0,#green:0.0,#blue:0.0,#alpha:0.4} FileReferences to the DiskFileSystem (effectively normal files) FILE['/tmp/foo.txt'] Here is an example of how much difference that makes. Given the following Dictionary { #background->Color red. #workdir->'/tmp/pharo/work/' asFileReference. #home->'https://pharo.org/experimental' asUrl. #datatype->'application/json' asMIMEType } asDictionary Which contains real objects as its values. was serialised by STON BEFORE the changes as { #datatype : ZnMimeType { #main : 'application', #sub : 'json' }, #background : Color { #rgb : 1072693248, #cachedDepth : 32, #cachedBitPattern : Bitmap [ 4294901760 ], #alpha : 255 }, #home : ZnUrl { #scheme : #https, #host : 'pharo.org', #segments : OrderedCollection [ 'experimental' ] }, #workdir : FileReference { #filesystem : FileSystem { #store : MacStore { #maxFileNameLength : 255 } }, #path : AbsolutePath [ 'tmp', 'pharo', 'work' ] } } which is 100% correct, but not very human friendly. Now, AFTER the changes, the STON serialisation looks as follows: { #datatype : MimeType [ 'application/json' ], #background : Color [ #red ], #home : URL [ 'https://pharo.org/experimental' ], #workdir : FILE [ '/tmp/pharo/work' ] } which is a huge improvement, IMO. What do you think ? Comments, feedback, remarks ? Any other suggestions for other object that could use this treatment ? Sven

Oct. 12, 2018

MacOS instructions do not work on Mojave

by Jan BlizniÄenko

Hello Before starting, note that I am not MacOS user. Most of experiments I have done on MacOS Mojave in VirualBox and with friend with mac with MacOS Mojave. On https://pharo.org/download there are instructions how to run Pharo on MacOS. These steps are however not needed for Pharo Launcher which is now default download - it runs out of a box, you just have to confirm you really want to start it. On the other hand, these instructions do not work for "Pharo standalone"/"platform"/"all in one" package at all and just with these instructions such package cannot be started. Possibility to use this package without Launcher is important to me. Error is: "Pharo6.1-64 is damaged and cannot be opened. You should move it to Trash." and not option to start anyway. There are two options on download page, but none of these work: 1) Right clicking and picking Open does not make any difference at all - same error message is the result. 2) Going through settings - Security & Privacy does not work either because option Anywhere does not appear after clicking on the lockpad and filling my password - it is just not there. Only way to overcome this is to run "sudo spctl --master-disable" in terminal, which is command that is supposed to completely turn off Gatekeeper. After this command is executed, Pharo opens just fine and even the Anywhere option appears in security settings. It means that the Pharo package is not damaged at all (as error message indicates), it is just not properly signed. <http://forum.world.st/file/t369698/Pharo-MacOS_Mojave.png> <http://forum.world.st/file/t369698/Pharo-MacOS_Mojave-2.png> Jan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 12, 2018

[Call for testers] Pharo Launcher 1.4.5

by Guillermo Polito

Hi all, We have been working these last ~two weeks with Christophe on the stability of the launcher. We have prepared version 1.4.5, and we would like to have some feedback. http://files.pharo.org/pharo-launcher/1.4.5 So, we would really LOVE, if somebody can play with this version and send us feedback. Specially, if your username in your machine has characters that encoded take more than 1 byte, we really would like your feedback. We have tested with japanese characters, and others like Ã®,Ã¼, etc, but the more the better. The main focus was on: - correct management of encodings (in all platforms) - of environment variables - of files and paths - of commands called through OSProcess - better error management in case of edge cases (like when we cannot determine the version of an image) Just FYI: the major limitation of the launcher right now (and it was like that since ever) is that we cannot call external processes with non-ascii characters in windows. This happens because ProcessWrapper uses the ascii version of the windows API to create a process. With what we have learnt this week, we would like to push some of these fixes to Pharo7 too soon: - Correct encoding/decoding of environment variables in linux/osx - Ability to access the encoded version of environment variables in linux/osx to give users control over the encoding they want (or even access binary data) - Correct encoding/decoding of environment variables in windows by using the correct windows API (current primitiveGetenv in windows uses Ascii version too...) In the long term, we also need a solution to enhance or replace ProcessWrapper using the W (wide) version of the windows API. But that is far more work... GC, Guille & Christophe

Oct. 12, 2018

Re: [Pharo-dev] Laucher cannot start a fresh 7 image

by Christophe Demarey

Do you have a pointer to the issue? If you do not use the latest Pharo Launcher, please update it: http://files.pharo.org/pharo-launcher/1.4.5/ Once done, you could also remove the pharo 7 VM from the vm folder and also the private vm folder to ensure the latest VM is downloaded. If you still have an issue, please post it on https://github.com/pharo-project/pharo-launcher/issues Christophe > Le 11 oct. 2018 Ã 20:49, Esteban A. Maringolo <emaringolo(a)gmail.com> a Ã©crit : > > I reported this a week or so ago, same issue. > > On 11/10/2018 03:09, phil(a)highoctane.be wrote: >> Used to work. Then does not anymore. >> >> Phil > > -- > Esteban A. Maringolo >

Oct. 12, 2018

Re: [Pharo-dev] What you think about visibility of trait method in browser?

by Denis Kudriashov

Hi Guille. ÑÑ, 11 Ð¾ÐºÑ. 2018 Ð³. Ð² 9:24, Guillermo Polito <guillermopolito(a)gmail.com>: > Hi, > > >> On Wed, Oct 10, 2018, 19:40 Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> Hello. >>> >>> I want to ask you what you think about it. >>> - do you prefer to see trait methods by default? >>> >> > Yes. > > >> - do you want feature to hide trait methods? >>> >> > Not necessarily. But the problem are not the methods "in traits". Read my > explanation below. > > Current Calypso support for traits follows simple principle which I found >>> important for me. But I can be the only guy who think this way. Maybe >>> because I meet traits in Self. So: >>> I simply want to see in the browser what class is actually implements. >>> If class uses TEmpty trait (with ifEmpty, isEmpty methods) I don't want to >>> see its methods by default. When I open such class in the browser I want to >>> see only code which class explicitly implements For me this logic is same >>> as for superclass methods. >>> >> > Well, the main problem of this approach is that traits in self are > fundamentally different than traits in self. And the main answer here is > not flattening or not flattening, but the idea of "trait composition". A > class does not just use "some traits". It uses a trait composition, which > includes also other rules like aliases, overrides and removals. With the > new implementation there is also deep aliasing. And moreover, since traits > are stateful, you need to support the same for slots. > > Then, regarding the current implementation, it is duplicating all the > semantics of traits in the UI, and incompletely because it is not covering > at all complex trait compositions. > > The problem with duplication is that then, if there is a bugz, we may have > to fix it several placez. > The problem with duplication is that then, if there is a bug, we may have > to fix it several places. > Duplication just needs to be avoided like in any other cases. I found that system can provide a single method which will allow correctly implement all visibility features but it will not expose to users trait arithmetics. It should just tell how given method is used by given class. aClass howAreYouUsingThisMethod: aMethod It can return different kind of objects like: - method is not used at all - it is an active method in the class - it is overridden method - method is overridden by package (for package overrides scenario) - method is removed (in trait composition) - method is aliased (in trait composition) It is kind of extended version of #isOverridden method. And can be useful in general. Anyway my question was not about implementation details of trait visibility feature. This feature will be removed and I just wanted to know if there are people who will be disappointed by this. But it seems nobody care. > And the other problem is that Traits already provide a good API to > discover all this things automatically without duplicating any of it: > - localMethods > - methods > - allMethods > > And then you can always ask the origin of a method. > > This API is of course perfectible, but I think it's better to enhance it, > than to duplicate it and work it around. > > On Thu, Oct 11, 2018 at 1:00 AM Gabriel Cotelli <g.cotelli(a)gmail.com> > wrote: > >> And by the way, we really need to name traits with a T in the name? I >> always found this ugly, it makes the trait support look like a hack. >> > > I don't think so :). It's just a name convention. >

Oct. 11, 2018

Re: [Pharo-dev] Laucher cannot start a fresh 7 image

by Esteban A. Maringolo

I reported this a week or so ago, same issue. On 11/10/2018 03:09, phil(a)highoctane.be wrote: > Used to work. Then does not anymore. > > Phil -- Esteban A. Maringolo

Oct. 11, 2018

Byte ordering in Form (urgent)

by Eliot Miranda

Hi All, in trying to fix a bug in BitBLT to do with accessing a word following a bitmap I have had to understand Form and BitBlt's extensions for handling multiple byte order. In particular, if a Form has a negative depth its byte ordering is reversed w.r.t. a Form with positive depth. But in examining this code I think I have found an inconsistency, and I urgently need to check my understanding. In the Form and BitBlt code, a negative depth is stated to mean a Form whose bits are in little-endian byte order: *Form methods for accessing* *depth* ^ depth < 0 ifTrue:[0-depth] ifFalse:[depth] *nativeDepth* "Return the 'native' depth of the receiver, e.g., including the endianess" ^depth *Form methods for testing* *isBigEndian* "Return true if the receiver contains big endian pixels, meaning the left-most pixel is stored in the most significant bits of a word." ^depth > 0 *isLittleEndian* "Return true if the receiver contains little endian pixels, meaning the left-most pixel is stored in the least significant bits of a word." ^depth < 0 and BitBltSimulation (the Smalltalk code for the plugin that implements BitBlt) has two instance variables destMSW and sourceMSW that are true if the destination form or source form has a positive depth: *BitBltSimulation methods for interpreter interface* *loadBitBltDestForm* "Load the dest form for BitBlt. Answer false if anything is wrong, true otherwise." ... destDepth := interpreterProxy fetchInteger: FormDepthIndex ofObject: destForm. destMSB := destDepth > 0. destDepth < 0 ifTrue: [destDepth := 0 - destDepth]. ... *loadBitBltSourceForm* "Load the source form for BitBlt. Return false if anything is wrong, true otherwise." ... sourceDepth := interpreterProxy fetchInteger: FormDepthIndex ofObject: sourceForm. sourceMSB := sourceDepth > 0. sourceDepth < 0 ifTrue: [sourceDepth := 0 - sourceDepth]. ... But if I have a look at the actual layout of bytes in a Form I see that the meaning of depth is that if it is positive it is the *native* byte order (little endian on x86, x86-64, ARM, big end on SPARC, PowerPC): Display fill: (0@0 extent: 1@100) rule: Form over fillColor: Color black. (Display bits at: 1) hex '16rFF000001' | bytes | bytes := Display bits copy. ByteArray adoptInstance: bytes. bytes copyFrom: 1 to: 4 #[1 0 0 255] i.e. the first word of the Display after writing the color black into the first 32-bit pixel is 16rFF000001 on Mac OS x86-64, or #[1 0 0 255] , which is little endian. When the Squeak BttF VM was first written it was written on Motorola 68k Macs and PowerPC Macs, which are big-endian. So it is natural that at the time the terms isBigEndian and isLittleEndian and destMSB sourceMSB were as they are now, because the platform was big endian. But subsequently when the code was ported to Windows x86 by Andreas Raab, the meaning seems to me to have changed. Now depth > 0 implies *native* byte order, not big endian byte order, and depth < 0 implies the *opposite of native* byte order, not little endian order. Does anyone disagree? Does anyone have corroborating or contradicting evidence? I ask because to make sense of the code I would at least like to change the variables in BitBltSimulation to be destNativeByteOrder and sourceNativeByteOrder, and I want to either delete Form>>isBigEndian and Form>>isLittleEndian and replace it with Form>>isNativeByteOrder, or redefine isBigEndian and isLittleEndian, eg as *isBigEndian* "Return true if the receiver contains big endian pixels, meaning the left-most pixel is stored in the most significant bits of a word." ^depth > 0 == Smalltalk isBigEndian _,,,^..^,,,_ best, Eliot

Oct. 11, 2018

Re: [Pharo-dev] GitHub Topics

by Sean P. DeNigris

Stephane Ducasse-3 wrote > super c00l +1. Tagged all mine. Now one can search in "Pharo" topic for subcategories e.g. "authentication" shows 3 projects. Of course, the ideal is always to have everything in image, but this is really nice to have: 1) almost for free, 2) in a place like GH which is highly visible to the outside world and 3) without needing an image handy (e.g. one could look for a lib on a mobile device) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 11, 2018