September 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Sept. 12, 2016

[pharo-project/pharo-core] 0e42ac: 60212

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 0e42ac3a57d6f06df9b018af0d536ab362fa703e https://github.com/pharo-project/pharo-core/commit/0e42ac3a57d6f06df9b018af… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-12 (Mon, 12 Sep 2016) Changed paths: A Refactoring-Critics.package/RBPharoBootstrapRule.class/class/accessing/uniqueIdentifierName.st R Refactoring-Critics.package/RBPharoBootstrapRule.class/class/as yet unclassified/isVisible.st A Refactoring-Critics.package/RBPharoBootstrapRule.class/class/testing/isVisible.st A Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/class/accessing/uniqueIdentifierName.st M Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/class/instance creation/new_.st M Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/instance/adding/addSearchStringFrom_in_.st R Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testOnlyReadOrWrittenTemporary.st R Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testTemporaryVariableCapitalization.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60211.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60212.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60211.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60212.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60212 19075 SmallLint tests failing after update https://pharo.fogbugz.com/f/cases/19075 http://files.pharo.org/image/60/60212.zip

Sept. 12, 2016

Integrations in Pharo for next generation VMs: FullBlockClosure, SistaV1 bytecode set and Read-only objects

by ClÃ©ment Bera

Hi everyone, With the help of multiple people (Marcus Denker, Eliot Miranda and some more), I introduced over the past year multiple changes in the Pharo image to support the next generation VMs. It's still a work in progress, but once issue 19083 will be introduced the bulk of the changes will be in the Pharo image. These changes have no impact on developers only reading/writing source code and analysing/working with the ASTs, but may have impact with people working with Opal's IR, the bytecode or directly with the BlockClosure and CompiledMethod instances (People building frameworks like Reflectivity, using OpalCompiler extensions or people working on object serializers). Three main changes were introduced: - Secondary bytecode set support - Read-only objects - FullBlockClosure The secondary bytecode set support allows the image to run on a VM supporting 2 bytecode sets. Each compiled method has a flag precising which set it uses. This change allows the image to convert all the methods from one bytecode set to another one without any bootstrap (only in-image do-its). The SistaV1 bytecode set was introduced as the second bytecode set. This bytecode set removes many encoding limitations of the existing bytecode set, simplifies bytecode decoding and features new instructions (such as full block closure instructions). Read-only objects allows one to mark any object as read-only. Any attempt to mutate a read-only object (primitive operations, instance variable store) fails, and the programmer can handle the failures with Smalltalk code. This feature is present with less than 1% overhead in all of our benchmark suite. In the near future, we plan to have all literals read-only to allow more aggressive compiler optimizations and avoid literal mutation inconsistency bugs. This feature can also be used to build efficient object modification trackers and could be used to improve the performance of part of the Reflectivity framework. It may break your code if you mutate literals (Normally you don't). FullBlockClosures are a new implementation of BlockClosures. They allow efficient implementation of Blocks, with the Copying block and Clean block optimizations present in other Smalltalks. They simplify part of the VM, making Blocks more similar to methods. They also remove many dependencies between BlockClosure, compiled method and contexts, which will allow us to implement more aggressive optimizations in the VM in the future. With FullBlockClosures, the closure's bytecode is present in a separate object (an instance of compiled block) instead of being inlined in the enclosing method. This is still confusing some tools. The debugging support of FullBlockClosure seems however to be complete. With the issue 19083 integrated and the latest VM compiled with different settings than the current Pharo VM (MULTIPLEBYTECODESETS true bytecodeTableInitializer initializeBytecodeTableForSqueakV3PlusClosuresAndSistaV1 -DIMMUTABILITY 1), all these features seems to be working in the Pharo image. The goal is to get all of these features used by default before the Pharo 6 feature freeze in November. Alternatively I will need to wait many more months (or Pharo will get unstable and Esteban will scream at me 'No do not integrate that'). If you worry how any of these changes can impact your frameworks, please answer this thread so we can analyse the potential problems. Regards,

Sept. 12, 2016

Re: [Pharo-dev] [ANN] Sparta v1.0

by Nicolai Hess

2016-09-05 11:50 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Hi > > I am happy to announce the release of Sparta v1.0 for Pharo 5 and Pharo 6. > https://github.com/syrel/Sparta/tree/v1.0 > For a moment only Linux and Mac are supported. > > It can be bootstrapped with the following script: > > Metacello new > baseline: 'Sparta'; > repository: 'github://syrel/sparta:v1.0/src'; > load: #file:core > > > (on linux install 32bit libgtk-2, lingtk-3 and libstdc++) > (script for ubuntu http://ws.stfx.eu/IEAWCUC18BH) > > Sparta is an almost stateless vector graphics API for Pharo that provides > bindings to the Moz2D rendering backend. Moz2D is the extracted graphical > engine from Mozilla Firefox compiled as standalone shared library together > with the extern C bindings required to call the engine from Pharo. > > - developed with the help of Iceberg > <https://github.com/npasserini/iceberg> (thanks!) on Github. > - integrated into travis-ci <https://travis-ci.org/syrel/Sparta> using > smalltalkCI <https://github.com/hpi-swa/smalltalkCI> (great job!). > - documented using Pillar <https://github.com/pillar-markup/pillar> (so > better!) syntax. > > I tried it on linux mint 18 (32 Bit) and executing any moz-example makes the image crashing. I will try to find out what exactly happens or do you have an idea what is missing? > Cheers, > Alex >

Sept. 12, 2016

Re: [Pharo-dev] About file printOn: method

by Eliot Miranda

> On Sep 10, 2016, at 12:28 PM, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > >> On 10/09/16 10:52, stepharo wrote: >> So this is what I was trying to get done. >> I do not know if what you propose (which can be better than what I was >> planning) requires to change fileSystem, my goal was not to change for >> now but just make sure that I can get cheaply file to print themselves >> into kind of objects I can manipulate again. >> >> Now if what you propose is better, then first we should introduce a >> logic to handle :file :memory >> >> And I'm not against so plese push it but this is outside of my little >> goal for now. > You're right. Your solution is much simpler - therefore I'd go with your solution for now. > >> would be nice. Push this idea. Once the community agrees then we can >> easily extend the printOn: behavior. > I'll try to work through the FS code and see if I can get the stuff I'm thinking about implemented. > >> Did you watch the excellent talk of marcus at ESUG? >> Because I think incrementally > One of the first videos/slidedecks I watched - the title made me curious. My key take-away is that it's better to implement the cheap/simple/non-perfect enhancement now than never (too late) the perfect one. "Don't let the perfect be the enemy of the good."

Sept. 11, 2016

Re: [Pharo-dev] Porting TalkFFI / LibClang to Pharo 5 UFFI

by Ben Coman

On Sun, Sep 11, 2016 at 2:07 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Sat, Sep 10, 2016 at 3:14 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> Looks like I've been reinventing the wheel making an FFI interface to libclang. I just bumped into Ciprian's TalkFFI which provides a NativeBoost interface to libclang (and was used to create libgit2 bindings) >> >> * https://rochiamaya.wordpress.com/2013/07/30/create-bindings-with-talkffi/ >> * http://smalltalkhub.com/#!/~CipT/TalkFFI >> * http://smalltalkhub.com/#!/~CipT/LibClang >> >> But it is NativeBoost based and the Configuration loads AsmJit and NativeBoost packages, which seems to lock up while "Initializing Nativeboost." What is involved in porting TalkFFI to Pharo 5.0 UFFI? >> >> For a start, these can be manually load no problem... >> LibClang-FFI-Types-CiprianTeodorov.2 >> LibClang-Tests-CiprianTeodorov.5 >> LibClang-Examples-CiprianTeodorov.2 >> >> but loading LibClang-FFI-Binding-CiprianTeodorov.1 >> reports "This package depends on the following classes: >> CLLibraryMap >> CLExternalLibraryWrapper >> You must resolve these dependencies before you will be able to load these definitions: >> CXIndexH" >> >> which I found these in TalkFFI-Runtime-CiprianTeodorov.7, but loading this >> reports "This package depends on the following classes: >> NBExternalLibraryWrapper >> You must resolve these dependencies before you will be able to load these definitions: >> CLExternalLibraryWrapper >> >> which I see is in Pharo 4.0 and not Pharo 5.0. So what is the replacement for NBExternalLibraryWrapper? >> What are the other general patterns for porting NativeBoost apps to UFFI? >> > > For discussion I've compiled a rough comparison of classes of NativeBoost and UFFI. Quite a bit of guesswork though. Feel free to edit. Probably could be slimmed by removing less significant classes like tests and OS specific classes. > https://docs.google.com/spreadsheets/d/1ZN6GUtzerh7KejODXNtze3njiGAryUUdSvk… > > cheers -ben I've done some additional matching and colour coding. Btw here is how the raw data was generated... |classes| outfile := (FileStream newFileNamed: '/tmp/NB-hierarchy3') lineEndConvention: #lf. classes := Smalltalk allClasses select: [ :c | (c name beginsWith: 'NB') ]. classes addAll: (classes flatCollect: [ :c | c allSuperclasses ]) asSet asOrderedCollection. Object printSubclassesOn: outfile level: 1 filter: classes. outfile close. I needed to add printSubclassesOn:level:filter: as a tweak to the existing printSubclassesOn:level:filter: that I thought might be generally useful, so I attached it to an issue... Extend ClassDescription>>printSubclassesOn:level: to have a filter https://pharo.fogbugz.com/default.asp?19077 cheers -ben

Sept. 11, 2016

Re: [Pharo-dev] PharoJS ESUG 2016 Demo files

by Hilaire

Interesting. Is it modeled as X window? It is what I understood from its description. Hilaire Le 10/09/2016 Ã 22:47, philippe.back(a)highoctane.be a Ã©crit : > But http://blackpagedigital.com/snowglobe/ may be able to. > > Craig told me they did something for a Pharo image at ESUG. > > Phil > -- Dr. Geo http://drgeo.eu

Sept. 11, 2016

Re: [Pharo-dev] linux vm-build

by Esteban Lorenzano

wait Iâm working on the new VM build process justâ¦ wait :) Esteban > On 10 Sep 2016, at 22:32, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > current linux vm build is broken. > > the platform display plugin now expects a ioScreenScaleFactor > function that isn't defined for vm-display-X11 and vm-display-null > and some defines in sq.h had changed > from > DragLeave to SqDragLeave (and the same for all other drag events). > > And maybe more, but fixing the above changes, I was at least able to > build a vm > > nicolai

