- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Testers Required] New FreeType implementation using FFI

by tesonep＠gmail.com

Cool, thanks a lot. On Fri, Mar 30, 2018 at 4:06 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > On Friday 30 March 2018 06:12 PM, tesonep(a)gmail.com wrote: > > 32 bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p >> ull%20request%20and%20branch%20Pipeline/view/change- >> requests/job/PR-1142/lastSuccessfulBuild/artifact/bootstrap- >> cache/Pharo7.0-32bit-b8d360a.zip >> > > 64 bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p >> ull%20request%20and%20branch%20Pipeline/view/change- >> requests/job/PR-1142/lastSuccessfulBuild/artifact/bootstrap- >> cache/Pharo7.0-64bit-b8d360a.zip >> > > Did a quick check by bringing up the image and running text related tests > in Test runner. All tests ran with 0 failures. > > Tested with get.pharo.org/vm70 (32-bit) and get.pharo.org/64/vm70 > (64-bit) on Ubuntu 16.04 > > HTH .. Subbu > > -- Pablo Tesone. tesonep(a)gmail.com

March 30, 2018

Re: [Pharo-dev] [Testers Required] New FreeType implementation using FFI

by K K Subbu

On Friday 30 March 2018 06:12 PM, tesonep(a)gmail.com wrote: > 32 bits: > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > 64 bits: > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… Did a quick check by bringing up the image and running text related tests in Test runner. All tests ran with 0 failures. Tested with get.pharo.org/vm70 (32-bit) and get.pharo.org/64/vm70 (64-bit) on Ubuntu 16.04 HTH .. Subbu

March 30, 2018

Why is FileSystem's Path class private ?

by Damien Pollet

The class Path from FileSystem is documented as privateâ¦ but it should be public, shouldn't it? First hint is that it's named with a public name: (Path not FileSystemPath). Then, consider the following use-case : if you have a file name in some config file (.ini, .tomlâ¦) then that's really a Path, not a resolved FileReference. I'm not talking about RelativePath and AbsolutePath, those can be hidden away since Path provides the factory and DSL methods. IMHO they should still be renamed to a more private name. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

March 30, 2018

Re: [Pharo-dev] [Testers Required] New FreeType implementation using FFI

by tesonep＠gmail.com

Thanks a lot. On Fri, Mar 30, 2018 at 2:55 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Le 30/03/2018 Ã 14:42, tesonep(a)gmail.com a Ã©crit : > > I have implemented the backend of FreeType using only FFI calls. > > So the whole implementation is in the image side, the current plugin has > > a lot of problems handling the release of the pointers. The new > > implementation is using the mechanism that is already present in UFFI to > > release the Heap pointers, so it should be more stable and easier to > > modify if there is an issue. > > > > The FT2Plugin is not used anymore in this version. > > > > I have tested it in the different platforms, but beside OSX I have only > > made a smoke test. I need some users to try it, so I ask you if you can > > test in different installations. > > > > The image can be downloaded from the CI > > > > 32 > > bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test% > 20pending%20pull%20request%20and%20branch%20Pipeline/ > view/change-requests/job/PR-1142/lastSuccessfulBuild/ > artifact/bootstrap-cache/Pharo7.0-32bit-b8d360a.zip > > > > 64 > > bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test% > 20pending%20pull%20request%20and%20branch%20Pipeline/ > view/change-requests/job/PR-1142/lastSuccessfulBuild/ > artifact/bootstrap-cache/Pharo7.0-64bit-b8d360a.zip > > > > Thanks to all!! > > Cheers. > > > > -- > > Pablo Tesone. > > tesonep(a)gmail.com <mailto:tesonep@gmail.com> > > Hi! > > 32bits version tested on Windows 7. > > Seems to work fine with a fast test. > > -- > Cyril Ferlicot > https://ferlicot.fr > > -- Pablo Tesone. tesonep(a)gmail.com

March 30, 2018

Re: [Pharo-dev] [Testers Required] New FreeType implementation using FFI

by Cyril Ferlicot D.

Le 30/03/2018 Ã 14:42, tesonep(a)gmail.com a Ã©critÂ : > I have implemented the backend of FreeType using only FFI calls.Â > So the whole implementation is in the image side, the current plugin has > a lot of problems handling the release of the pointers. The new > implementation is using the mechanism that is already present in UFFI to > release the Heap pointers, so it should be more stable and easier to > modify if there is an issue.Â > > The FT2Plugin is not used anymore in this version. > > I have tested it in the different platforms, but beside OSX I have only > made a smoke test. I need some users to try it, so I ask you if you can > test in different installations. > > The image can be downloaded from the CI > > 32 > bits:Â https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > 64 > bits:Â https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > Thanks to all!! > Cheers. > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com> Hi! 32bits version tested on Windows 7. Seems to work fine with a fast test. -- Cyril Ferlicot https://ferlicot.fr

