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

Best wishes for 2018

by Torsten Bergmann

Only a few days left for 2017. Thanks to all who helped shaping Pharos future. May the lighthouse be with you in 2018 as well: World backgroundImage: (ZnEasy getJpeg: 'https://spotlight.it-notes.ru/wp-content/uploads/2017/08/02c48424be88ee36d5…') layout: #scaled Have fun! Bye T.

Dec. 29, 2017

Re: [Pharo-dev] New Year Wishlist (2018) ?

by Pierce Ng

On Wed, Dec 27, 2017 at 04:41:56PM +0100, Cyril Ferlicot D. wrote: > I also forgot: a real headless :) And real "embeddability". :-) I'll write GUIs with Pascal/Lazarus if I must. Being able to implement domain logic stuff in Pharo embedded into the application will super charge productivity. Pierce

Dec. 29, 2017

Re: [Pharo-dev] PR: Compressed sources inside the object memory

by Denis Kudriashov

2017-12-28 20:02 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > For string searching in source codes it is 1.5s (external sources) vs 3.7s > (in image compressed), for recompilation of the image it was for me 51s vs > 56s. > I expected much better performance than external file. Can it be optimized? I guess that every "aMethod sourceCode" decompresses full section. And it can be easily cached. To measure maximum speed can you check the version with uncompressed inmemory sources? > > -- Pavel > > 2017-12-28 17:10 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> 2017-12-28 17:07 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> Interesting to compare speed of search operation like "find string in >>> sources" >>> >> >> With Calypso you can do it by: >> >> [(ClyMethodSources withString: 'example' from: ClyNavigationEnvironment >> currentImageScope ) execute] timeToRun >> >> >> >>> >>> 2017-12-28 16:21 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> >>>> >>>> >>>> 2017-12-28 16:00 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>> >>>>> Nice. >>>>> >>>>> 2017-12-28 15:50 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>>> >>>>>> Hi, >>>>>> >>>>>> when the Pharo 7 image is being built on top of the bootstrapped >>>>>> image, all loaded code is placed in the changes file so this process ends >>>>>> with an empty sources file, huge changes file and the image. We condense >>>>>> the sources file for every build so we distribute the Pharo 7 as >>>>>> three files - image, huge sources (over 30 MB) and almost empty changes >>>>>> file. >>>>>> As consequence every build has own sources file that can be shared >>>>>> between images based on the same build - so when we will release the >>>>>> Pharo 7, the sources file can be shared as it was for previous >>>>>> releases, but as soon as some fixing version of Pharo 7 will be >>>>>> released, it will require a new specific sources file. >>>>>> >>>>>> As one possible solution I tried to create a pull request that >>>>>> resurrects from oblivion an old code made for Squeak 3.7 that introduced >>>>>> option of compressed sources files. Such files use segments that are stored >>>>>> in compressed form so it is not so small as one single zip file but still >>>>>> good enough. From original uncompressed file of size 30.8 MB it generates >>>>>> 7.1 MB file while single zip has 6.1 MB. >>>>>> >>>>>> Of course the image file is bigger but: >>>>>> - the amount of new objects is low so it should not make much more >>>>>> stress on GC >>>>>> >>>>> >>>>> And how many objects it adds? (how many sections are compressed?) >>>>> >>>> >>>> It uses currently 1619 segments of size 20000 bytes but that does not >>>> mean that such amount of objects is needed because in the memory filesystem >>>> all the (compressed) data are in single ByteArray and the stream class uses >>>> a very simple segments table - one big array of 1619 integer items that >>>> contain indexes to the ByteArray. >>>> >>>> >>>>> >>>>>> - we already used to have big images because the condenser was not >>>>>> working and it was not a big issue >>>>>> - the amount of distributed files will be the same as in case of >>>>>> Pharo 6 (image+changes) so it means less troubles >>>>>> - the sources file can be easily restored, deleted from the object >>>>>> memory and used the same way as before >>>>>> - we are not using the nice concept of the image well enough. All >>>>>> data that are not really shared between images or serve as backup >>>>>> information should be stored inside image >>>>>> >>>>> >>>>> Can we avoid empty changes file? We can create it on demand (when user >>>>> modifies code for example). >>>>> >>>> >>>> I think we can because it contains only do-its. We should be able to >>>> simply delete it and only modify the image start-up do do not require it. >>>> >>>> -- Pavel >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> Please review this PR. As a side effect it makes the sources file >>>>>> mechanism (but not changes file) independent on the FileStream >>>>>> classes that are deprecated. >>>>>> >>>>>> PR: https://github.com/pharo-project/pharo/pull/631 >>>>>> >>>>>> The pre-built image: >>>>>> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20 >>>>>> pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSucc >>>>>> essfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip >>>>>> >>>>>> Cheers, >>>>>> -- Pavel >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >

