January 2017 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60353 Home: https://github.com/pharo-project/pharo-core

Jan. 23, 2017

[pharo-project/pharo-core] 24542a: 60353

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 24542ad3cedacbf19c06fec46ae34d8df5bbac84 https://github.com/pharo-project/pharo-core/commit/24542ad3cedacbf19c06fec4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-23 (Mon, 23 Jan 2017) Changed paths: M BaselineOfIDE.package/BaselineOfIDE.class/instance/actions/additionalInitialization.st M BaselineOfIDE.package/BaselineOfIDE.class/instance/actions/postload_package_.st M BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/baseline_.st A BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/groups_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60352.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60353.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60352.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60353.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60353 19574 update BaselineOfIDE https://pharo.fogbugz.com/f/cases/19574 http://files.pharo.org/image/60/60353.zip

Jan. 23, 2017

Re: [Pharo-dev] AST node replacement API

by John Brant

On 01/23/2017 07:48 AM, Yuriy Tymchuk wrote: > Hi everyone, > > does anyone have a better knowledge about replacing nodes in AST? Because what I saw is that there are methods like replaceSourceWith: that can be sent to an AST node with another AST node as a parameter. But this is not enough to get a new source code. Because when you ask the AST for newSource it generates a new source by taking replacements into account, parses the new source, compares it with itself and in case the new parse tree is equal it returns the new source. So itâs not enough to just use replaceSourceWith: but you also have to replace the current node with a new one it AST. > > Now the question is: am I doing something wrong, or we have strange API because we need to replace both source and node, replacing only one of them does not workâ¦ This code was created so that some refactoring could be performed without having to format the entire parse tree. For example, converting direct variable access to use accessors should be able to rewrite the code without having to reformat. When you perform the replaceWith: on a node or the rewriter performs a node replacement, it calls the replaceMethodSource: method. That method calls the replaceSourceWith: method (replaceSourceWith: is a "private" method). The replaceSourceWith: methods test the source/replacement nodes for certain patterns. If the replacement fits the condition of the pattern, then it adds the appropriate text edit operations that should transform the old source into the new source. If the replaceSourceWith: doesn't recognize what is being done, then it dispatches the replaceSourceFrom: message to the replacement node. Currently, this handles cases were any section of code is being replaced with a variable or literal. Anyway, after all replacements are performed, it gets the new source like you explain. It performs a sanity check on the edited source. If it isn't parse tree equivalent to the rewritten tree, then it assumes that something went wrong in a replaceSourceWith: or replaceSourceFrom: method and uses the formatted code of the rewritten tree instead. John Brant

Jan. 23, 2017

Re: [Pharo-dev] AST node replacement API

by Nicolai Hess

2017-01-23 14:48 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi everyone, > > does anyone have a better knowledge about replacing nodes in AST? Because > what I saw is that there are methods like replaceSourceWith: that can be > sent to an AST node with another AST node as a parameter. But this is not > enough to get a new source code. Because when you ask the AST for newSource > it generates a new source by taking replacements into account, parses the > new source, compares it with itself and in case the new parse tree is equal > it returns the new source. So itâs not enough to just use > replaceSourceWith: but you also have to replace the current node with a new > one it AST. > > Now the question is: am I doing something wrong, or we have strange API > because we need to replace both source and node, replacing only one of them > does not workâ¦ > The API is strange : ) The nodeMapping and replacements are used by the tree rewriter. And the way the treerewriter works, it does not rewrite a AST-Tree but generates a new method by compiling the returned value, and it works on the returned value, the new/reformatted source text, not on a changed AST-Tree. >From the rewriter point of view (and some other parts of RB), the AST is more like a immutable structure. Only since when we started to use the RB-AST for the compiler, we started to use the AST for other purposes (remember when we got into trouble, because some lint rules from critic browser were modifying the AST and we used that modified source as the method source, although the actual method source didn't changed ) > > Uko >

Jan. 23, 2017

Re: [Pharo-dev] Collections and Kernel

by Pavel Krivanek

I do not think that to have the package "Kernel" as the smallest system subset is the good way to go. The minimal system should be a set of well-structured packages so it still makes sense to have packages like Collections-* where some of them are supposed to be mandatory and others optional. So: 1) not in that form 2) Kernel package deserves better modularization but in that case names will be like Kernel-* But of course we should discuss the best approach. Cheers, -- Pavel 2017-01-23 15:36 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hi everyone, > > As I am working on an optimising JIT compiler for the Cog VM written in > Smalltalk and partly running in the Smalltalk runtime, I am very careful > about dependencies. I would like to limit the dependencies of the optimiser > to the Kernel. > > The main problem I have is that there are no collections in the Pharo > Kernel except MethodDictionary and DependentsArray. The optimiser depends > on Array, ByteArray, OrderedCollection, Set and Dictionary which are not > part of the Kernel. > > The second problem is that there are lots of things in the Kernel that the > optimiser do not depend on even though everything is in the Kernel package, > for example, the optimiser does not depend on anything related to > Time/Chronology, on Numbers other than SmallIntegers or Protocol logic. > > This leads to questions. I know that with the bootstrap incoming, some > people have answers to these questions, but I would like to the > conversation happening on the mailing list so everyone can contribute. > > Question 1) Is there any plan to make a 'Kernel-Collection' package, which > includes Array, ByteArray, OrderedCollection, Set and Dictionary, but not > the rest of the collections ? > > Question 2) Is there any plan to split the Kernel (or maybe the Kernel and > all its dependencies ?) into smaller pieces, for example 'KernelCore', > which includes the existing Kernel *but* other Numbers than SmallIntegers, > Protocol logic and Time Chronology, which could be moved to > 'KernelExtended' or something like that ? > > I understand that those problems are not easy, but I would like to know if > there is a generic plan so I can correctly decide on what dependencies I > can have or not. > > Thanks, cheers, >