March 30, 2018

[Testers Required] New FreeType implementation using FFI

by tesonep＠gmail.com

I have implemented the backend of FreeType using only FFI calls. So the whole implementation is in the image side, the current plugin has a lot of problems handling the release of the pointers. The new implementation is using the mechanism that is already present in UFFI to release the Heap pointers, so it should be more stable and easier to modify if there is an issue. The FT2Plugin is not used anymore in this version. I have tested it in the different platforms, but beside OSX I have only made a smoke test. I need some users to try it, so I ask you if you can test in different installations. The image can be downloaded from the CI 32 bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… 64 bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… Thanks to all!! Cheers. -- Pablo Tesone. tesonep(a)gmail.com

March 30, 2018

Strange deprecation of SystemVersion

by Stephane Ducasse

Hi I do not really understand why fromShortVErsionString: and friends have been deprecated (that part I can understand) but why do they depend on an extension packaged in tests. Stef

March 30, 2018

[Pharo 7.0-dev] Build #742: 21653-ShiftClassInstaller-gives-error-when-changing-superclass-to-new-one-with-variables

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #742 was: SUCCESS. The Pull Request #1163 was integrated: "21653-ShiftClassInstaller-gives-error-when-changing-superclass-to-new-one-with-variables" Pull request url: https://github.com/pharo-project/pharo/pull/1163 Issue Url: https://pharo.fogbugz.com/f/cases/21653 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 30, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Martin McClure

Thanks, Guille! I can confirm that my load once again initializes properly. -Martin On 03/29/2018 12:48 AM, Guillermo Polito wrote: > PR:Â https://github.com/pharo-project/pharo/pull/1161 > > I added a test to avoid this problem in the future. > > Guille >

March 29, 2018

Re: [Pharo-dev] Writing into stream from another stream

by Denis Kudriashov

Hi Nicolas 2018-03-29 17:44 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > There are two different questions: > - expressiveness > - efficiency > > Real efficiency of transfer (without any intermediate copy) is only > guaranteed in very rare cases > (if the target collection of write stream is same species as source > collection of read stream, and there are no transform in any of the > intermediate wrapper streams, then a direct bulk transfer of the form > targetCollection replaceFrom:to:with: sourceCollection startingAt: is > possible) > I'm not at all convinced that we should focus too much on such > optimization. > > The fact that we have at least two choices, let the readStream drive the > operation, or let the writeStream do it, is a smell. > It sounds like we could provide the two: > aReadStream writeContentsTo: aWriteStream. > aWriteStream readContentsFrom: aReadStream. > ... and then let the programmer decide (maybe there is a more optimal > path). > ... or provide a way to negotiate the transfer (size of chunked buffers, > etc...) > I like this idea. > > Unless there is a more symetrical solution. > It's a long time since I did not check Xtreams, but wasn't there a reified > Buffer that could/would be the effective actor of such transfer? > Xtreams provides nice API to "pipe" multiple streams. But as I remember the Buffer was internal detail hidden from your. Idea was to reuse internal stream arrays to minimize garbage (or something like this). > > > Nicolas > > > 2018-03-29 15:02 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> 2018-03-29 14:40 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> >>> >>> > On 29 Mar 2018, at 14:34, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> > >>> > >>> > 2018-03-29 11:45 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> > ZnUtils class>>#streamFrom:to: ? >>> > >>> > Yes, it gives feature which I want. But it's too Java style. >>> > What you think to move it to stream itself? And with what message name? >>> >>> This was written in a specific context, to be efficient. I don't know if >>> it is general enough for broad use. Yes it could be more OO to not make it >>> a utility method, but on the other hand, where would you put it ? >> >> >> In read streams we already have: >> >> >> readInto: aCollection startingAt: startIndex count: n >> >> >> So I would put new method in ReadStream (#readIntoStream: ?). >> >> >>> I am hesitant to make the Stream API bigger ;-) >>> >> >> We already have this method in Utils class. So it is here but in strange >> hidden place. >> >> >>> > > On 29 Mar 2018, at 11:22, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> > > >>> > > Hi. >>> > > >>> > > Do we have simple method to write data between streams? >>> > > >>> > > I want something like: >>> > > >>> > > writeStream nextPutAllFrom: readStream >>> > > >>> > > I always used loop for this. But maybe we have something suitable. >>> Otherwise lets introduce it. >>> > > >>> > > Best regards, >>> > > Denis >>> > >>> > >>> > >>> >>> >>> >> >

March 29, 2018