Dec. 28, 2017

Re: [Pharo-dev] Streaming over a UTF-8 encoded file using upToAll:

by Henrik-Nergaard

Hi, #upTo: works fine. 'test' asFileReference readStreamDo: [ :stream | stream converter: UTF8TextConverter new; upTo: $e ]. "'Ã'" It looks like PositionableStream>>#upToAll: assumes a 1 to 1 map per item, and only takes the difference between current position up to the pattern when found. Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 28, 2017

Re: [Pharo-dev] PR: Compressed sources inside the object memory

by Pavel Krivanek

For string searching in source codes it is 1.5s (external sources) vs 3.7s (in image compressed), for recompilation of the image it was for me 51s vs 56s. -- Pavel 2017-12-28 17:10 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2017-12-28 17:07 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> Interesting to compare speed of search operation like "find string in >> sources" >> > > With Calypso you can do it by: > > [(ClyMethodSources withString: 'example' from: ClyNavigationEnvironment > currentImageScope ) execute] timeToRun > > > >> >> 2017-12-28 16:21 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> >>> >>> >>> 2017-12-28 16:00 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>>> Nice. >>>> >>>> 2017-12-28 15:50 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>> >>>>> Hi, >>>>> >>>>> when the Pharo 7 image is being built on top of the bootstrapped >>>>> image, all loaded code is placed in the changes file so this process ends >>>>> with an empty sources file, huge changes file and the image. We condense >>>>> the sources file for every build so we distribute the Pharo 7 as >>>>> three files - image, huge sources (over 30 MB) and almost empty changes >>>>> file. >>>>> As consequence every build has own sources file that can be shared >>>>> between images based on the same build - so when we will release the >>>>> Pharo 7, the sources file can be shared as it was for previous >>>>> releases, but as soon as some fixing version of Pharo 7 will be >>>>> released, it will require a new specific sources file. >>>>> >>>>> As one possible solution I tried to create a pull request that >>>>> resurrects from oblivion an old code made for Squeak 3.7 that introduced >>>>> option of compressed sources files. Such files use segments that are stored >>>>> in compressed form so it is not so small as one single zip file but still >>>>> good enough. From original uncompressed file of size 30.8 MB it generates >>>>> 7.1 MB file while single zip has 6.1 MB. >>>>> >>>>> Of course the image file is bigger but: >>>>> - the amount of new objects is low so it should not make much more >>>>> stress on GC >>>>> >>>> >>>> And how many objects it adds? (how many sections are compressed?) >>>> >>> >>> It uses currently 1619 segments of size 20000 bytes but that does not >>> mean that such amount of objects is needed because in the memory filesystem >>> all the (compressed) data are in single ByteArray and the stream class uses >>> a very simple segments table - one big array of 1619 integer items that >>> contain indexes to the ByteArray. >>> >>> >>>> >>>>> - we already used to have big images because the condenser was not >>>>> working and it was not a big issue >>>>> - the amount of distributed files will be the same as in case of Pharo >>>>> 6 (image+changes) so it means less troubles >>>>> - the sources file can be easily restored, deleted from the object >>>>> memory and used the same way as before >>>>> - we are not using the nice concept of the image well enough. All data >>>>> that are not really shared between images or serve as backup information >>>>> should be stored inside image >>>>> >>>> >>>> Can we avoid empty changes file? We can create it on demand (when user >>>> modifies code for example). >>>> >>> >>> I think we can because it contains only do-its. We should be able to >>> simply delete it and only modify the image start-up do do not require it. >>> >>> -- Pavel >>> >>> >>>> >>>> >>>>> >>>>> Please review this PR. As a side effect it makes the sources file >>>>> mechanism (but not changes file) independent on the FileStream >>>>> classes that are deprecated. >>>>> >>>>> PR: https://github.com/pharo-project/pharo/pull/631 >>>>> >>>>> The pre-built image: >>>>> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20 >>>>> pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSucc >>>>> essfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip >>>>> >>>>> Cheers, >>>>> -- Pavel >>>>> >>>>> >>>>> >>>> >>>> >>> >> >