Jan. 23, 2017

Collections and Kernel

by ClÃ©ment Bera

Hi everyone, As I am working on an optimising JIT compiler for the Cog VM written in Smalltalk and partly running in the Smalltalk runtime, I am very careful about dependencies. I would like to limit the dependencies of the optimiser to the Kernel. The main problem I have is that there are no collections in the Pharo Kernel except MethodDictionary and DependentsArray. The optimiser depends on Array, ByteArray, OrderedCollection, Set and Dictionary which are not part of the Kernel. The second problem is that there are lots of things in the Kernel that the optimiser do not depend on even though everything is in the Kernel package, for example, the optimiser does not depend on anything related to Time/Chronology, on Numbers other than SmallIntegers or Protocol logic. This leads to questions. I know that with the bootstrap incoming, some people have answers to these questions, but I would like to the conversation happening on the mailing list so everyone can contribute. Question 1) Is there any plan to make a 'Kernel-Collection' package, which includes Array, ByteArray, OrderedCollection, Set and Dictionary, but not the rest of the collections ? Question 2) Is there any plan to split the Kernel (or maybe the Kernel and all its dependencies ?) into smaller pieces, for example 'KernelCore', which includes the existing Kernel *but* other Numbers than SmallIntegers, Protocol logic and Time Chronology, which could be moved to 'KernelExtended' or something like that ? I understand that those problems are not easy, but I would like to know if there is a generic plan so I can correctly decide on what dependencies I can have or not. Thanks, cheers,

Jan. 23, 2017

[REMINDER] Pharo TechTalk tomorrow Jan 24 16h UTC

by Esteban Lorenzano

Hello all, This is a reminder for the next TechTalk who will be around Bloc/Brick. Alex, Glenn and/or Doru will be handling thisâ¦ so specific details will come from them, but I suppose it will be more or less like last time: youtube live for presentations, questions/conversation over discord. Links will be sent tomorrow. cheers, Esteban

Jan. 23, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 16 January 2017

by Ben Coman

