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

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

by Tudor Girba

Great. This is a great entry point into Pharo. Please publicize it as widely as you can. Here is the announcement tweet that you can retweet: https://twitter.com/stephaneducasse/status/823195882770284545 Cheers, Doru > On Jan 22, 2017, at 4: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 > -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Jan. 23, 2017

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

by Guillermo Polito

Yeh, thanks to all who made an effort :) On Sun, Jan 22, 2017 at 5:10 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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. 23, 2017

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

by Guillermo Polito

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

[pharo-project/pharo-core]

by GitHub

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

Jan. 23, 2017

[pharo-project/pharo-core] ada27b: 60349

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: ada27b978600e43ff5942b2a9191ced7ba74a8ff https://github.com/pharo-project/pharo-core/commit/ada27b978600e43ff5942b2a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-23 (Mon, 23 Jan 2017) Changed paths: M ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/symbolic versions/stable_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/versions/versionv3%5F3%5F0_.st M Renraku.package/extension/CompiledMethod/instance/critiques.st M Renraku.package/extension/CompiledMethod/instance/guidedBan_.st M Renraku.package/extension/CompiledMethod/instance/nodeCritiques.st A Renraku.package/extension/CompiledMethod/instance/reBanName.st M Renraku.package/extension/Object/instance/gtInspectorEProportiesIn_.st M Renraku.package/extension/RBMethodNode/instance/critiques.st A Renraku.package/extension/RPackage/instance/reBanName.st M Renraku.package/extension/TBehavior/instance/critiques.st M Renraku.package/extension/TBehavior/instance/guidedBan_.st A Renraku.package/extension/TBehavior/instance/reBanName.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60348.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60349.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60348.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60349.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60349 19570 QA 3.3.0 https://pharo.fogbugz.com/f/cases/19570 http://files.pharo.org/image/60/60349.zip

Jan. 23, 2017

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

by Pavel Krivanek

2017-01-23 9:51 GMT+01:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > On 23/01/2017 08:57, Esteban Lorenzano wrote: > > it works for me (couple of bugs around in the examples) > > > > in macOS sierra > > in latest Pharo 6.0 > > in latest Pharo VM > > > > Esteban > > > > > > I have a white screen until I click > > macOS ElCaptain > Pharo 6.0 > latest Pharo VM > same here (El Captain 10.11.3) -- Pavel > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Jan. 23, 2017

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

by Esteban Lorenzano

> 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 <mailto:estebanlm@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 <mailto:estebanlm@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 <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 Stephane Ducasse

Tx a lot esteban! This is so great. Showing what you are doing is important. Can you send this mail to the consortium mailing-list too? 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] What happened to Pharo's Window?

by Cyril Ferlicot D.

On 23/01/2017 08:57, Esteban Lorenzano wrote: > it works for me (couple of bugs around in the examples) > > in macOS sierra > in latest Pharo 6.0 > in latest Pharo VM > > Esteban > > I have a white screen until I click macOS ElCaptain Pharo 6.0 latest Pharo VM -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Jan. 23, 2017

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

by Pavel Krivanek

The window display seems to be OK on Fedora and Ubuntu (32-bit) for 60+vmLatest -- Pavel 2017-01-23 8:57 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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> 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