Dec. 28, 2017

Streaming over a UTF-8 encoded file using upToAll:

by Bernhard Pieber

Hi all, I want to stream over a file which is encoded in UTF-8 and have a problem with upToAll: answering more than it should. Here is a minimal test: 'Ãe' readStream upToAll: 'e'. This answers 'Ã' as expected. I wrote those two characters to a file: FileStream forceNewFileNamed: 'test' do: [ :stream | stream nextPutAll: 'Ãe' ]. I opened it using a text editor to verify the encoding. It is UTF-8 as expected. Now if I do the following... 'test' asFileReference readStreamDo: [ :stream | stream upToAll: 'e' ]. ... I get 'Ãe' instead of just 'Ã'. I tried explicitly setting a UTF8TextConverter: 'test' asFileReference readStreamDo: [ :stream | stream converter: UTF8TextConverter new; upToAll: 'e' ]. However, the result is still 'Ãe'. If I read the entire file first using #contentsOfEntireFile first it works: ('test' asFileReference readStreamDo: [ :stream | stream contentsOfEntireFile ]) readStream upToAll: 'e' However, that defies the purpose of streaming. Can someone tell me what I am doing wrong? I am on Pharo 6.1 on a Mac. Bernhard

Dec. 28, 2017

Re: [Pharo-dev] Simple game framework

by ClÃ©ment Bera

On Thu, Dec 28, 2017 at 4:39 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > What is the reason using Cairo over SDSL? Is not SDL just enought? My understanding is that SDL provides the surface to draw on as part of the window, but not a 2D vector graphic engine on top. You've got only draw Line/Rect/pixel functions in SDL. To render a svg/png/jpeg that you want for games on the SDL surface, the normal way is to use a third party library such as Cairo. For 3D I believe people use SDL combined with open GL or direct3D instead of Cairo but I don't know the details. For events (keyboard, mouse, joypad) I use SDL event management and it works differently on each OS. I wrote in the readMe the different set-ups to make it work on each OS. On Windows and Linux I can use the latest Pharo. On Mac I use old Pharo 5 images. I guess it's possible to use SDL for audio, but it seems there is no code relative to audio in the SDL binding and in OSWindow in Pharo. That's why I did not go that way. I tried multiple things but I successfully run audio code in Pharo only with the openAL binding and .wav file (and even in this case, I had to install external librairies in Mac OS...). Whichever if Cairo stays around or not does not really matter, normally one uses Cairo through Athens or Sparta, abstraction layers on top of 2D graphic engines. I've worked with other 2D engines and the API are always almost the same, so I have no doubt that if Cairo support is dropped we can re-bind Athens/Sparta with another 2D engine (such as engines used by web browsers). > > Hilaire > > > Le 25/12/2017 Ã 19:32, ClÃ©ment Bera a Ã©crit : > >> >> https://github.com/clementbera/wizard-battle-arena >> >> https://github.com/clementbera/SpiderInvasion >> >> Audio has always been a problem to me. I successfully run audio files >> with the open AL binding, but I failed to do so cross-platform. Already >> key-bindings coherent cross platform is difficult. >> >> > -- > Dr. Geo > http://drgeo.eu > > > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Dec. 28, 2017

Re: [Pharo-dev] Calendrical capabilities

by Michael Forster

On Wed, Dec 27, 2017 at 2:38 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Excellent I did not know it. > > Stef > [...] +1 I re-implemented the core Chronos features in PLT-Scheme (Racket) and Common Lisp years ago. For those interested in Chronos--and to save them some time digging--here are some links I kept: http://chronos-st.blogspot.ca/2006/12/chronos-101-points-in-time.html http://chronos-st.blogspot.ca/2007/01/chronos-101-durational-values.html http://chronos-st.blogspot.ca/2007/01/chronos-101-intervals-of-time.html Cheers, Mike

Dec. 28, 2017

Re: [Pharo-dev] PR: Compressed sources inside the object memory

by Hilaire