Thanks Esteban. This is interesting to tune in on whats happening in vm and FFI. cheers -ben On Mon, Jan 23, 2017 at 4:00 PM, <estebanlm(a)gmail.com> wrote: > Hello! > > This is my weekly ChangeLog, from 16 January 2017 to 22 January 2017. > You can see it in a better format by going here: http://log.smallworks.eu > > ChangeLog > ========= > > 20 January 2017: > ---------------- > > * I'm still fixing a couple of final failing tests on iceberg, > multi-remotes branch. Problem is that there are still somethings to > understand > on the "command line > backend" (we need to find a better name for this), and the #pushTo: > method: if I > do it as I > think is correct, a couple of failing tests appear... but then, I need > to > reflect if this is > a problem on the functionality or on the tests. > > 19 January 2017: > ---------------- > > * I think I finally got the problem with FT2Plugin! > Yesterday night talking in slack I realised that there was actually > duplicated > instances of > FT2Handle hierarchy with exactly same handle (pointer address). This, > of > course, causes a double free when those instances are released... and > that's the VM crash :) > So I quickly sketched a workaround, that you can see here: > FT2Handle>>pvtDestroyHandle > "This should only be sent from the finalizer. > It runs inside a mutex because in strange cases it can happen that > this is > executed twice, > causing a primitiveFailed to be raised." > self class destroyMutex critical: [ | handleToRelease | > self isValid ifFalse: [ ^self ]. > handleToRelease := self handle copy. > self primDestroyHandle. > "This is super-ugly, but it will prevent duplicated handles to be > released" > FT2Handle allSubInstancesDo: [ :each | > (handleToRelease = each handle) ifTrue: [ each beNull ] ] ] > and so far nobody who is testing it crashed! > This can be important, but of course... now we need to realise why the > duplicated instances are happening. > * I spent some time preparing a new way to annoy people :) > I prepared a way to send a digest mail about my activity (this stream) > to > pharo-dev list. > I hope it will not be too much. > > 18 January 2017: > ---------------- > > * ... and still some more work on iceberg, this time making some test > pass on the command line backend (who is just a fallback, but well... > we still > need it around). > * Still working on UFFI 64bits. Now I introduced a new hierarchy, > FFIArchitecture > for now with two children: > * FFI_i386 > * FFI_x86_64 > the purpose is obvious: to allow UFFI to handle differences between > different > architectures (for example, > long has to be parsed to FFIInt32 in i386 and to FFIInt64 in x86_64). > > 17 January 2017: > ---------------- > > * I'm working on the UFFI support for 64bits. > In general, it works fine, but there is a huge problem with > structures. What's > this problem? Well, let's take > this simple structure as example: > struct point { > unsigned long x; > unsigned long y; > } > Well, thing is in 32bits sizeof(struct point) = 8 while in 64bits > sizeof(struct > point) = 16, and of > course this breaks our current implementation which would be something > like this > StructPoint>>x > ^ handle unsignedLongAt: 1 > StructPoint>>y > ^ handle unsignedLongAt: 5 > and of course, this is not correct for 64bits. > My solution is quite simple, instead hardcoding the field offsets, I > store those > values into class variables > that can be calculated each session (but just once). > So, this structure would end looking like this: > StructPoint>>x > ^ handle unsignedLongAt: OFFSET_X > StructPoint>>y > ^ handle unsignedLongAt: OFFSET_Y > this would solve the problem for most of the cases, but there is still > the issue > that emerges when complete > implementation of the struct changes between platforms. I'm planning to > implement a strategy pattern to solve > this, but not yet (probably I will wait until having a concrete case). > This seems to be working, but now I have other problems not related to > UFFI: > many people has implemented > void * parameters of funtions as unsigned long (including me, time > ago) which > was correct in 32bits but > it is not in 64bits. So now I need to review this implementations to > see where a > fix is needed. > But this is not directly a problem of UFFI, I think. > * I worked with Nico on fixing libgit2 backend tests for iceberg. > Now (more thanks to Nico than me, heh), test for multi-remotes branch > are > passing for linux but > still not for macOS (and forget it about Pharo 5.0). > I suspect a problem with VM, I need to review if I can configure > smalltalkci > to work with latest vm instead stable. > > 15 January 2017: > ---------------- > > * ... and now I restored the posix permissions to windows platform. Next > latest VM > will have this change, I > hope that will end the problems with FilePlugin, but we'll see. > * I just fixed a problem with FilePlugin on macOS: the problem was when > determining if a symlink is also a > directory: > â/tmpâ asFileReference isDirectory > was answering false, because it is a symlink and when trying to > resolve the > symlink to obtain the > attributes, there was a cyclic condition that was transforming â/tmpâ > into > â/private/tmpâ and then > back to â/tmpâ, and because of that the test for directory was failing. > > cheers! > Esteban > >

Jan. 23, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 16 January 2017

by Dimitris Chloupis