Sept. 11, 2016

Re: [Pharo-dev] About file printOn: method

by Ben Coman

On Sun, Sep 11, 2016 at 4:37 AM, stepharo <stepharo(a)free.fr> wrote: > o this is what I was trying to get done. > >> I do not know if what you propose (which can be better than what I was >>> planning) requires to change fileSystem, my goal was not to change for >>> now but just make sure that I can get cheaply file to print themselves >>> into kind of objects I can manipulate again. >>> >>> Now if what you propose is better, then first we should introduce a >>> logic to handle :file :memory >>> >>> And I'm not against so plese push it but this is outside of my little >>> goal for now. >>> >> You're right. Your solution is much simpler - therefore I'd go with your >> solution for now. >> >> would be nice. Push this idea. Once the community agrees then we can >>> easily extend the printOn: behavior. >>> >> I'll try to work through the FS code and see if I can get the stuff I'm >> thinking about implemented. >> > Please :) > I like the idea of URI for everything Do you mean a URI represented as a String or as a URI object? I expect the former since ultimately pintOn: is called by printString, but I wanted to be clear? cheers -ben > > >> Did you watch the excellent talk of marcus at ESUG? >>> Because I think incrementally >>> >> One of the first videos/slidedecks I watched - the title made me curious. >> My key take-away is that it's better to implement the >> cheap/simple/non-perfect enhancement now than never (too late) the perfect >> one. >> > > :) > > > > >