It is funny, because I have reverse problem: FreeType renders nicely the font but not Athens. The opening of the DrGeo main window instance is done at start up, will this be an issue? I guessed not as opening the window is done from the user start up list, but closing the window opened at start up then opening a new one, the Athens canvas is right. Gush... Now there is issue with the startup, absent from previous P7 image, the issue was then with the missing source file. Le 28/12/2017 Ã 16:55, Pavel Krivanek a Ã©critÂ : > I'm trying this DrGeo image on Linux VM and I have no problems with > Athens but with the FreeType. The image does not start and reports > following bugs: > > FT2Error: Freetype2 primitive failed [error 1][cannot open resource] > FreeTypeFace(FT2Handle)>>primitiveFailed: > FreeTypeFace(FT2Handle)>>primitiveFailed > FreeTypeFace(FT2Face)>>primNewFaceFromFile:index: > FreeTypeFace(FT2Face)>>newFaceFromFile:index: > FreeTypeFace>>create > FreeTypeFace>>validate > FreeTypeFont>>face > > To be able to run it I had to remove the FreeType plugin from the VM > but then I have no Athens error. Try to build this image without > opening of the main DrGeo window. > -- Dr. Geo http://drgeo.eu

Dec. 28, 2017

Re: [Pharo-dev] PR: Compressed sources inside the object memory

by Denis Kudriashov

2017-12-28 17:07 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Interesting to compare speed of search operation like "find string in > sources" > With Calypso you can do it by: [(ClyMethodSources withString: 'example' from: ClyNavigationEnvironment currentImageScope ) execute] timeToRun > > 2017-12-28 16:21 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> >> >> 2017-12-28 16:00 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> Nice. >>> >>> 2017-12-28 15:50 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> >>>> Hi, >>>> >>>> when the Pharo 7 image is being built on top of the bootstrapped >>>> image, all loaded code is placed in the changes file so this process ends >>>> with an empty sources file, huge changes file and the image. We condense >>>> the sources file for every build so we distribute the Pharo 7 as three >>>> files - image, huge sources (over 30 MB) and almost empty changes file. >>>> As consequence every build has own sources file that can be shared >>>> between images based on the same build - so when we will release the >>>> Pharo 7, the sources file can be shared as it was for previous >>>> releases, but as soon as some fixing version of Pharo 7 will be >>>> released, it will require a new specific sources file. >>>> >>>> As one possible solution I tried to create a pull request that >>>> resurrects from oblivion an old code made for Squeak 3.7 that introduced >>>> option of compressed sources files. Such files use segments that are stored >>>> in compressed form so it is not so small as one single zip file but still >>>> good enough. From original uncompressed file of size 30.8 MB it generates >>>> 7.1 MB file while single zip has 6.1 MB. >>>> >>>> Of course the image file is bigger but: >>>> - the amount of new objects is low so it should not make much more >>>> stress on GC >>>> >>> >>> And how many objects it adds? (how many sections are compressed?) >>> >> >> It uses currently 1619 segments of size 20000 bytes but that does not >> mean that such amount of objects is needed because in the memory filesystem >> all the (compressed) data are in single ByteArray and the stream class uses >> a very simple segments table - one big array of 1619 integer items that >> contain indexes to the ByteArray. >> >> >>> >>>> - we already used to have big images because the condenser was not >>>> working and it was not a big issue >>>> - the amount of distributed files will be the same as in case of Pharo >>>> 6 (image+changes) so it means less troubles >>>> - the sources file can be easily restored, deleted from the object >>>> memory and used the same way as before >>>> - we are not using the nice concept of the image well enough. All data >>>> that are not really shared between images or serve as backup information >>>> should be stored inside image >>>> >>> >>> Can we avoid empty changes file? We can create it on demand (when user >>> modifies code for example). >>> >> >> I think we can because it contains only do-its. We should be able to >> simply delete it and only modify the image start-up do do not require it. >> >> -- Pavel >> >> >>> >>> >>>> >>>> Please review this PR. As a side effect it makes the sources file >>>> mechanism (but not changes file) independent on the FileStream classes >>>> that are deprecated. >>>> >>>> PR: https://github.com/pharo-project/pharo/pull/631 >>>> >>>> The pre-built image: >>>> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20 >>>> pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSuccessfulBuild >>>> /artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>>> >>> >>> >> >

Dec. 28, 2017