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

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

by Esteban Lorenzano

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

Esteban's ChangeLog week of 16 January 2017

by estebanlm＠gmail.com

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] PharoSpur32Vm

by Esteban Lorenzano

> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: > Hi, > > I believe they're built from https://github.com/OpenSmalltalk/vm <https://github.com/OpenSmalltalk/vm> using travis and appveyor. On the gitbhub readme there are relevant links. All built artifacts are also kept on bintray for history. > > > > Thank you! no, they arenât :) instead, they are built here: https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm> (README still not updated) Esteban > > > On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > Where are the latest Pharo-spur-vms (32bit) are built? > I don't see them on the build server, only the buildresults at > http://files.pharo.org/vm/pharo-spur32/linux/ <http://files.pharo.org/vm/pharo-spur32/linux/> > > The latest builds on the buildserver are from the last year only. > > nicolai > >

Jan. 23, 2017

Re: [Pharo-dev] What happened to Pharo's Window?

by Esteban Lorenzano

it works for me (couple of bugs around in the examples) in macOS sierra in latest Pharo 6.0 in latest Pharo VM Esteban > On 21 Jan 2017, at 17:42, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > To not forget, OSWindow also does not work anymore. > Ronnie has minheadless 64bit VM that solves the issue with OSWindow. > Would be nice to have it for 32bit too. > > It is great to see how VM is progressing! :) > > Cheers, > Alex > > On 21 January 2017 at 17:35, Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>> wrote: > Hi > > Latest Pharo VM + image (from year 2017, middle of January) changed the way how main window is managed and created (without any announcement). > > Something is really messed up, because I can not create an OpenGL context. > > OpenGL context created with default framebuffer: > > <Screen Shot 2017-01-21 at 17.27.49.png> > > If I create a headless context than screen just freezes until I resize (after resize it recreates context making it current). > Also, window is a black (or sometimes white) when launching pharo until I click. > > It definitely looks like Pharo window plays with OpenGL, probably it tries to render morphic in a GL texture and then display it with acceleration: scaled pharo world became sharper on retina and strange lines after dragged window are in the past. Also, rendering performance on retina is dramatically improved. > > All those improvements are great, but please make GL context current (glXMakeCurrent) every frame. Thanks! >

Jan. 23, 2017

Re: [Pharo-dev] AioPlugin not present

by David T. Lewis

On Sun, Jan 22, 2017 at 05:00:04PM +0100, Thierry Goubier wrote: > > Le 22/01/2017 ? 15:50, Davide Varvello via Pharo-dev a ?crit : > >Hi Thierry, > > > >I need it for the OSProcess. When my code calls OSProcess the warning > >(http://imgur.com/a/9jhMy) appears. > > > >It happens only once. If I close the warning window It does not happen > >again, but of course if I restart the image it appears once again, so I > >have > >to find a way to include it or another workaround > > > >Cheers > >Davide > > Hi Davide, > > I do use OSProcess in some cases; last time, I just rewrote that part to > emit a notification (and not raise a popup). > > Regards, > > Thierry I am not sure why the AIOPlugin is not being included in the VMs. Whatever the reason for that, the notifier about the missing plugin was too annoying, so I got rid of it in the latest OSProcess update: Name: OSProcess-Base-dtl.56 Time: 17 January 2017, 8:47:36.321587 am OSProcess 4.6.7 Add nil checks in #shutDown: to prevent failures when exiting existing image with a VM that does not include OSPP (e.g. SqueakJS). For AIO event hander, if the AIO plugin is not present, write an error to console rather than interrupting the image with a notifer. Reduces the annoyance level if VM provider provides OSPP but neglects to include the AIO plugin. Dave

Jan. 22, 2017

Re: [Pharo-dev] About more precise default exception?

by ClÃ©ment Bera

I agree this exception should be more specific. By the way one needs to update all the primitive mutating objects, such as at:put:, so that when it fails because it attempts to mutate a read-only object a proper error is raised instead of SubscriptOutOfBounds with an in-bound index. Maybe an intern can create a specific error for your case, add an error for read-only object and write / update tests for everything. On Sun, Jan 22, 2017 at 6:28 PM, stepharong <stepharong(a)free.fr> wrote: > When I read that, I thought that errorNotIndexable would raise an > Exception different from Error. > But this is not the case and it means that people should write not so good > tests by checking Error > instead of a concrete Exception. > > [[[ > MyExampleSetTest >> testIllegal > self should: [ empty at: 5 ] raise: Error. > self should: [ empty at: 5 put: #zork ] raise: Error > ]]] > We even have a rule that states that we should not catch on Error > > > at: index > "Primitive. Assumes receiver is indexable. Answer the value of an > indexable element in the receiver. Fail if the argument index is > not an > Integer or is out of bounds. Essential. See Object documentation > whatIsAPrimitive. Read the class comment for a discussion about > that the fact > that the index can be a float." > > <primitive: 60> > index isInteger ifTrue: > [self class isVariable > ifTrue: [self errorSubscriptBounds: index] > ifFalse: [self errorNotIndexable]]. > index isNumber > ifTrue: [^self at: index asInteger] > ifFalse: [self errorNonIntegerIndex] > > thoughts comments? > >

Jan. 22, 2017

About more precise default exception?

by stepharong

When I read that, I thought that errorNotIndexable would raise an Exception different from Error. But this is not the case and it means that people should write not so good tests by checking Error instead of a concrete Exception. [[[ MyExampleSetTest >> testIllegal self should: [ empty at: 5 ] raise: Error. self should: [ empty at: 5 put: #zork ] raise: Error ]]] We even have a rule that states that we should not catch on Error at: index "Primitive. Assumes receiver is indexable. Answer the value of an indexable element in the receiver. Fail if the argument index is not an Integer or is out of bounds. Essential. See Object documentation whatIsAPrimitive. Read the class comment for a discussion about that the fact that the index can be a float." <primitive: 60> index isInteger ifTrue: [self class isVariable ifTrue: [self errorSubscriptBounds: index] ifFalse: [self errorNotIndexable]]. index isNumber ifTrue: [^self at: index asInteger] ifFalse: [self errorNonIntegerIndex] thoughts comments?

Jan. 22, 2017

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

by Sven Van Caekenberghe

Great work, can't wait for the HTML version (to link to when answering questions). Thank you ! > On 22 Jan 2017, at 16:53, 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. 22, 2017

Re: [Pharo-dev] AioPlugin not present

by Thierry Goubier

Hi Davide, I do use OSProcess in some cases; last time, I just rewrote that part to emit a notification (and not raise a popup). Regards, Thierry Le 22/01/2017 Ã 15:50, Davide Varvello via Pharo-dev a Ã©crit : > Hi Thierry, > > I need it for the OSProcess. When my code calls OSProcess the warning > (http://imgur.com/a/9jhMy) appears. > > It happens only once. If I close the warning window It does not happen > again, but of course if I restart the image it appears once again, so I have > to find a way to include it or another workaround > > Cheers > Davide

Jan. 22, 2017

Pharo by Example 50 released!

by stepharong

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. 22, 2017