Very good idea Esteban I think I will steal it On Mon, 23 Jan 2017 at 11:38, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I like the "talk to yourself" format :P > > On Mon, Jan 23, 2017 at 10:05 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > On 23 Jan 2017, at 10:02, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > Tx a lot esteban! > This is so great. > > > thanks :) > > Showing what you are doing is important. > Can you send this mail to the consortium mailing-list too? > > > of course, this is a Pharo script after all ;) > > Esteban > > > On Mon, Jan 23, 2017 at 9:22 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > yeah, Iâm aware I need to iterate on the text exporter to have some better > output :P > > Esteban > > > On 23 Jan 2017, at 09:00, estebanlm(a)gmail.com wrote: > > > > Hello! > > > > This is my weekly ChangeLog, from 16 January 2017 to 22 January 2017. > > You can see it in a better format by going here: > http://log.smallworks.eu > > > > ChangeLog > > ========= > > > > 20 January 2017: > > ---------------- > > > > * I'm still fixing a couple of final failing tests on iceberg, > > multi-remotes branch. Problem is that there are still somethings to > understand > > on the "command line > > backend" (we need to find a better name for this), and the #pushTo: > method: if I > > do it as I > > think is correct, a couple of failing tests appear... but then, I > need to > > reflect if this is > > a problem on the functionality or on the tests. > > > > 19 January 2017: > > ---------------- > > > > * I think I finally got the problem with FT2Plugin! > > Yesterday night talking in slack I realised that there was actually > duplicated > > instances of > > FT2Handle hierarchy with exactly same handle (pointer address). > This, of > > course, causes a double free when those instances are released... and > > that's the VM crash :) > > So I quickly sketched a workaround, that you can see here: > > FT2Handle>>pvtDestroyHandle > > "This should only be sent from the finalizer. > > It runs inside a mutex because in strange cases it can happen that > this is > > executed twice, > > causing a primitiveFailed to be raised." > > self class destroyMutex critical: [ | handleToRelease | > > self isValid ifFalse: [ ^self ]. > > handleToRelease := self handle copy. > > self primDestroyHandle. > > "This is super-ugly, but it will prevent duplicated handles to be > released" > > FT2Handle allSubInstancesDo: [ :each | > > (handleToRelease = each handle) ifTrue: [ each beNull ] ] ] > > and so far nobody who is testing it crashed! > > This can be important, but of course... now we need to realise why the > > duplicated instances are happening. > > * I spent some time preparing a new way to annoy people :) > > I prepared a way to send a digest mail about my activity (this > stream) to > > pharo-dev list. > > I hope it will not be too much. > > > > 18 January 2017: > > ---------------- > > > > * ... and still some more work on iceberg, this time making some test > > pass on the command line backend (who is just a fallback, but well... > we still > > need it around). > > * Still working on UFFI 64bits. Now I introduced a new hierarchy, > FFIArchitecture > > for now with two children: > > * FFI_i386 > > * FFI_x86_64 > > the purpose is obvious: to allow UFFI to handle differences between > different > > architectures (for example, > > long has to be parsed to FFIInt32 in i386 and to FFIInt64 in x86_64). > > > > 17 January 2017: > > ---------------- > > > > * I'm working on the UFFI support for 64bits. > > In general, it works fine, but there is a huge problem with > structures. What's > > this problem? Well, let's take > > this simple structure as example: > > struct point { > > unsigned long x; > > unsigned long y; > > } > > Well, thing is in 32bits sizeof(struct point) = 8 while in 64bits > sizeof(struct > > point) = 16, and of > > course this breaks our current implementation which would be > something like this > > StructPoint>>x > > ^ handle unsignedLongAt: 1 > > StructPoint>>y > > ^ handle unsignedLongAt: 5 > > and of course, this is not correct for 64bits. > > My solution is quite simple, instead hardcoding the field offsets, I > store those > > values into class variables > > that can be calculated each session (but just once). > > So, this structure would end looking like this: > > StructPoint>>x > > ^ handle unsignedLongAt: OFFSET_X > > StructPoint>>y > > ^ handle unsignedLongAt: OFFSET_Y > > this would solve the problem for most of the cases, but there is > still the issue > > that emerges when complete > > implementation of the struct changes between platforms. I'm planning > to > > implement a strategy pattern to solve > > this, but not yet (probably I will wait until having a concrete case). > > This seems to be working, but now I have other problems not related > to UFFI: > > many people has implemented > > void * parameters of funtions as unsigned long (including me, time > ago) which > > was correct in 32bits but > > it is not in 64bits. So now I need to review this implementations to > see where a > > fix is needed. > > But this is not directly a problem of UFFI, I think. > > * I worked with Nico on fixing libgit2 backend tests for iceberg. > > Now (more thanks to Nico than me, heh), test for multi-remotes branch > are > > passing for linux but > > still not for macOS (and forget it about Pharo 5.0). > > I suspect a problem with VM, I need to review if I can configure > smalltalkci > > to work with latest vm instead stable. > > > > 15 January 2017: > > ---------------- > > > > * ... and now I restored the posix permissions to windows platform. > Next latest VM > > will have this change, I > > hope that will end the problems with FilePlugin, but we'll see. > > * I just fixed a problem with FilePlugin on macOS: the problem was when > > determining if a symlink is also a > > directory: > > â/tmpâ asFileReference isDirectory > > was answering false, because it is a symlink and when trying to > resolve the > > symlink to obtain the > > attributes, there was a cyclic condition that was transforming â/tmpâ > into > > â/private/tmpâ and then > > back to â/tmpâ, and because of that the test for directory was > failing. > > > > cheers! > > Esteban > > > > > >

Jan. 23, 2017

Re: [Pharo-dev] Pharo by Example 50 released!

by Ben Coman

Thanks for your great effort guys. cheers -ben On Sun, Jan 22, 2017 at 11:53 PM, stepharong <stepharong(a)free.fr> wrote: > https://pharoweekly.wordpress.com/2017/01/22/pharo-by-example-50-released/ > > Super special thanks to Nicolai Hess that pushed me to do the last steps > to release. > Thanks Nicolai your steady commits pushed me! > > Stef > >

Jan. 23, 2017