Sept. 11, 2016

Re: [Pharo-dev] About Year not knowing exact daysInMonth

by Paul DeBruicker

You could use Month class>>#daysInMonth:forYear: Which I think does what you want already. stepharo wrote > Hi > > I started to write a little utility to generate bills. > > And I need to know the number of days in a month and I was surprised that > > (Month month: 2) daysInMonth returns 28 because we do not know :) > > So I thought that I was obviously wrong and I should use > > (Year year: 2016) daysInMonth > > > "#(31 28 31 30 31 30 31 31 30 31 30 31)" > > :( > > When I look at the implementation this is clear that it is wrong > > daysInMonths > ^ Date daysInMonth > > totally not aware of the year. > > > I think that daysInMonths should use DateAndTime creating a dummy date > for each month and using asMonth daysInMonth > > (DateAndTime > year: 2016 month: 2 day: 3) > asMonth > daysInMonth > > > 29 > > > > Year >> daysInMonth: aMonthNumber > "Returns the days in month for a given month" > > > <expr: #(#(#Year #year: 2016) #daysInMonth: 2) result: 29> > ^ (DateAndTime year: self year month: aMonthNumber) asMonth > daysInMonth > > > I extended the class with some more practical methods. What do you > think? I should push them to pharo? > > I was surprised that the library was not that good. > > Stef -- View this message in context: http://forum.world.st/About-Year-not-knowing-exact-daysInMonth-tp4915092p49… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 10, 2016