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

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

by Stephane Ducasse

Thanks for the submission we will check. On Sun, Dec 31, 2017 at 4:26 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > Hi Henrik, > > Thanks for the fix. I just saw it today. In the meantime I have created a pull request with another fix. To be honest, I have just taken the working implementation from Squeak: > https://github.com/pharo-project/pharo/pull/632 > > Alas, the CI check failed for some reason I don't understand. :-/ > > Happy New Year! > Bernhard > >> Am 30.12.2017 um 13:32 schrieb Henrik-Nergaard <draagren(a)outlook.com>: >> >> Here is a fix. >> >> ------------------------------------ >> PositionableStream>>#upToAll: aCollection >> "Answer a subcollection from the current access position to the occurrence >> (if any, but not inclusive) of aCollection. If aCollection is not in the >> stream, answer the entire rest of the stream." >> >> | output pattern | >> >> aCollection ifEmpty: [ ^ collection species empty ]. >> >> output := (collection species new: 100) writeStream. >> pattern := aCollection readStream. >> >> [ pattern atEnd ] whileFalse: [ | item | >> self atEnd ifTrue: [ >> output next: pattern position putAll: aCollection startingAt: 1. >> ^ output contents >> ]. >> >> item := self next. >> (pattern peekFor: item) ifFalse: [ >> output >> next: pattern position putAll: aCollection startingAt: 1; >> nextPut: item. >> >> pattern reset. >> ]. >> ]. >> >> ^ output contents >> ------------------------------------ >> >> Best regards, >> Henrik > >

Dec. 31, 2017

Re: [Pharo-dev] Best wishes for 2018

by Stephane Ducasse

you too :) On Mon, Jan 1, 2018 at 12:15 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On ven. 29 dÃ©c. 2017 at 09:40, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> 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. >> > Happy new year everyone :) > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France

Dec. 31, 2017

Re: [Pharo-dev] Best wishes for 2018

by Cyril Ferlicot

On ven. 29 dÃ©c. 2017 at 09:40, Torsten Bergmann <astares(a)gmx.de> wrote: > 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. > > Happy new year everyone :) -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 31, 2017

Re: [Pharo-dev] Simple game framework

by Stephane Ducasse

Hi hilaire Some students at Prague are working on different 2D games with Bloc and this is working. Some did a sokoban, other a miner (check on pharo weekly). They use Bloc and I will ask them to make public their code. No need for SDL. SDL is ***low level***. Now modeling the board and proposing some abstractions that can be easily extended is difficult. and this is what lauraMaximilliano did in MetaBorg. It was on my todo to do a pass. I implemented a grid to help the design of board game. Now having direction/location can be good. What is interesting in the design of metaborg is that we do not test if an object can move to a place. We go to the place and the place pull the item. A wall will not pull for example while a empty slot will pull the item to move. I found it intriguing and I would like to know if this is working for more complex situation. Maximiliano implemented sokoban, tetris, snake, pacman with the same framwork. Now it is a bit abstract but an interesting experience. Stef On Sun, Dec 31, 2017 at 2:41 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > I am *exploring* if Pharo will be suitable to have a simple programming > environment to let kids write simple 2D games, SDL was designed for that. > > Some of my students asked me about programming games, Smalltalk way of > writing code will be neat, but the environment need to be accessible and not > over engineered. > > > Le 30/12/2017 Ã 22:32, Stephane Ducasse a Ã©crit : >> >> What kind of game are you targeting? Did you look at Bloc? Because to >> me this is the way to go except if you want just a canvas >> and reimplement your event loop. in that case SDL + Athens should work. > > > -- > Dr. Geo > http://drgeo.eu > > >

Dec. 31, 2017

Re: [Pharo-dev] Best VM for the Mac>

by Stephane Ducasse

Well, do NOT rely on them on Sierra. I can crash such VM while typing code. They have two issues: - typing - freeType I removed the freeType plugin to be able to work on my machine but this is clearly not a solution. Now crashing every 20 min when typing code is not something that we can claim is production ready. And this is both for 6.1 and 7.0 Stef On Sun, Dec 31, 2017 at 4:02 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 31 Dec 2017, at 16:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> >>> On 31 Dec 2017, at 15:59, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> yes. >>> and I will promote them to stable this month. >> bah, not this month but january ;) > > ah, maybe is confusing, hehâ¦ yes, usually latest VMs are *not* for production. But this ones have been tested last three months and they work fine so yes, *this ones* can be used for production. > > Esteban > >> >>> >>>> On 31 Dec 2017, at 15:56, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>>> >>>> These are not for production, right? >>>> >>>> Bernhard >>>> >>>>> Am 31.12.2017 um 11:58 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> >>>>> wget -O- get.pharo.org/vmLatest70 | bash >>>>> wget -O- get.pharo.org/64/vmLatest70 | bash >>>>> >>>>> Esteban >>>>> >>>>>> On 31 Dec 2017, at 11:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>>>> >>>>>> Sean P. DeNigris wrote >>>>>>> What is the best VM right now for the Mac? Where/how would one get it? >>>>>> >>>>>> Bump ;) >>>>>> >>>>>> >>>>>> >>>>>> ----- >>>>>> Cheers, >>>>>> Sean >>>>>> -- >>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>> >>>> >>> >> > >

Dec. 31, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Stephane Ducasse

On Sun, Dec 31, 2017 at 12:55 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: >> Hi Bernhard. >> >> The deprecation is still in progress. > > Considering the amount of non-image code using this, I would be interested > to hear how this is going to be supported and documented. Step by step. :) We cannot continue to have so bad streams without taking action. So we start to make sure that Pharo itself does not use the old streams. Then it means that we will be able to have the old stream library as a separate package and people will slowly migrate. Now it would be nice to have a rewrite rule to help but it requires time. Stef

Dec. 31, 2017

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

by Stephane Ducasse

Tx Stephan I have too many dreams :) so I will have to prioritize but let's the first three :). Stef On Sun, Dec 31, 2017 at 12:58 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> Hi everybody, >> >> This looks like a good moment of the year to ask all of you what would >> you want to see in Pharo next year. > > I wish you all the time and good health to realize some of your Pharo > dreams > > Stephan > >

Dec. 31, 2017

Re: [Pharo-dev] [Pharo-users] Best wishes for 2018

by Stephane Ducasse

:) I like this kind of metrics :) I want more of them :) I wish everybody lot of success and business. Stef On Sun, Dec 31, 2017 at 2:18 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > I want to second that. It has been another amazing year for pharo. And I think things have changed significantly. So 2018 should be really great! > I matched my personal not-to-serious goal > > # ps aux | grep pharo | wc -l > 59 > > So I have 59 pharo images in production. Next step will be to exceed 100 in 2018! And yes, Iâm definitely interested in a bootstrapped image ;) > > Thank you all for your amazing work. We are a great community! > > Norbert > > >> Am 29.12.2017 um 09:39 schrieb Torsten Bergmann <astares(a)gmx.de>: >> >> 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. 31, 2017

FreeCell resurrection

by Pavel Krivanek

Hi, I fixed the old FreeCell code from Squeak to be able to run on Pharo 6 and 7. Repository: https://github.com/pavel-krivanek/FreeCell How to load: Metacello new baseline: 'FreeCell'; repository: 'github://pavel-krivanek/FreeCell/src'; load. How to run: FreeCell open. Cheers, -- Pavel

Dec. 31, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Bernhard Pieber

IIUC that means that a stream implementation compatible with the standard streams cannot be implemented on top of the new streams, right? What is the plan about #upToAll:, #match: and similar messages which are very useful for parsing? Where should they go? Bernhard > Am 31.12.2017 um 17:07 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> On 31 Dec 2017, at 16:21, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> >> Hi Sven, >> >> Thanks for the answer. This is exactly what I was looking for. And it is great that there is also documentation. >> >> However, ZnCharacterReadStream does not implement #upToAll:. The implementation from PositionableStream cannot easily be borrowed because there seems to be no way to reset the position. Is there a plan to support the most commonly used messages from the normal streams? > > The Stream API is much too wide, it has to be reduced and split in a number of elementary streams that can be composed to add desired behaviour (like character encoding/decoding, buffering, line end translation, ...). Positioning in a stream (moving backwards without restrictions) is not generally possible (think of a network stream), that is why it is not implemented. > >> Bernhard >> >>> Am 30.12.2017 um 18:03 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… >>> >>> 1.4. Converting Streams >>> >>>> On 30 Dec 2017, at 13:27, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>>> >>>> I just saw that the FileStream hierarchy including MultiByteFileStream is deprecated. However, I can't find what file stream class should be used to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also uses MultiByteFileStream. >>>> >>>> Can someone please point me to the right code? >>>> >>>> Bernhard

Dec. 31, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Sven Van Caekenberghe

> On 31 Dec 2017, at 16:21, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > Hi Sven, > > Thanks for the answer. This is exactly what I was looking for. And it is great that there is also documentation. > > However, ZnCharacterReadStream does not implement #upToAll:. The implementation from PositionableStream cannot easily be borrowed because there seems to be no way to reset the position. Is there a plan to support the most commonly used messages from the normal streams? The Stream API is much too wide, it has to be reduced and split in a number of elementary streams that can be composed to add desired behaviour (like character encoding/decoding, buffering, line end translation, ...). Positioning in a stream (moving backwards without restrictions) is not generally possible (think of a network stream), that is why it is not implemented. > Bernhard > >> Am 30.12.2017 um 18:03 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… >> >> 1.4. Converting Streams >> >>> On 30 Dec 2017, at 13:27, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>> >>> I just saw that the FileStream hierarchy including MultiByteFileStream is deprecated. However, I can't find what file stream class should be used to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also uses MultiByteFileStream. >>> >>> Can someone please point me to the right code? >>> >>> Bernhard > >

Dec. 31, 2017

Re: [Pharo-dev] Pharo 7 crash on Mac

by Bernhard Pieber

Hi Stef, I feel your pain! Especially for the stable version (6.1) this is very unfortunate. I hope the problems are gone with the new VMs Esteban will release. Happy New Year! Bernhard > Am 30.12.2017 um 17:57 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi bernhard > > I can crash pharo 60 and 70 on sierra nearly 3 times per 30 min. > Because of a bad key combination. So I save often > and do not use the arrow keys. :( > We will have to address this super super super annoying problem. > Now may be this is not the same bug. > Guille is currently refactoring, adding many tests to Iceberg internal > representation. > > Stef > > On Sat, Dec 30, 2017 at 11:03 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> Hi, >> >> I wanted to set up a new Pharo 7 image for contributing. I used the description from here: https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >> >> After I had successfully cloned the pharo repository Pharo crashed. I am afraid I cannot remember the last thing I did before the crash. Nevertheless, maybe the crash dump is of some use for someone being able to interpret its content. >> >> I am on macOS Sierra 10.12.6. >> >> ./pharo --version >> 5.0 5.0.201708271955 Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) [Production Spur VM] >> CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 >> VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ >> Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> Happy New Year! >> >> Bernhard

Dec. 31, 2017

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

by Bernhard Pieber

Hi Henrik, Thanks for the fix. I just saw it today. In the meantime I have created a pull request with another fix. To be honest, I have just taken the working implementation from Squeak: https://github.com/pharo-project/pharo/pull/632 Alas, the CI check failed for some reason I don't understand. :-/ Happy New Year! Bernhard > Am 30.12.2017 um 13:32 schrieb Henrik-Nergaard <draagren(a)outlook.com>: > > Here is a fix. > > ------------------------------------ > PositionableStream>>#upToAll: aCollection > "Answer a subcollection from the current access position to the occurrence > (if any, but not inclusive) of aCollection. If aCollection is not in the > stream, answer the entire rest of the stream." > > | output pattern | > > aCollection ifEmpty: [ ^ collection species empty ]. > > output := (collection species new: 100) writeStream. > pattern := aCollection readStream. > > [ pattern atEnd ] whileFalse: [ | item | > self atEnd ifTrue: [ > output next: pattern position putAll: aCollection startingAt: 1. > ^ output contents > ]. > > item := self next. > (pattern peekFor: item) ifFalse: [ > output > next: pattern position putAll: aCollection startingAt: 1; > nextPut: item. > > pattern reset. > ]. > ]. > > ^ output contents > ------------------------------------ > > Best regards, > Henrik

Dec. 31, 2017

Re: [Pharo-dev] Best VM for the Mac>

by Bernhard Pieber

Hi Esteban, Thanks for the detailed explanation and for the VMs, too? ;-) Happy New Year! Bernhard > Am 31.12.2017 um 16:02 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > > >> On 31 Dec 2017, at 16:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> >>> On 31 Dec 2017, at 15:59, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> yes. >>> and I will promote them to stable this month. >> bah, not this month but january ;) > > ah, maybe is confusing, hehâ¦ yes, usually latest VMs are *not* for production. But this ones have been tested last three months and they work fine so yes, *this ones* can be used for production. > > Esteban > >> >>> >>>> On 31 Dec 2017, at 15:56, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>>> >>>> These are not for production, right? >>>> >>>> Bernhard >>>> >>>>> Am 31.12.2017 um 11:58 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> >>>>> wget -O- get.pharo.org/vmLatest70 | bash >>>>> wget -O- get.pharo.org/64/vmLatest70 | bash >>>>> >>>>> Esteban >>>>> >>>>>> On 31 Dec 2017, at 11:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>>>> >>>>>> Sean P. DeNigris wrote >>>>>>> What is the best VM right now for the Mac? Where/how would one get it? >>>>>> >>>>>> Bump ;) >>>>>> >>>>>> >>>>>> >>>>>> ----- >>>>>> Cheers, >>>>>> Sean >>>>>> -- >>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>> >>>> >>> >> > >

Dec. 31, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Bernhard Pieber

Hi Sven, Thanks for the answer. This is exactly what I was looking for. And it is great that there is also documentation. However, ZnCharacterReadStream does not implement #upToAll:. The implementation from PositionableStream cannot easily be borrowed because there seems to be no way to reset the position. Is there a plan to support the most commonly used messages from the normal streams? Bernhard > Am 30.12.2017 um 18:03 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > > 1.4. Converting Streams > >> On 30 Dec 2017, at 13:27, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> >> I just saw that the FileStream hierarchy including MultiByteFileStream is deprecated. However, I can't find what file stream class should be used to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also uses MultiByteFileStream. >> >> Can someone please point me to the right code? >> >> Bernhard

Dec. 31, 2017

Re: [Pharo-dev] Best VM for the Mac>

by Esteban Lorenzano

yes, they are compatible. > On 31 Dec 2017, at 16:03, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > EstebanLM wrote >> wget -O- get.pharo.org/vmLatest70 <http://get.pharo.org/vmLatest70> >> | bash >> wget -O- get.pharo.org/64/vmLatest70 >> <http://get.pharo.org/vmLatest70> | bash > > Thanks! Are those definitely compatible with Pharo 6.1 or is it important to > â¦/vmLatest61 in that case? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Dec. 31, 2017

Re: [Pharo-dev] Best VM for the Mac>

by Sean P. DeNigris

EstebanLM wrote > wget -O- get.pharo.org/vmLatest70 <http://get.pharo.org/vmLatest70> > | bash > wget -O- get.pharo.org/64/vmLatest70 > <http://get.pharo.org/vmLatest70> | bash Thanks! Are those definitely compatible with Pharo 6.1 or is it important to â¦/vmLatest61 in that case? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 31, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Bernhard Pieber

Hi Stef, Thank you for your answer pointing me to the ZnCharacter...Stream. This seems to be meant as the replacement I was looking for. I will have a closer look. Bernhard > Am 30.12.2017 um 17:35 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi Bernhard > > Have a look at how guille started to implement File package. > (Guille is actively converting all the image users of the old > hierarchy but last time he losts a couple of hours > because changing epicea and other users of positionable streams and > sourceArray... at the same time > was leading to complex situations :). But Guille told me that he > learned and will come back to this.) > > He is using ZnCharacterWriteStream and wrapper like ZnCrPortableWriteStream. > > writeSourceCodeFrom: aStream baseName: baseName isSt: stOrCsFlag > > | extension fileName outputStream | > extension := stOrCsFlag ifTrue: ['.st'] ifFalse: ['.cs']. > fileName := baseName, extension. > fileName := FileSystem disk checkName: fileName fixErrors: true. > outputStream := (File named: fileName) writeStream. > (ZnCrPortableWriteStream on: (ZnCharacterWriteStream > on: outputStream > encoding: 'utf8')) nextPutAll: aStream contents. > > outputStream close. > > writeSourceCodeFrom: aStream toFileReference: aFileReference > > aFileReference writeStreamDo: [ :outputStream | > (ZnCrPortableWriteStream on: (ZnCharacterWriteStream > on: outputStream > encoding: 'utf8')) nextPutAll: aStream contents. > ]. > > self inform: 'Filed out to: ', String cr, aFileReference basename > > > self inform: 'Filed out to: ', String cr, fileName. > > I hope it helps. > > Stef > > On Sat, Dec 30, 2017 at 1:27 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> I just saw that the FileStream hierarchy including MultiByteFileStream is deprecated. However, I can't find what file stream class should be used to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also uses MultiByteFileStream. >> >> Can someone please point me to the right code? >> >> Bernhard >

Dec. 31, 2017

Re: [Pharo-dev] Best VM for the Mac>

by Esteban Lorenzano

> On 31 Dec 2017, at 16:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 31 Dec 2017, at 15:59, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> yes. >> and I will promote them to stable this month. > bah, not this month but january ;) ah, maybe is confusing, hehâ¦ yes, usually latest VMs are *not* for production. But this ones have been tested last three months and they work fine so yes, *this ones* can be used for production. Esteban > >> >>> On 31 Dec 2017, at 15:56, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>> >>> These are not for production, right? >>> >>> Bernhard >>> >>>> Am 31.12.2017 um 11:58 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> >>>> wget -O- get.pharo.org/vmLatest70 | bash >>>> wget -O- get.pharo.org/64/vmLatest70 | bash >>>> >>>> Esteban >>>> >>>>> On 31 Dec 2017, at 11:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>>> >>>>> Sean P. DeNigris wrote >>>>>> What is the best VM right now for the Mac? Where/how would one get it? >>>>> >>>>> Bump ;) >>>>> >>>>> >>>>> >>>>> ----- >>>>> Cheers, >>>>> Sean >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> >>> >> >

Dec. 31, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Bernhard Pieber

Hi Denis, Thank you for your answer. However, setting the UTF8TextConverter did not help because of a bug in upToAll:. I created a pull request to fix it: https://github.com/pharo-project/pharo/pull/632 I am afraid the CI failed for some reason I don't understand. :-/ The UTF8TextConverter was set by default, by the way. Bernhard > Am 30.12.2017 um 13:57 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi Bernhard. > > The deprecation is still in progress. > Now to setup encoding for MultiByteFileStream you should set #converter: > > (FileLocator imageDirectory / 'test.txt') asFileReference readStreamDo: [ :s | > s converter: UTF8TextConverter new. > s contents > ] > > 2017-12-30 13:27 GMT+01:00 Bernhard Pieber <bernhard(a)pieber.com>: > I just saw that the FileStream hierarchy including MultiByteFileStream is deprecated. However, I can't find what file stream class should be used to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also uses MultiByteFileStream. > > Can someone please point me to the right code? > > Bernhard

Dec. 31, 2017

Re: [Pharo-dev] Best VM for the Mac>

by Esteban Lorenzano

> On 31 Dec 2017, at 15:59, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > yes. > and I will promote them to stable this month. bah, not this month but january ;) > >> On 31 Dec 2017, at 15:56, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> >> These are not for production, right? >> >> Bernhard >> >>> Am 31.12.2017 um 11:58 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>> wget -O- get.pharo.org/vmLatest70 | bash >>> wget -O- get.pharo.org/64/vmLatest70 | bash >>> >>> Esteban >>> >>>> On 31 Dec 2017, at 11:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>> >>>> Sean P. DeNigris wrote >>>>> What is the best VM right now for the Mac? Where/how would one get it? >>>> >>>> Bump ;) >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >> >

Dec. 31, 2017

Re: [Pharo-dev] Best VM for the Mac>

by Esteban Lorenzano

yes. and I will promote them to stable this month. > On 31 Dec 2017, at 15:56, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > These are not for production, right? > > Bernhard > >> Am 31.12.2017 um 11:58 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> wget -O- get.pharo.org/vmLatest70 | bash >> wget -O- get.pharo.org/64/vmLatest70 | bash >> >> Esteban >> >>> On 31 Dec 2017, at 11:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> Sean P. DeNigris wrote >>>> What is the best VM right now for the Mac? Where/how would one get it? >>> >>> Bump ;) >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Dec. 31, 2017

Re: [Pharo-dev] Best VM for the Mac>

by Bernhard Pieber

These are not for production, right? Bernhard > Am 31.12.2017 um 11:58 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > wget -O- get.pharo.org/vmLatest70 | bash > wget -O- get.pharo.org/64/vmLatest70 | bash > > Esteban > >> On 31 Dec 2017, at 11:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Sean P. DeNigris wrote >>> What is the best VM right now for the Mac? Where/how would one get it? >> >> Bump ;) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 31, 2017

Re: [Pharo-dev] Simple game framework

by Hilaire

I am *exploring* if Pharo will be suitable to have a simple programming environment to let kids write simple 2D games, SDL was designed for that. Some of my students asked me about programming games, Smalltalk way of writing code will be neat, but the environment need to be accessible and not over engineered. Le 30/12/2017 Ã 22:32, Stephane Ducasse a Ã©critÂ : > What kind of game are you targeting? Did you look at Bloc? Because to > me this is the way to go except if you want just a canvas > and reimplement your event loop. in that case SDL + Athens should work. -- Dr. Geo http://drgeo.eu

Dec. 31, 2017

Re: [Pharo-dev] [Pharo-users] Best wishes for 2018

by Norbert Hartl

I want to second that. It has been another amazing year for pharo. And I think things have changed significantly. So 2018 should be really great! I matched my personal not-to-serious goal # ps aux | grep pharo | wc -l 59 So I have 59 pharo images in production. Next step will be to exceed 100 in 2018! And yes, Iâm definitely interested in a bootstrapped image ;) Thank you all for your amazing work. We are a great community! Norbert > Am 29.12.2017 um 09:39 schrieb Torsten Bergmann <astares(a)gmx.de>: > > 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. 31, 2017

Re: [Pharo-dev] Simple game framework

by Hilaire

because simple things should be simple... Le 30/12/2017 Ã 22:32, Stephane Ducasse a Ã©critÂ : > Hilaire > > why do you need to have a sprite on a SDL surface and why plain Athens > is not good enough. Athens is an API not an implementation. > It is like sparta: an API and you do not care about the library below. > > OSWindow is a layer on top of SDL and it is better than SDL directly > to my understanding. > So you should get Athens and SDL for event. > > What kind of game are you targeting? Did you look at Bloc? Because to > me this is the way to go except if you want just a canvas > and reimplement your event loop. in that case SDL + Athens should work. > > Stef > > On Sat, Dec 30, 2017 at 9:33 PM, Hilaire<hilaire(a)drgeo.eu> wrote: >> I found the mix of OSWindow+SDL+Athens very complex (tens of classes with >> hundreds of methods) and to produce code hard to understand (I look at your >> spider code). >> >> I will prefer fewer functionnality I can understand. >> >> For example, how can you copy a sprite on a SDL surface? Can you do it >> without Athens surface? >> >> >> Le 28/12/2017 Ã 18:51, ClÃ©ment Bera a Ã©crit : >>> 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). >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> -- Dr. Geo http://drgeo.eu

Dec. 31, 2017

Re: [Pharo-dev] [Pharo-users] Best wishes for 2018

by Norbert Hartl

> Am 29.12.2017 um 10:27 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > Thanks Torsten, > I was about to write a similar mail. > > Thanks to everybody for allow me to be your âguy to hateâ :) > I will continue doing my best to make Pharo a better place for everybody, one step at a time. > You are still by far the nicest âguy to hateâ Iâve ever encountered ;) > happy new year! happy new year to you, too! Norbert > Esteban > >> On 29 Dec 2017, at 09:39, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> 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. 31, 2017

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

by Stephan Eggermont

Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi everybody, > > This looks like a good moment of the year to ask all of you what would > you want to see in Pharo next year. I wish you all the time and good health to realize some of your Pharo dreams Stephan

Dec. 31, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Stephan Eggermont

Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Bernhard. > > The deprecation is still in progress. Considering the amount of non-image code using this, I would be interested to hear how this is going to be supported and documented. Stephan

Dec. 31, 2017

Re: [Pharo-dev] Best VM for the Mac>

by Esteban Lorenzano

wget -O- get.pharo.org/vmLatest70 <http://get.pharo.org/vmLatest70> | bash wget -O- get.pharo.org/64/vmLatest70 <http://get.pharo.org/vmLatest70> | bash Esteban > On 31 Dec 2017, at 11:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sean P. DeNigris wrote >> What is the best VM right now for the Mac? Where/how would one get it? > > Bump ;) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Dec. 31, 2017

Re: [Pharo-dev] Best VM for the Mac>

by Sean P. DeNigris

Sean P. DeNigris wrote > What is the best VM right now for the Mac? Where/how would one get it? Bump ;) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 31, 2017

Re: [Pharo-dev] an error in ZnResourceMetaUtils>>queryKeyValueSafeSet ?

by Esteban Lorenzano

now I found that also $@ and $! are problematic for twitter api. soâ¦ Iâm guessing is a problem of twitter more than a generic error (this would have been spotted before, if is a bug). I need to dig to see if I can explicit an encoding in some way instead hacking over #queryKeyValueSafeSet (but that will be hard to do today ;) ) Esteban > On 29 Dec 2017, at 10:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi Sven, > > A POST with this form will fail on twitter api: > > POST /1.1/statuses/update.json HTTP/1.1 > Host: api.twitter.com > Content-Type: application/x-www-form-urlencoded > Accept: */* > Content-Length: 0 > User-Agent: Zinc HTTP Components 1.0 (Pharo/7.0) > > status=testing? > > It will fail because of the â?â, if I remove ? from save and I encode as this: > > POST /1.1/statuses/update.json HTTP/1.1 > Host: api.twitter.com > Content-Type: application/x-www-form-urlencoded > Accept: */* > Content-Length: 0 > User-Agent: Zinc HTTP Components 1.0 (Pharo/7.0) > > status=testing%3F > > it will be posted correctly. > > My doubt if this is a bug in queryKeyValueSafeSet or this is a particular problem on twitter. If the last, I didnât see a good way to change value of safe set for just one case (for now I just override the method, but this is clearly not good ;) ). > > cheers! > Esteban > > >> On 28 Dec 2017, at 13:00, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi Esteban, >> >>> On 28 Dec 2017, at 11:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> Hi all, Sven >>> >>> Iâm doing some experiments with twitter and posting and I found that twitter does not accept a post with $? in the status string (it throws an error). Now, if I change ZnResourceMetaUtils>>queryKeyValueSafeSet removing $? from the safe set it works correctly. >>> >>> the question is: this is a twitter error or a ZnResourceMetaUtils>>queryKeyValueSafeSet error and the $? shouldnât be considered safe (and then it should be percent encoded?) >>> >>> cheers, >>> Esteban >> >> I know that the last time I did the implementation, we looked very carefully in what characters are safe or not, and had some discussions about it. >> >> I am not familiar with the API you are trying to use. I am a bit confused by POST and 'status string', while encoding a query part of the URL. It is possible to show exactly the call that you are trying to make ? What does an equivalent curl -v call show ? Could you point to the actual API call documentation ? >> >> Sven >> >> >

Dec. 31, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Stephane Ducasse

Which reminds me that we should publish these HTML in another location.... Just too many things to do :( But at least we get pdf and HTML and more if needed for our books. On Sat, Dec 30, 2017 at 6:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > > 1.4. Converting Streams > >> On 30 Dec 2017, at 13:27, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> >> I just saw that the FileStream hierarchy including MultiByteFileStream is deprecated. However, I can't find what file stream class should be used to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also uses MultiByteFileStream. >> >> Can someone please point me to the right code? >> >> Bernhard > >

Dec. 30, 2017

Re: [Pharo-dev] Simple game framework

by Stephane Ducasse

Hilaire why do you need to have a sprite on a SDL surface and why plain Athens is not good enough. Athens is an API not an implementation. It is like sparta: an API and you do not care about the library below. OSWindow is a layer on top of SDL and it is better than SDL directly to my understanding. So you should get Athens and SDL for event. What kind of game are you targeting? Did you look at Bloc? Because to me this is the way to go except if you want just a canvas and reimplement your event loop. in that case SDL + Athens should work. Stef On Sat, Dec 30, 2017 at 9:33 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > I found the mix of OSWindow+SDL+Athens very complex (tens of classes with > hundreds of methods) and to produce code hard to understand (I look at your > spider code). > > I will prefer fewer functionnality I can understand. > > For example, how can you copy a sprite on a SDL surface? Can you do it > without Athens surface? > > > Le 28/12/2017 Ã 18:51, ClÃ©ment Bera a Ã©crit : >> >> 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). > > > -- > Dr. Geo > http://drgeo.eu > > >

Dec. 30, 2017

Re: [Pharo-dev] Simple game framework

by Hilaire

I found the mix of OSWindow+SDL+Athens very complex (tens of classes with hundreds of methods) and to produce code hard to understand (I look at your spider code). I will prefer fewer functionnality I can understand. For example, how can you copy a sprite on a SDL surface? Can you do it without Athens surface? Le 28/12/2017 Ã 18:51, ClÃ©ment Bera a Ã©critÂ : > 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). -- Dr. Geo http://drgeo.eu

Dec. 30, 2017

Re: [Pharo-dev] Pharo 7 crash on Mac

by Denis Kudriashov

Thank's Nicolas. It helps 2017-12-30 18:32 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Hi steph, > There is a workaround > defaults write NSGlobalDomain ApplePressAndHoldEnabled -bool falseâ. > See https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 > > Le 30 dÃ©c. 2017 17:58, "Stephane Ducasse" <stepharo.self(a)gmail.com> a > Ã©crit : > >> Hi bernhard >> >> I can crash pharo 60 and 70 on sierra nearly 3 times per 30 min. >> Because of a bad key combination. So I save often >> and do not use the arrow keys. :( >> We will have to address this super super super annoying problem. >> Now may be this is not the same bug. >> Guille is currently refactoring, adding many tests to Iceberg internal >> representation. >> >> Stef >> >> On Sat, Dec 30, 2017 at 11:03 AM, Bernhard Pieber <bernhard(a)pieber.com> >> wrote: >> > Hi, >> > >> > I wanted to set up a new Pharo 7 image for contributing. I used the >> description from here: https://github.com/pharo-proje >> ct/pharo/wiki/Contribute-a-fix-to-Pharo >> > >> > After I had successfully cloned the pharo repository Pharo crashed. I >> am afraid I cannot remember the last thing I did before the crash. >> Nevertheless, maybe the crash dump is of some use for someone being able to >> interpret its content. >> > >> > I am on macOS Sierra 10.12.6. >> > >> > ./pharo --version >> > 5.0 5.0.201708271955 Mac OS X built on Aug 27 2017 20:27:09 UTC >> Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) [Production >> Spur VM] >> > CoInterpreter VMMaker.oscog-eem.2265 uuid: >> 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 >> > StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: >> 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 >> > VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> $ Date: Sun Aug 27 21:55:26 2017 +0200 $ >> > Plugins: 201708271955 https://github.com/OpenSmallta >> lk/opensmalltalk-vm.git $ >> > >> > Happy New Year! >> > >> > Bernhard >> > >> >>

Dec. 30, 2017

Re: [Pharo-dev] Pharo 7 crash on Mac

by Nicolas Cellier

Hi steph, There is a workaround defaults write NSGlobalDomain ApplePressAndHoldEnabled -bool falseâ. See https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 Le 30 dÃ©c. 2017 17:58, "Stephane Ducasse" <stepharo.self(a)gmail.com> a Ã©crit : > Hi bernhard > > I can crash pharo 60 and 70 on sierra nearly 3 times per 30 min. > Because of a bad key combination. So I save often > and do not use the arrow keys. :( > We will have to address this super super super annoying problem. > Now may be this is not the same bug. > Guille is currently refactoring, adding many tests to Iceberg internal > representation. > > Stef > > On Sat, Dec 30, 2017 at 11:03 AM, Bernhard Pieber <bernhard(a)pieber.com> > wrote: > > Hi, > > > > I wanted to set up a new Pharo 7 image for contributing. I used the > description from here: https://github.com/pharo- > project/pharo/wiki/Contribute-a-fix-to-Pharo > > > > After I had successfully cloned the pharo repository Pharo crashed. I am > afraid I cannot remember the last thing I did before the crash. > Nevertheless, maybe the crash dump is of some use for someone being able to > interpret its content. > > > > I am on macOS Sierra 10.12.6. > > > > ./pharo --version > > 5.0 5.0.201708271955 Mac OS X built on Aug 27 2017 20:27:09 UTC > Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) [Production > Spur VM] > > CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a > Aug 27 2017 > > StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: > 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 > > VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > $ Date: Sun Aug 27 21:55:26 2017 +0200 $ > > Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk- > vm.git $ > > > > Happy New Year! > > > > Bernhard > > > >

Dec. 30, 2017

Re: [Pharo-dev] How to restore image upgrade? was New Year Wishlist (2018) ?

by Stephane Ducasse

;) We will get there. I want live update V2.0 for real. On Tue, Dec 26, 2017 at 11:36 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-12-25 23:54 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> As a half-way house, consider that "upgrade" scripts could be a good >> mechanism >> post-Release when changes should be less-deep/less-arduous on the system. >> This might avoid Esteban's time being needed to re-Release for each >> upgrade, >> with post-Release moving to a more community supported mechanism. >> This could scale better as we gain more users interested in long term >> support >> of their applications on a stable-release than the moving target of the >> development-edge. >> >> cheers -ben > > > Hi Ben, > upgrade scripts is what is used by Squeak trunk (as available via > Monticello). > it's difficult to write correctly, and difficult to test (clearly a job for > a bot). > Every intermediate script has to be replayed (or not, but who knows?) and > this is done via MonticelloConfigurationMap. > Can you imagine that transposed to git? > > It's not reversible (we don't provide the reverse scripts). > It might fail due to specific changes in the image (let's say dirty > workspace), and not only code changes. > > So it's very very far from git smoothness. > Fortunately, those scripts are rarely needed (as a percentage of commits). > Unfortunately, they are regularly needed (several times a year). > Remind that Pharo is supposed to change Kernel classes a bit faster than > Squeak ;) > >> >> On 25 December 2017 at 23:11, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >>> >>> Nicolas >>> >>> We want to keep the live part of Pharo and incremental loading and it >>> is key for us. Now we should not be naive. > > > Hi Steph, > Not every provocation deserves an answer ;) > I hope everyone here wants a lively thing, otherwise why use Pharo? > >>> >>> Most of the time we do not have the garantee that a change will work >>> when loaded. >>> > We have bots passing tests for rejecting broken code. > But the problem is that correct code can also be rejected > >>> We proposed Pablo to work since two years on a really working dynamic >>> code loader and >>> Pablo has really nice results. But it takes time to evaluate if/how we >>> integrate its changes. >>> Pablo has an atomic coder loader and an incremental and modular class >>> builder. >>> He also designed a modular shutdown/startup list manager (in production). >>> > Glad to ear that. I hope to read publications on this subject one day then. > Two years for nice intermediate results just confirms that the problem is > very tough as we all know... > >>> We want to be able to have a **real** and robust incremental load. >>> Right now as you know it and as in ANY smalltalk I can break the >>> system super easily. >>> There is no magic. I do not see how we can make sure that any piece of >>> code will be loaded >>> and do not break the system. >>> So our objective is to have a new infrastructure that we can updates >>> (like method hashes for example without having to >>> twists our mind and do five updates). >>> >>> Now about git, we want and we will have our lovely image as a working >>> directory but this requires engineering >>> because the image is another artefact that other languages do not have >>> to worry. >>> We will get there. >>> > > Agree with all you said, > > My point is that git is not going to help you solving the problems others > don't have. > If we have seemless integration for bootstrap free code, that will already > be something... > For the rest, it's a bit too much wishful thinking to my taste. > As said above, because bootstrap problems happen rarely, but regularly, > I can predict that pharo development won't be as smooth as dreamed of for > some time. > We have to accept that and work hard to find acceptable trade offs. > I'm interested in seeing which solution will emerge. > > >>> Stef >>> >>> >>> On Sun, Dec 24, 2017 at 11:41 PM, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> > >>> > >>> > 2017-12-24 2:59 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >>> >> >>> >> My four wishes, in no particular order: >>> >> - Better code completion >>> >> - Git in Pharo as easy as using Git for other languages >>> > >>> > The recipe is easy: turn pharo into a file based edit-compile-run >>> > language >>> > and expunge those live object burden ;) >>> > Let me explain why it's not just trolling. >>> > Currently we have to download an image made by a bot. >>> > Pharo has gradually lost the power to upgrade the image (it's not new). >>> > >>> > If we recognize that an image acts like a workspace, and want to let >>> > the >>> > pull/branch switch/etc work again... >>> > IOW going from one point to any other in source code graph >>> > and experience the full power of git like any other language, >>> > that means, in a live IDE, at least solving those two problems: >>> > - changing the tools that are used to upgrade the image (Compiler, >>> > MethodDictionary, Array, etc...) >>> > - correctly initialize all the states (including stange loops) >>> > If pharo has not managed to solve this with a linear one way history >>> > (the >>> > regularly broken update image option), >>> > how do you think this is going to be solved in the more general case? >>> > I call this the universal boostrap problem. >>> > >>> > IMO the logical next step is to separate the IDE >>> > (the Inanimate Desintegrated Environment of any other language). >>> > >>> > Maybe we don't have to bend Pharo too much to git if it does not fit. >>> > The goal: as easy might be not that easy. >>> > >>> > >>> >> - Bloc on Steroid >>> >> - Being able to interrupt any process and endless loop using >>> >> Cmd-. >>> >> >>> >> Merry Christmas to all of you! >>> >> Alexandre >>> >> >>> >> >>> >> >>> >> > On Dec 23, 2017, at 1:58 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> >> > wrote: >>> >> > >>> >> > Hi everybody, >>> >> > >>> >> > This looks like a good moment of the year to ask all of you what >>> >> > would >>> >> > you want to see in Pharo next year. >>> >> > Features, improvements, radical changes, etcâ¦. whatever you want. >>> >> > >>> >> > Of course, this list will not be a roadmap and it does not means we >>> >> > will >>> >> > implement all of it (as always, time drives our possibilities), but >>> >> > is a >>> >> > good moment for us a a community to check where we are and where we >>> >> > wan to >>> >> > go next :) >>> >> > >>> >> > So, letâs those wishes come! >>> >> > >>> >> > cheers, >>> >> > Esteban >>> >> >>> >> >>> > >>> >> >

Dec. 30, 2017

Re: [Pharo-dev] Calendrical capabilities

by Stephane Ducasse

Tx for the links. On Thu, Dec 28, 2017 at 6:00 PM, Michael Forster <mike(a)forsterfamily.ca> wrote: > 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. 30, 2017

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

by Stephane Ducasse

Not Pharo 70. Too many issues on other fronts. Ring2, calypso, iceberg.... On Thu, Dec 28, 2017 at 5:05 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 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. > > > It is unbelievable that we can have single image file. I think it is very > attractive goal for Pharo 7. And it is so close. > >> >> >> -- 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%20pull%20request%2… >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>> >>> >> >

Dec. 30, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Sven Van Caekenberghe

https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… 1.4. Converting Streams > On 30 Dec 2017, at 13:27, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > I just saw that the FileStream hierarchy including MultiByteFileStream is deprecated. However, I can't find what file stream class should be used to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also uses MultiByteFileStream. > > Can someone please point me to the right code? > > Bernhard

Dec. 30, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Stephane Ducasse

Thanks for asking because I hope that this is the case. Stef On Sat, Dec 30, 2017 at 2:59 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2017-07-23 23:18 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >> >> >> 2017-07-23 22:38 GMT+02:00 Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com>: >>> >>> >>> >>> 2017-07-23 19:56 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >>>> >>>> >>>> 2017-07-23 19:42 GMT+02:00 HernÃ¡n Morales Durand >>>> <hernan.morales(a)gmail.com>: >>>>> >>>>> 2017-07-22 10:03 GMT-03:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>> > >>>>> > Hm, I tried to create the build environment used for the >>>>> > windows vm build from opensmalltalk. >>>>> > >>>>> > I setup a cygwin environment with the same install commands as from >>>>> > >>>>> > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml >>>>> > >>>>> > My problems, first it is missing make and wget, I can add make and >>>>> > wget to the install command line for cygwin, but I am >>>>> > curious why it is working on the build server ? >>>>> > >>>>> > Anyway, after I got this working, the build stops and building the >>>>> > pkg-config package. >>>>> > The log says it can not find a gcc, I know that the build process >>>>> > with cygwin uses >>>>> > i686-w64-mingw32-gcc >>>>> > or >>>>> > x86_64-w64-mingw32-gcc >>>>> > >>>>> > But I don't understand where is the missing step to tell the >>>>> > configure scripts to use the >>>>> > >>>>> > i686-w64-mingw32-gcc command instead of "gcc", >>>>> > >>>>> > again, this seems to work on the appveyor build but not locally on my >>>>> > machine. >>>>> > >>>>> > Any idea what I had missed? >>>>> > >>>>> >>>>> I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in >>>>> your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and >>>>> the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the >>>>> line: >>>>> >>>>> MSYS2_PATH="/usr/local/bin:/usr/bin:/bin" >>>>> >>>>> to >>>>> >>>>> >>>>> MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/bin:/usr/bin:/bin" >>>>> >>>>> And finally >>>>> >>>>> source /etc/profile >>>>> >>>>> Cheers, >>>> >>>> >>>> I always had problems using mingw in the past. I got a working mingw >>>> environment some years ago, and a newer mingw version >>>> did not work well (some changes on the debug and exception format). >>>> But now, the build process for pharo did change. (The build instructions >>>> on github/pharo-vm are old and do not work anymore. >>>> >>>> And I hoped to get a more automatic and more reliable build process by >>>> using the same commands used by the build server for >>>> the opensmalltalk pharo vm sources. >>>> >>>> And I thought the compiler used to build the latest pharo-vm for windows >>>> is from cygwin ? >>>> >>>> >>> >>> Hi Nicolai, >>> more exactly we cross compile from a cygwin environment for a mingw >>> target. >>> The main reason for switching to cygwin are: >>> - this is required for the 64 bit vm >>> - the other flavours on opensmallalk (squeak/newspeak) were also built >>> with cygwin, so it's more simple to maintain a single way of doing things >>> >>> Cygwin is required for the 64bits vm because of directx. >>> Indeed cygwin still provides support for the legacy directx version used >>> by the VM, while recent mingw does not. >>> Until we port to a newer API, mingw thus depends on the MS directx >>> include and library files that we redistribute for 32 bits only (and we >>> should not without permission, I plan to remove these files). That does not >>> work at all for 64 bits. >>> >>> The 64bits VM does not work either with gcc and requires clang currently. >>> installing clang in mingw is tedious, while it's a prebuilt package in >>> cygwin. >>> >>> You now know why we use cygwin, not how, maybe it does not terribly >>> helps, but it's important in order to avoid regression, or to be aware of >>> what need to be done before changing the building environment again... >>> Could you detail what you tried exactly? >> >> >> >> Setup cygwin: >> >> CYG_MIRROR=http://cygwin.mirror.constant.com >> CYG_ROOT='c:\cygwin' >> CYG_SETUP=setup-x86.exe >> MINGW_ARCH=i686 >> $CYG_SETUP -dgnqNO -R $CYG_ROOT -s "$CYG_MIRROR" -l >> "$CYG_ROOT"/var/cache/setup -P >> mingw64-$MINGW_ARCH-gcc-core,mingw64-$MINGW_ARCH-gcc-g++,mingw64-$MINGW_ARCH-headers,mingw64-$MINGW_ARCH-runtime,zip,mingw64-$MINGW_ARCH-clang,libiconv-devel,libglib2.0-devel,perl,mingw64-$MINGW_ARCH-zlib,cmake,mingw64-$MINGW_ARCH-win-iconv,make,wget >> >> (taken from the appveyor.xml, I needed to add make and wget, don't know >> why, from the appveyor log I see that make and wget is installed, even >> without this option...) >> >> Run the build (from an "empty" environment, that is, no other msys or >> mingw in the path environment variable) >> >> set FLAVOR=pharo.cog.spur >> set ARCH=win32x86 >> set MINGW_ARCH=i686 >> set CYG_ROOT=c:\cygwin >> set TRAVIS_OS_NAME=windows >> set PATH=%CYG_ROOT%\bin;p:\git\bin;%PATH%; >> git config --system core.autocrlf input >> git clone -q --depth=5 --branch=Cog >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git C:\projects\vm >> SET APPVEYOR_BUILD_FOLDER=c:\projects\vm >> git checkout -qf 88c4c56245f3308e711b38467bb7636864886d16 >> %CYG_ROOT%\bin\bash -lc "cd $APPVEYOR_BUILD_FOLDER;exec 0</dev/null;exec >> ./.travis_build.sh" >> > > I still have problems building the pharo vm locally with the above setup. > Somehow I can not build the thirdparty libs > The compiler I use from the cygwin installation is > i686-w64-mingw32-gcc > But I can not see where this is set for the third party libs (starting with > pkg-config). > > Are they really build on the travis build server ? I can not see it in the > build log. > > nicolai > > > >> >> >> >>> >>> >>> Nicolas >>> >>>>> >>>>> HernÃ¡n >>>>> >>>>> > >>>>> > nicolai >>>>> > >>>>> > >>>>> > >>>>> > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>> >> >>>>> >> >>>>> >> >>>>> >> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be >>>>> >> <philippe.back(a)gmail.com>: >>>>> >>> >>>>> >>> I made my own build here. >>>>> >>> Not up to date with latest stuff but should work for the build >>>>> >>> process. >>>>> >>> >>>>> >>> https://ci.appveyor.com/project/philippeback/pharo-vm >>>>> >>> >>>>> >>> It uses my forked repo and provided you set your own bintray env >>>>> >>> vars for API keys will publish there. >>>>> >>> >>>>> >>> Check all of the output of env vars and where/which in the appveyor >>>>> >>> console to see what gets used when when it comes to compilers and so on as >>>>> >>> there were various compiler versions involved at one point. >>>>> >>> >>>>> >>> Third party cache part is also worth checking. >>>>> >>> >>>>> >>> Still not able to build on my local box at the moment due to some >>>>> >>> tools discrepancies happening. >>>>> >>> >>>>> >>> My build artifacts are embarking too much at this point but allow >>>>> >>> you ro get the release, debug, and assert vms for windows. This helps when >>>>> >>> debugging as backtraces and so on are much more meaningful and one can use >>>>> >>> gdb more effectively to understand what is going on. >>>>> >>> >>>>> >>> Just keep the dlls and exes and you'll be fine. >>>>> >> >>>>> >> >>>>> >> Ah good, thank you. >>>>> >> >>>>> >> >>>>> >>> >>>>> >>> >>>>> >>> HTH >>>>> >>> >>>>> >>> Phil >>>>> >>> >>>>> >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a >>>>> >>> Ã©crit : >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier >>>>> >>>> <nicolas.cellier.aka.nice(a)gmail.com>: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier >>>>> >>>>> <nicolas.cellier.aka.nice(a)gmail.com>: >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier >>>>> >>>>>>> <nicolas.cellier.aka.nice(a)gmail.com>: >>>>> >>>>>>>> >>>>> >>>>>>>> Hi Nicolai, >>>>> >>>>>>>> >>>>> >>>>>>>> If you look at appveyor.yml configuration on >>>>> >>>>>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml, >>>>> >>>>>>>> you will see that the pharo brand is not yet in the matrix. >>>>> >>>>>>>> >>>>> >>>>>>>> It's because builds are based on cygwin, but as I understood, >>>>> >>>>>>>> some library used by some plugin required by pharo refuse to compile with >>>>> >>>>>>>> cygwin. They appear to work with mingw32. >>>>> >>>>>>>> Cygwin provides headers for legacy directx, some distribution >>>>> >>>>>>>> of mingw32 did in the past, but it does not seem the case anymore. >>>>> >>>>>>>> Using the directx headers from Microsoft SDK is a problem. >>>>> >>>>>>>> They are not redistributable and can't be found anymore on the net (too >>>>> >>>>>>>> old). We cannot seriously base the builds on something so fragile (both >>>>> >>>>>>>> technically and legally) in the long term. >>>>> >>>>>>>> >>>>> >>>>>>>> Also, the 64 bits VM does only work with clang, and we don't >>>>> >>>>>>>> have anything available as a 64bits Microsoft SDK... So pharo has to fix >>>>> >>>>>>>> that too. >>>>> >>>>>>>> >>>>> >>>>>>>> In the interim, you should look at >>>>> >>>>>>>> https://github.com/pharo-project/pharo-vm/blob/master/.appveyor.yml and >>>>> >>>>>>>> follow the scripts there. >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> Ok, thank you. >>>>> >>>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> I gave it a shot on sunday, because it was particularly rainy in >>>>> >>>>>> Nantes, and I almost succeeded in compiling all the dependencies with >>>>> >>>>>> cygwin. >>>>> >>>>>> Well, I mean with autotools cmake libtool pkg-config and I >>>>> >>>>>> surely forget a few other niceties that some not so well informed >>>>> >>>>>> programmers committed with the faith that it would make their life "easier". >>>>> >>>>>> It certainly does not make mine simpler... >>>>> >>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: >>>>> >>>>>> it seems that the workaround of Igor does not work anymore. >>>>> >>>>>> ssize_t, WTF??? >>>>> >>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case >>>>> >>>>>> I'll publish the branch to see how far appveyor goes. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> So I solved the ssize_t problem by removing the hack from Igor >>>>> >>>>> which is not necessary anymore... >>>>> >>>>> But got another problem soon after while building the tests... >>>>> >>>>> There are trailing lines generated at end of >>>>> >>>>> tests/cairo-test-constructors.c that make the compilation fail: >>>>> >>>>> >>>>> >>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff >>>>> >>>>> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src >>>>> >>>>> -I../src -D_REENTRANT >>>>> >>>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 >>>>> >>>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/libpng16 >>>>> >>>>> -Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration >>>>> >>>>> -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum >>>>> >>>>> -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 >>>>> >>>>> -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers >>>>> >>>>> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline >>>>> >>>>> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 >>>>> >>>>> -Wno-unused-but-set-variable -D_REENTRANT -m32 >>>>> >>>>> -static-libgcc -static-libstdc++ >>>>> >>>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include >>>>> >>>>> -march=pentium4 -c -o cairo_test_suite-cairo-test-constructors.o `test -f >>>>> >>>>> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>>>> >>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de >>>>> >>>>> donnÃ©es n'a pas de type ni de classe de stockage >>>>> >>>>> oning (); >>>>> >>>>> ^ >>>>> >>>>> cairo-test-constructors.c:1118:1: attention : type defaults to >>>>> >>>>> âintâ in declaration of âoningâ [-Wimplicit-int] >>>>> >>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de >>>>> >>>>> donnÃ©es n'a pas de type ni de classe de stockage >>>>> >>>>> _register_ft_show_glyphs_table (); >>>>> >>>>> ^ >>>>> >>>>> >>>>> >>>>> And the file looks like it has obviously been overwritten, but >>>>> >>>>> not truncated !!! >>>>> >>>>> >>>>> >>>>> ... >>>>> >>>>> extern void _register_multi_page (void); >>>>> >>>>> extern void _register_fallback_resolution (void); >>>>> >>>>> >>>>> >>>>> void >>>>> >>>>> _cairo_test_runner_register_tests (void) >>>>> >>>>> { >>>>> >>>>> _register_a1_bug (); >>>>> >>>>> _register_a1_clip_paint (); >>>>> >>>>> ... >>>>> >>>>> _register_multi_page (); >>>>> >>>>> _register_fallback_resolution (); >>>>> >>>>> } >>>>> >>>>> oning (); >>>>> >>>>> _register_ft_show_glyphs_table (); >>>>> >>>>> _register_ft_text_vertical_layout_type1 (); >>>>> >>>>> _register_ft_text_vertical_layout_type3 (); >>>>> >>>>> _register_ft_text_antialias_none (); >>>>> >>>>> _register_ps_eps (); >>>>> >>>>> _register_ps_features (); >>>>> >>>>> _register_ps_surface_source (); >>>>> >>>>> _register_svg_surface (); >>>>> >>>>> _register_svg_clip (); >>>>> >>>>> _register_svg_surface_source (); >>>>> >>>>> _register_multi_page (); >>>>> >>>>> _register_fallback_resolution (); >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> This file is generated by a shell script >>>>> >>>>> test/make-cairo-test-constructors.sh >>>>> >>>>> I can't find any reference of the bug, and upgrade to version >>>>> >>>>> 1.14.8 does not solve the issue. >>>>> >>>>> So it will wait until tomorrow... >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> I got the build for windows with mingw nearly working. (it can not >>>>> >>>> build some plugins, like SqueakSSL for windows, because the used wincrypt.h >>>>> >>>> is different in the mingw distrubtion). >>>>> >>>> >>>>> >>>> I still have the problem, that there seems to be a preprocessing >>>>> >>>> step , that should put the vm-version (and source timestamp) in the >>>>> >>>> sqSCCSVersion.h >>>>> >>>> I got this working by running .travis_build.sh (with the options >>>>> >>>> for arch/flavor/platform) But how is this done normally when you build a vm >>>>> >>>> locally? >>>>> >>>> And how is this done for the pharo-vm we currently use? >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Nicolas >>>>> >>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> I hope that Esteban will find time to resolve all these >>>>> >>>>>>>> problems and have pharo brand back on opensmalltalk-vm. I guess that any >>>>> >>>>>>>> form of help is welcome. >>>>> >>>>>>>> >>>>> >>>>>>>> Nicolas >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess >>>>> >>>>>>>> <nicolaihess(a)gmail.com>: >>>>> >>>>>>>>> >>>>> >>>>>>>>> I still have problems building a vm on windows. >>>>> >>>>>>>>> can you give me some hints how to start ? >>>>> >>>>>>>>> I cloned the recent pharo-vm project, >>>>> >>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>>>> >>>>>>>>> run >>>>> >>>>>>>>> mvm >>>>> >>>>>>>>> >>>>> >>>>>>>>> But I got a couple of problems (mingw-32 compiler commands >>>>> >>>>>>>>> not found, I had to adjust the include path for finding directx header, >>>>> >>>>>>>>> missing variable replacement for git-versions). >>>>> >>>>>>>>> So I may miss some important steps. >>>>> >>>>>>>>> Is there a repository where I can clone the mingw environment >>>>> >>>>>>>>> used to build the win32-pharo-vm, the environment used on the build-server ? >>>>> >>>>>>>>> >>>>> >>>>>>>>> Thanks >>>>> >>>>>>>>> Nicolai >>>>> >>>>>>>>> >>>>> >>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess >>>>> >>>>>>>>> <nicolaihess(a)gmail.com>: >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess >>>>> >>>>>>>>>> <nicolaihess(a)gmail.com>: >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano >>>>> >>>>>>>>>>> <estebanlm(a)gmail.com>: >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> 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>: >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> Hi, >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> I believe they're built from >>>>> >>>>>>>>>>>>> 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 >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> (README still not updated) >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> what did changed ? I am not able to build the vm on windows >>>>> >>>>>>>>>>> anymore (something wrong with generating the generator.image, I'll now reset >>>>> >>>>>>>>>>> my local pharo-vm build directory and see if it works afterwards). >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> see attached the stderr log : >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> 'Errors in script loaded from >>>>> >>>>>>>>>> u:\github\pharo-vm\scripts\LoadVMMaker.st' >>>>> >>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>>>> >>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>>>> >>>>>>>>>> BaseSoundSystem class>>initialize >>>>> >>>>>>>>>> MCMethodDefinition>>postloadOver: >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> .... >>>>> >>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> Are we still working with branch spur-64, or are we back on >>>>> >>>>>>>>>>> master ? >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> Esteban >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess >>>>> >>>>>>>>>>>>> <nicolaihess(a)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/ >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> The latest builds on the buildserver are from the last >>>>> >>>>>>>>>>>>>> year only. >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> nicolai >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>> >>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>>> >> >>>>> > >>>>> >>>> >>> >> >

Dec. 30, 2017

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

by Stephane Ducasse

Thanks. What I understood is that positionableReadStream does not work with variable elements like utf-8 because there is no 1 to 1 mapping. On Sat, Dec 30, 2017 at 12:54 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > I created an issue for this: > https://pharo.fogbugz.com/f/cases/20898 > > Bernhard > >> Am 30.12.2017 um 12:01 schrieb Bernhard Pieber <bernhard(a)pieber.com>: >> >> I just checked and the bug in #upToAll: is still there in Pharo 7. >> >> Bernhard >> >>> Am 29.12.2017 um 20:26 schrieb Bernhard Pieber <bernhard(a)pieber.com>: >>> >>> Hi Henrik, >>> >>> Thanks for your answer. Sounds like a bug, then. :-/ >>> >>> Cheers, >>> Bernhard >>> >>>> Am 28.12.2017 um 20:31 schrieb Henrik-Nergaard <draagren(a)outlook.com>: >>>> >>>> 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 >> > >

Dec. 30, 2017

Re: [Pharo-dev] Pharo 7 crash on Mac

by Stephane Ducasse

Hi bernhard I can crash pharo 60 and 70 on sierra nearly 3 times per 30 min. Because of a bad key combination. So I save often and do not use the arrow keys. :( We will have to address this super super super annoying problem. Now may be this is not the same bug. Guille is currently refactoring, adding many tests to Iceberg internal representation. Stef On Sat, Dec 30, 2017 at 11:03 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > Hi, > > I wanted to set up a new Pharo 7 image for contributing. I used the description from here: https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > After I had successfully cloned the pharo repository Pharo crashed. I am afraid I cannot remember the last thing I did before the crash. Nevertheless, maybe the crash dump is of some use for someone being able to interpret its content. > > I am on macOS Sierra 10.12.6. > > ./pharo --version > 5.0 5.0.201708271955 Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 > VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ > Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > Happy New Year! > > Bernhard >

Dec. 30, 2017

Re: [Pharo-dev] Best wishes for 2018

by Stephane Ducasse

Tx. Nice picture! On Fri, Dec 29, 2017 at 9:39 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > 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. 30, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Stephane Ducasse

Hi Bernhard Have a look at how guille started to implement File package. (Guille is actively converting all the image users of the old hierarchy but last time he losts a couple of hours because changing epicea and other users of positionable streams and sourceArray... at the same time was leading to complex situations :). But Guille told me that he learned and will come back to this.) He is using ZnCharacterWriteStream and wrapper like ZnCrPortableWriteStream. writeSourceCodeFrom: aStream baseName: baseName isSt: stOrCsFlag | extension fileName outputStream | extension := stOrCsFlag ifTrue: ['.st'] ifFalse: ['.cs']. fileName := baseName, extension. fileName := FileSystem disk checkName: fileName fixErrors: true. outputStream := (File named: fileName) writeStream. (ZnCrPortableWriteStream on: (ZnCharacterWriteStream on: outputStream encoding: 'utf8')) nextPutAll: aStream contents. outputStream close. writeSourceCodeFrom: aStream toFileReference: aFileReference aFileReference writeStreamDo: [ :outputStream | (ZnCrPortableWriteStream on: (ZnCharacterWriteStream on: outputStream encoding: 'utf8')) nextPutAll: aStream contents. ]. self inform: 'Filed out to: ', String cr, aFileReference basename self inform: 'Filed out to: ', String cr, fileName. I hope it helps. Stef On Sat, Dec 30, 2017 at 1:27 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > I just saw that the FileStream hierarchy including MultiByteFileStream is deprecated. However, I can't find what file stream class should be used to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also uses MultiByteFileStream. > > Can someone please point me to the right code? > > Bernhard

Dec. 30, 2017

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

by StÃ©phane Ducasse

Me too :) > On 30 Dec 2017, at 15:51, Holger Freyther <holger(a)freyther.de> wrote: > > >> On 30. Dec 2017, at 20:13, Norbert Hartl <norbert(a)2denker.de> wrote: > > Hey! > > >> - working SSL on newer distributions > > related to that I would love a working VM release process. > > - Tag releases of the stable VM > - Be able to take release X.Y and release X.Y+1 with a single bugfix -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Dec. 30, 2017

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

by Holger Freyther

> On 30. Dec 2017, at 20:13, Norbert Hartl <norbert(a)2denker.de> wrote: Hey! > - working SSL on newer distributions related to that I would love a working VM release process. - Tag releases of the stable VM - Be able to take release X.Y and release X.Y+1 with a single bugfix

Dec. 30, 2017

Best VM for the Mac>

by Sean P. DeNigris

What is the best VM right now for the Mac? Where/how would one get it? I recently downloaded a fresh Launcher from CI which comes with CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017, but get.pharo.../vm70 downloads CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017â¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 30, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Denis Kudriashov

Hi Bernhard. The deprecation is still in progress. Now to setup encoding for MultiByteFileStream you should set #converter: (FileLocator imageDirectory / 'test.txt') asFileReference readStreamDo: [ :s | s converter: UTF8TextConverter new. s contents ] 2017-12-30 13:27 GMT+01:00 Bernhard Pieber <bernhard(a)pieber.com>: > I just saw that the FileStream hierarchy including MultiByteFileStream is > deprecated. However, I can't find what file stream class should be used to > read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also uses > MultiByteFileStream. > > Can someone please point me to the right code? > > Bernhard >

Dec. 30, 2017

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

by Henrik-Nergaard

Here is a fix. ------------------------------------ PositionableStream>>#upToAll: aCollection "Answer a subcollection from the current access position to the occurrence (if any, but not inclusive) of aCollection. If aCollection is not in the stream, answer the entire rest of the stream." | output pattern | aCollection ifEmpty: [ ^ collection species empty ]. output := (collection species new: 100) writeStream. pattern := aCollection readStream. [ pattern atEnd ] whileFalse: [ | item | self atEnd ifTrue: [ output next: pattern position putAll: aCollection startingAt: 1. ^ output contents ]. item := self next. (pattern peekFor: item) ifFalse: [ output next: pattern position putAll: aCollection startingAt: 1; nextPut: item. pattern reset. ]. ]. ^ output contents ------------------------------------ Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 30, 2017

Replacement for deprected MultiByteFileStream?

by Bernhard Pieber

I just saw that the FileStream hierarchy including MultiByteFileStream is deprecated. However, I can't find what file stream class should be used to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also uses MultiByteFileStream. Can someone please point me to the right code? Bernhard

Dec. 30, 2017

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

by StÃ©phane Ducasse

nice list :) > On 30 Dec 2017, at 13:13, Norbert Hartl <norbert(a)2denker.de> wrote: > > My list would be in order of importance: > > - stable 64bit vm > - mature iceberg plus dependent tools > - no endless loop in debugging anymore aka real stoppable computation > - bootstrap aka small image > - vm with collaboration support > - working SSL on newer distributions > - unified keymapping > - improved epicea > - better parser support aka core petit parser in the image > - basic document model in the image for documentation aka mini pillar > - bloc plus basic widgets > - better modification tracking support > - runtime traits / dynamic layers > - better set of slot classes for types and relations > > Norbert > >> Am 23.12.2017 um 17:58 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> Hi everybody, >> >> This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year. >> Features, improvements, radical changes, etcâ¦. whatever you want. >> >> Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :) >> >> So, letâs those wishes come! >> >> cheers, >> Esteban > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Dec. 30, 2017

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

by Bernhard Pieber

I created an issue for this: https://pharo.fogbugz.com/f/cases/20898 Bernhard > Am 30.12.2017 um 12:01 schrieb Bernhard Pieber <bernhard(a)pieber.com>: > > I just checked and the bug in #upToAll: is still there in Pharo 7. > > Bernhard > >> Am 29.12.2017 um 20:26 schrieb Bernhard Pieber <bernhard(a)pieber.com>: >> >> Hi Henrik, >> >> Thanks for your answer. Sounds like a bug, then. :-/ >> >> Cheers, >> Bernhard >> >>> Am 28.12.2017 um 20:31 schrieb Henrik-Nergaard <draagren(a)outlook.com>: >>> >>> 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 >

Dec. 30, 2017

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

by Bernhard Pieber

I just checked and the bug in #upToAll: is still there in Pharo 7. Bernhard > Am 29.12.2017 um 20:26 schrieb Bernhard Pieber <bernhard(a)pieber.com>: > > Hi Henrik, > > Thanks for your answer. Sounds like a bug, then. :-/ > > Cheers, > Bernhard > >> Am 28.12.2017 um 20:31 schrieb Henrik-Nergaard <draagren(a)outlook.com>: >> >> 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

Dec. 30, 2017

Pharo 7 crash on Mac

by Bernhard Pieber

Hi, I wanted to set up a new Pharo 7 image for contributing. I used the description from here: https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo After I had successfully cloned the pharo repository Pharo crashed. I am afraid I cannot remember the last thing I did before the crash. Nevertheless, maybe the crash dump is of some use for someone being able to interpret its content. I am on macOS Sierra 10.12.6. ./pharo --version 5.0 5.0.201708271955 Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Happy New Year! Bernhard

Dec. 30, 2017

Re: [Pharo-dev] Simple game framework

by Dimitris Chloupis

Problem is that people , coders and users, tend to underestimate the complexity of game development. 99% of the technology we use nowadays is game based. Powerful GPUs utilized by consumer computers and supercomputer alike to deal with highly complex problems like cancer research and simulations of the Bing Bang. Massive memory that is millions time large than technology that existed 30 years ago. A computer with 128GB of memory is exactly 1 million times bigger than my first computer with 128 kbs of memory that will become 30 years old in exactly one year. Massive super fast hard drives. Multi core CPUs The internet. Anything you look around you has so massively progressed , only because of high end games that have created the most profitable business for half a century. No other kind of software comes remotely close to pushing the hardware to such extremes and yet being so massively popular as high end games. So game APIs are extremely complex even for the simplest games. In Python for example we have , or rather had , Pygame , itâs as massively popular with beginners game developers as its massively unpopular with profession or very experienced amateur game developers. The latest Pygame is basically SDL with some extra game stuff. Why people donât use it beyond proof of concept ? One word âSimpleâ What the rest of the computer world pursue as the holy grail in game development is nothing more than a bad allergy . Why ? Because You will be far better in embracing the extremely complex engines on the market even for the creation of the simplest games. The moment you decide that using such an engine is an overkill for your so simple needs and that you donât have to endure their very steep learning curve is the moment you condemn yourself to a full rewrite if there is a remote chance of taking the game one step further. We all know how much fun full rewrites are. In short making games is no game. Go use a professional engine and you can thank me later. On Thu, 28 Dec 2017 at 19:53, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > 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 > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve > d > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> > 'Ascq > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> >

Dec. 30, 2017

Re: [Pharo-dev] Best wishes for 2018

by Dimitris Chloupis

Canât imagine myself ever coming remotely close to hating you. Big thanks to you and the rest of the community for keeping the dream alive and kicking. Looking back to 2011 when I first joined, Pharo has come a long way and nowadays it looks and is comparable to other far more popular languages and the fact our community is small is the ultimate proof of its high productivity. What makes me most happy with Pharo is that it has retained all the important parts of Smalltalk and also, even though I never did and never will hesitate for a second to compare Pharo to other languages and break the misconceptions - prejudice against them, Pharo for me has become a breath of fresh air, not afraid to follow its own path but at the same time not afraid of embracing the practical needs of coders struggling with finding bugs and retaining this direct connection with the machine instead of being lost inside its own massive complexity. Pharo has built a very solid yet flexible foundation that stands as the torch that keeps the flame alive and making Smalltalk more relevant to modern coders than ever before. Itâs living proof that Smalltalk is not a relic of the past,an outdated philosophy, great in theory , bad in practice but a life form that is made of binary code like anything else but on the same time far more capable of surviving, adjusting , evolving and thriving in a world that accelerates to light speed in matters of technology and science even though the world still struggles with basic concepts. Like a real transformer , Pharo is technology from the future and there is definetly more than meets the eye. I wish health and happiness to all and as always Keep dreaming with open mind On Fri, 29 Dec 2017 at 11:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Thanks Torsten, > I was about to write a similar mail. > > Thanks to everybody for allow me to be your âguy to hateâ :) > I will continue doing my best to make Pharo a better place for everybody, > one step at a time. > > happy new year! > Esteban > > > On 29 Dec 2017, at 09:39, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > 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. 30, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolai Hess

2017-07-23 23:18 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2017-07-23 22:38 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> >> >> 2017-07-23 19:56 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> >>> >>> 2017-07-23 19:42 GMT+02:00 HernÃ¡n Morales Durand < >>> hernan.morales(a)gmail.com>: >>> >>>> 2017-07-22 10:03 GMT-03:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> > >>>> > Hm, I tried to create the build environment used for the >>>> > windows vm build from opensmalltalk. >>>> > >>>> > I setup a cygwin environment with the same install commands as from >>>> > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/. >>>> appveyor.yml >>>> > >>>> > My problems, first it is missing make and wget, I can add make and >>>> wget to the install command line for cygwin, but I am >>>> > curious why it is working on the build server ? >>>> > >>>> > Anyway, after I got this working, the build stops and building the >>>> pkg-config package. >>>> > The log says it can not find a gcc, I know that the build process >>>> with cygwin uses >>>> > i686-w64-mingw32-gcc >>>> > or >>>> > x86_64-w64-mingw32-gcc >>>> > >>>> > But I don't understand where is the missing step to tell the >>>> configure scripts to use the >>>> > >>>> > i686-w64-mingw32-gcc command instead of "gcc", >>>> > >>>> > again, this seems to work on the appveyor build but not locally on my >>>> machine. >>>> > >>>> > Any idea what I had missed? >>>> > >>>> >>>> I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in >>>> your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and >>>> the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the >>>> line: >>>> >>>> MSYS2_PATH="/usr/local/bin:/usr/bin:/bin" >>>> >>>> to >>>> >>>> MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/bi >>>> n:/usr/bin:/bin" >>>> >>>> And finally >>>> >>>> source /etc/profile >>>> >>>> Cheers, >>>> >>> >>> I always had problems using mingw in the past. I got a working mingw >>> environment some years ago, and a newer mingw version >>> did not work well (some changes on the debug and exception format). >>> But now, the build process for pharo did change. (The build instructions >>> on github/pharo-vm are old and do not work anymore. >>> >>> And I hoped to get a more automatic and more reliable build process by >>> using the same commands used by the build server for >>> the opensmalltalk pharo vm sources. >>> >>> And I thought the compiler used to build the latest pharo-vm for windows >>> is from cygwin ? >>> >>> >>> >> Hi Nicolai, >> more exactly we cross compile from a cygwin environment for a mingw >> target. >> The main reason for switching to cygwin are: >> - this is required for the 64 bit vm >> - the other flavours on opensmallalk (squeak/newspeak) were also built >> with cygwin, so it's more simple to maintain a single way of doing things >> >> Cygwin is required for the 64bits vm because of directx. >> Indeed cygwin still provides support for the legacy directx version used >> by the VM, while recent mingw does not. >> Until we port to a newer API, mingw thus depends on the MS directx >> include and library files that we redistribute for 32 bits only (and we >> should not without permission, I plan to remove these files). That does not >> work at all for 64 bits. >> >> The 64bits VM does not work either with gcc and requires clang currently. >> installing clang in mingw is tedious, while it's a prebuilt package in >> cygwin. >> >> You now know why we use cygwin, not how, maybe it does not terribly >> helps, but it's important in order to avoid regression, or to be aware of >> what need to be done before changing the building environment again... >> Could you detail what you tried exactly? >> > > > Setup cygwin: > > CYG_MIRROR=http://cygwin.mirror.constant.com > CYG_ROOT='c:\cygwin' > CYG_SETUP=setup-x86.exe > MINGW_ARCH=i686 > $CYG_SETUP -dgnqNO -R $CYG_ROOT -s "$CYG_MIRROR" -l > "$CYG_ROOT"/var/cache/setup -P mingw64-$MINGW_ARCH-gcc-core, > mingw64-$MINGW_ARCH-gcc-g++,mingw64-$MINGW_ARCH-headers, > mingw64-$MINGW_ARCH-runtime,zip,mingw64-$MINGW_ARCH-clang, > libiconv-devel,libglib2.0-devel,perl,mingw64-$MINGW_ > ARCH-zlib,cmake,mingw64-$MINGW_ARCH-win-iconv,make,wget > > (taken from the appveyor.xml, I needed to add make and wget, don't know > why, from the appveyor log I see that make and wget is installed, even > without this option...) > > Run the build (from an "empty" environment, that is, no other msys or > mingw in the path environment variable) > > set FLAVOR=pharo.cog.spur > set ARCH=win32x86 > set MINGW_ARCH=i686 > set CYG_ROOT=c:\cygwin > set TRAVIS_OS_NAME=windows > set PATH=%CYG_ROOT%\bin;p:\git\bin;%PATH%; > git config --system core.autocrlf input > git clone -q --depth=5 --branch=Cog https://github.com/ > OpenSmalltalk/opensmalltalk-vm.git C:\projects\vm > SET APPVEYOR_BUILD_FOLDER=c:\projects\vm > git checkout -qf 88c4c56245f3308e711b38467bb7636864886d16 > %CYG_ROOT%\bin\bash -lc "cd $APPVEYOR_BUILD_FOLDER;exec 0</dev/null;exec > ./.travis_build.sh" > > I still have problems building the pharo vm locally with the above setup. Somehow I can not build the thirdparty libs The compiler I use from the cygwin installation is i686-w64-mingw32-gcc But I can not see where this is set for the third party libs (starting with pkg-config). Are they really build on the travis build server ? I can not see it in the build log. nicolai > > > >> >> Nicolas >> >> >>>> HernÃ¡n >>>> >>>> > >>>> > nicolai >>>> > >>>> > >>>> > >>>> > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >> >>>> >> >>>> >> >>>> >> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be < >>>> philippe.back(a)gmail.com>: >>>> >>> >>>> >>> I made my own build here. >>>> >>> Not up to date with latest stuff but should work for the build >>>> process. >>>> >>> >>>> >>> https://ci.appveyor.com/project/philippeback/pharo-vm >>>> >>> >>>> >>> It uses my forked repo and provided you set your own bintray env >>>> vars for API keys will publish there. >>>> >>> >>>> >>> Check all of the output of env vars and where/which in the appveyor >>>> console to see what gets used when when it comes to compilers and so on as >>>> there were various compiler versions involved at one point. >>>> >>> >>>> >>> Third party cache part is also worth checking. >>>> >>> >>>> >>> Still not able to build on my local box at the moment due to some >>>> tools discrepancies happening. >>>> >>> >>>> >>> My build artifacts are embarking too much at this point but allow >>>> you ro get the release, debug, and assert vms for windows. This helps when >>>> debugging as backtraces and so on are much more meaningful and one can use >>>> gdb more effectively to understand what is going on. >>>> >>> >>>> >>> Just keep the dlls and exes and you'll be fine. >>>> >> >>>> >> >>>> >> Ah good, thank you. >>>> >> >>>> >> >>>> >>> >>>> >>> >>>> >>> HTH >>>> >>> >>>> >>> Phil >>>> >>> >>>> >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a >>>> Ã©crit : >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>>>>>> >>>> >>>>>>>> Hi Nicolai, >>>> >>>>>>>> >>>> >>>>>>>> If you look at appveyor.yml configuration on >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/. >>>> appveyor.yml, you will see that the pharo brand is not yet in the >>>> matrix. >>>> >>>>>>>> >>>> >>>>>>>> It's because builds are based on cygwin, but as I understood, >>>> some library used by some plugin required by pharo refuse to compile with >>>> cygwin. They appear to work with mingw32. >>>> >>>>>>>> Cygwin provides headers for legacy directx, some distribution >>>> of mingw32 did in the past, but it does not seem the case anymore. >>>> >>>>>>>> Using the directx headers from Microsoft SDK is a problem. >>>> They are not redistributable and can't be found anymore on the net (too >>>> old). We cannot seriously base the builds on something so fragile (both >>>> technically and legally) in the long term. >>>> >>>>>>>> >>>> >>>>>>>> Also, the 64 bits VM does only work with clang, and we don't >>>> have anything available as a 64bits Microsoft SDK... So pharo has to fix >>>> that too. >>>> >>>>>>>> >>>> >>>>>>>> In the interim, you should look at >>>> https://github.com/pharo-project/pharo-vm/blob/master/.appveyor.yml >>>> and follow the scripts there. >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> Ok, thank you. >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> I gave it a shot on sunday, because it was particularly rainy in >>>> Nantes, and I almost succeeded in compiling all the dependencies with >>>> cygwin. >>>> >>>>>> Well, I mean with autotools cmake libtool pkg-config and I >>>> surely forget a few other niceties that some not so well informed >>>> programmers committed with the faith that it would make their life >>>> "easier". It certainly does not make mine simpler... >>>> >>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: >>>> it seems that the workaround of Igor does not work anymore. >>>> >>>>>> ssize_t, WTF??? >>>> >>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case >>>> I'll publish the branch to see how far appveyor goes. >>>> >>>>>> >>>> >>>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> So I solved the ssize_t problem by removing the hack from Igor >>>> which is not necessary anymore... >>>> >>>>> But got another problem soon after while building the tests... >>>> >>>>> There are trailing lines generated at end of >>>> tests/cairo-test-constructors.c that make the compilation fail: >>>> >>>>> >>>> >>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff >>>> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src >>>> -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opens >>>> malltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 >>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/libpng16 >>>> -Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration >>>> -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum >>>> -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 >>>> -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers >>>> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline >>>> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 >>>> -Wno-unused-but-set-variable -D_REENTRANT -m32 >>>> -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensm >>>> alltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c >>>> -o cairo_test_suite-cairo-test-constructors.o `test -f >>>> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>>> >>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de >>>> donnÃ©es n'a pas de type ni de classe de stockage >>>> >>>>> oning (); >>>> >>>>> ^ >>>> >>>>> cairo-test-constructors.c:1118:1: attention : type defaults to >>>> âintâ in declaration of âoningâ [-Wimplicit-int] >>>> >>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de >>>> donnÃ©es n'a pas de type ni de classe de stockage >>>> >>>>> _register_ft_show_glyphs_table (); >>>> >>>>> ^ >>>> >>>>> >>>> >>>>> And the file looks like it has obviously been overwritten, but >>>> not truncated !!! >>>> >>>>> >>>> >>>>> ... >>>> >>>>> extern void _register_multi_page (void); >>>> >>>>> extern void _register_fallback_resolution (void); >>>> >>>>> >>>> >>>>> void >>>> >>>>> _cairo_test_runner_register_tests (void) >>>> >>>>> { >>>> >>>>> _register_a1_bug (); >>>> >>>>> _register_a1_clip_paint (); >>>> >>>>> ... >>>> >>>>> _register_multi_page (); >>>> >>>>> _register_fallback_resolution (); >>>> >>>>> } >>>> >>>>> oning (); >>>> >>>>> _register_ft_show_glyphs_table (); >>>> >>>>> _register_ft_text_vertical_layout_type1 (); >>>> >>>>> _register_ft_text_vertical_layout_type3 (); >>>> >>>>> _register_ft_text_antialias_none (); >>>> >>>>> _register_ps_eps (); >>>> >>>>> _register_ps_features (); >>>> >>>>> _register_ps_surface_source (); >>>> >>>>> _register_svg_surface (); >>>> >>>>> _register_svg_clip (); >>>> >>>>> _register_svg_surface_source (); >>>> >>>>> _register_multi_page (); >>>> >>>>> _register_fallback_resolution (); >>>> >>>>> } >>>> >>>>> >>>> >>>>> This file is generated by a shell script >>>> test/make-cairo-test-constructors.sh >>>> >>>>> I can't find any reference of the bug, and upgrade to version >>>> 1.14.8 does not solve the issue. >>>> >>>>> So it will wait until tomorrow... >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I got the build for windows with mingw nearly working. (it can not >>>> build some plugins, like SqueakSSL for windows, because the used wincrypt.h >>>> is different in the mingw distrubtion). >>>> >>>> >>>> >>>> I still have the problem, that there seems to be a preprocessing >>>> step , that should put the vm-version (and source timestamp) in the >>>> sqSCCSVersion.h >>>> >>>> I got this working by running .travis_build.sh (with the options >>>> for arch/flavor/platform) But how is this done normally when you build a vm >>>> locally? >>>> >>>> And how is this done for the pharo-vm we currently use? >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Nicolas >>>> >>>>> >>>> >>>>>>>> >>>> >>>>>>>> I hope that Esteban will find time to resolve all these >>>> problems and have pharo brand back on opensmalltalk-vm. I guess that any >>>> form of help is welcome. >>>> >>>>>>>> >>>> >>>>>>>> Nicolas >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com >>>> >: >>>> >>>>>>>>> >>>> >>>>>>>>> I still have problems building a vm on windows. >>>> >>>>>>>>> can you give me some hints how to start ? >>>> >>>>>>>>> I cloned the recent pharo-vm project, >>>> >>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>>> >>>>>>>>> run >>>> >>>>>>>>> mvm >>>> >>>>>>>>> >>>> >>>>>>>>> But I got a couple of problems (mingw-32 compiler commands >>>> not found, I had to adjust the include path for finding directx header, >>>> missing variable replacement for git-versions). >>>> >>>>>>>>> So I may miss some important steps. >>>> >>>>>>>>> Is there a repository where I can clone the mingw environment >>>> used to build the win32-pharo-vm, the environment used on the build-server ? >>>> >>>>>>>>> >>>> >>>>>>>>> Thanks >>>> >>>>>>>>> Nicolai >>>> >>>>>>>>> >>>> >>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com >>>> >: >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess < >>>> nicolaihess(a)gmail.com>: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano < >>>> estebanlm(a)gmail.com>: >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> 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>: >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Hi, >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> I believe they're built from >>>> 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 >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> (README still not updated) >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> what did changed ? I am not able to build the vm on windows >>>> anymore (something wrong with generating the generator.image, I'll now >>>> reset my local pharo-vm build directory and see if it works afterwards). >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> see attached the stderr log : >>>> >>>>>>>>>> >>>> >>>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\Loa >>>> dVMMaker.st' >>>> >>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>>> >>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>>> >>>>>>>>>> BaseSoundSystem class>>initialize >>>> >>>>>>>>>> MCMethodDefinition>>postloadOver: >>>> >>>>>>>>>> >>>> >>>>>>>>>> .... >>>> >>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Are we still working with branch spur-64, or are we back on >>>> master ? >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> Esteban >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess < >>>> nicolaihess(a)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/ >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> The latest builds on the buildserver are from the last >>>> year only. >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> nicolai >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>> >>>> >>>> >>>> >> >>>> > >>>> >>>> >>> >> >

Dec. 30, 2017

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

by Bernhard Pieber

Hi Henrik, Thanks for your answer. Sounds like a bug, then. :-/ Cheers, Bernhard > Am 28.12.2017 um 20:31 schrieb Henrik-Nergaard <draagren(a)outlook.com>: > > 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

Dec. 29, 2017

Re: [Pharo-dev] Flexibility of ZnUrl (For Metacello evolution)

by Dale Henrichs

On 12/29/17 3:55 AM, Sven Van Caekenberghe wrote: > >> On 29 Dec 2017, at 10:35, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: >> >> Hi, >> >> In order to improve the usage of Pharo and the git integration there is >> some discussions around Metacello in order to be able to: >> >> - Load a private git project from Metacello API >> - Load a project hosted on a private server from Metacello API >> - Load a project hosted on a private server with non default ssh port >> from Metacello API >> - Depend on a private git project in a baseline >> - Depend on a project hosted on a private server in a baseline >> - Depend on a project hosted on a private server with non default ssh >> port in a baseline >> >> To achieve this, Metacello needs to be able to manage urls like: >> >> - 'git@gitlab.ferlicot.fr:Projet/Bazard.git' >> - 'ssh://git@gitlab.ferlicot.fr:3456/Projet/Bazard.git' >> >> and many others. >> >> Dale wants to use Zinc to manage urls's in Pharo. >> >> It works great for this url: >> >> 'ssh://git@gitlab.ferlicot.fr:3456/Projet/Bazard.git' asUrl >> >> It gives an instance of ZnUrl of the ssh scheme, gitlab.ferlicot.fr as >> host, 3456 as port, git as username and #('Project' 'Bazard.git') as >> segments. >> >> Now the problem is that it does not work well for this url: >> >> 'git@gitlab.ferlicot.fr:Projet/Bazard.git' asUrl > ZnUrl fromString: 'git(a)gitlab.ferlicot.fr/Projet/Bazard.git' defaultScheme: #http. > > ZnUrl fromString: 'git(a)gitlab.ferlicot.fr/Projet/Bazard.git' defaultScheme: #ssh. > > URI/URL are put in classes or types based on their scheme. If there is no explicit scheme in the URI/URL itself, you have to supply a default one. > > That being said, the general syntax supported by ZnUrl is approximately > > scheme://username:password@host:port/segments?query#fragment > > The colon right after the host is reserved for a port, a path has to start with a / (unless you are using relative URL's, but then you need a parent context). This is why I changed your example, to make it work. > > There literally exist hundreds of schemes, some with very weird syntax. That is indeed the prerogative of a scheme, to define its own special syntax. However, the straightforward approach of the ZnUrl parser cannot recognise those. > > The question then becomes: how to provide an extension mechanism for exotic schemes ? > > Although the question has come up a couple of times, it has never been very urgent. > > I know that some people have programmed around this limitation, maybe they could tell us what they did. > Thanks Sven. As Cyril points out we are considering adding a new batch of urls for repository descriptions and the first order of business is to solve the parsing issue --- I would prefer NOT to bring back the old Url hiearchy --- which is what I would do if forced to provide a Metacello-specific solution ... The overall goal is to be able have Metacello execute an expression that looks like the following: Â repositoryDescriptionString asUrl asMetacelloRepository where the repositoryDescriptionString could be one of the following: Â 'http://seaside.gemtalksystems.com/ss/metacello' Â 'github://dalehenrich/filetree:pharo1.1/repository' Â 'filetree://$GS_HOME/shared/repos/metacello/repository' Note that the last two repository descriptions are accepted by ZnUrl, but require additional parsing tease out the required fields. Cyril's examples are what is used by git as a repository description: Â 'ssh://git@gitlab.ferlicot.fr:3456/Projet/Bazard.git' Â 'git@gitlab.ferlicot.fr:Projet/Bazard.git' Note that in these two examples from Cyril, we are missing some critical information: commitish and repository path need for a complete Metacello repository description, so I don't consider these repository descriptions complete. Thierry Goubier addressed these particular issues with his GitFileTree repository description[1]: Â 'gitfiletree://gitlab.ferlicot.fr:3456:Projet/Bazard:dev/src' My inclination is to base the custom urls on Thierry's gitfiletree model, but we are still in the process of gathering requirements and parsing technology will be an issue once we've settled on the standard set of repository descriptions. In the past Thierry has mentioned that "I would have reused ZnUrl to do that [iceberg using regex], but maybe they wanted to avoid ZnUrl errors about unknown schemes. I had to copy/paste some of the ZnUrl code into GitFileTree for that purpose."[2] Looking at Thierry's implementation[1] it does look like he is able to pack all of the critical information into the repository description, but as with the github:// and filetree:// schemes additional parsing is required to tease out all of the fields ... I have not seen examples of the repository descriptions used by iceberg (yet) ... So, Sven, it would be interesting to hear from you about any ideas that you might have to allow for the handling of custom url parsing within the ZnUrl framework... ideally we'd not have to do any scheme-specific post-parsing of the url and the #asMetacelloRepository method could be implemented to just send messages to extract the various values of the custom fields ... as with the old Url hierarchy, allowing subclasses to implement custom parsers based on the scheme could be done, but it isn't the only approach. I do want to point out that the #asMetacelloRepository is intended to return a repository instance from which packages can be loaded by Metacello... and the intent is to allow developers to be able to choose which platform tool will be used to manage the repository. The idea is that platform tools will register to handle a particular scheme, so the a developer can choose whether to use gitfiletree or iceberg or <the next generation repository management tool> to manage the repository for the github:// scheme, etc. This would eliminate the current implementation where we have a fixed map of schemes to tools and developers to invent a custom url (and patch Metacello) for each new tool. Dale [1] https://github.com/dalehenrich/filetree/blob/734eed46ea57ebf5e24e5d935768bd… [2] https://github.com/Metacello/metacello/issues/474#issuecomment-350871020

Dec. 29, 2017

Re: [Pharo-dev] Flexibility of ZnUrl (For Metacello evolution)

by Norbert Hartl

> Am 29.12.2017 um 10:35 schrieb Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > > Hi, > > In order to improve the usage of Pharo and the git integration there is > some discussions around Metacello in order to be able to: > > - Load a private git project from Metacello API > - Load a project hosted on a private server from Metacello API > - Load a project hosted on a private server with non default ssh port > from Metacello API > - Depend on a private git project in a baseline > - Depend on a project hosted on a private server in a baseline > - Depend on a project hosted on a private server with non default ssh > port in a baseline > > To achieve this, Metacello needs to be able to manage urls like: > > - 'git@gitlab.ferlicot.fr:Projet/Bazard.git' > - 'ssh://git@gitlab.ferlicot.fr:3456/Projet/Bazard.git' > > and many others. > > Dale wants to use Zinc to manage urls's in Pharo. > > It works great for this url: > > 'ssh://git@gitlab.ferlicot.fr:3456/Projet/Bazard.git' asUrl > > It gives an instance of ZnUrl of the ssh scheme, gitlab.ferlicot.fr as > host, 3456 as port, git as username and #('Project' 'Bazard.git') as > segments. > > Now the problem is that it does not work well for this url: > > 'git@gitlab.ferlicot.fr:Projet/Bazard.git' asUrl > > It gives an instance of ZnUrl with #('git@gitlab.ferlicot.fr:Projet' > 'Bazard.git') as segments. > > What do you think guys about this issue? Could the flexibility of ZnUrls > be improved in order to be able to use it? Should Metacello use another way? > Why ZnURL should be flexible to treat something that is not a URI? An URI is something like <some ascii chars>:<some arbitrary stuff> The important part is the colon. If you split on it then the first part is addressing a name that can be resolved to get an entity that can digest the second part. Thatâs it! A locator is just a special form of URI that cheats by saying that the second part can be used directly to locate the resource (thatâs the difference by identifiable resources and locatable resources meaning the ones that really exist) So I cannot see how this can work. But nobody says you need to fold this into ZnURL. A Client is free to do something like if it starts with git I prepend that with ssh:// or git:// or git+ssh:// So the point is that if your model is the URI (it does not have to) then you should create valid URLs by adding missing stuff. Otherwise just have a model that treats URLs and your special cases. Norbert > To see the full discussions: > - Github issue: https://github.com/Metacello/metacello/issues/474 > - Metacello group discussion: > https://groups.google.com/forum/#!topic/metacello/QbpngL6Jhg8 > > Have a nice day :) > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Dec. 29, 2017

Re: [Pharo-dev] Flexibility of ZnUrl (For Metacello evolution)

by Sven Van Caekenberghe

> On 29 Dec 2017, at 10:35, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Hi, > > In order to improve the usage of Pharo and the git integration there is > some discussions around Metacello in order to be able to: > > - Load a private git project from Metacello API > - Load a project hosted on a private server from Metacello API > - Load a project hosted on a private server with non default ssh port > from Metacello API > - Depend on a private git project in a baseline > - Depend on a project hosted on a private server in a baseline > - Depend on a project hosted on a private server with non default ssh > port in a baseline > > To achieve this, Metacello needs to be able to manage urls like: > > - 'git@gitlab.ferlicot.fr:Projet/Bazard.git' > - 'ssh://git@gitlab.ferlicot.fr:3456/Projet/Bazard.git' > > and many others. > > Dale wants to use Zinc to manage urls's in Pharo. > > It works great for this url: > > 'ssh://git@gitlab.ferlicot.fr:3456/Projet/Bazard.git' asUrl > > It gives an instance of ZnUrl of the ssh scheme, gitlab.ferlicot.fr as > host, 3456 as port, git as username and #('Project' 'Bazard.git') as > segments. > > Now the problem is that it does not work well for this url: > > 'git@gitlab.ferlicot.fr:Projet/Bazard.git' asUrl ZnUrl fromString: 'git(a)gitlab.ferlicot.fr/Projet/Bazard.git' defaultScheme: #http. ZnUrl fromString: 'git(a)gitlab.ferlicot.fr/Projet/Bazard.git' defaultScheme: #ssh. URI/URL are put in classes or types based on their scheme. If there is no explicit scheme in the URI/URL itself, you have to supply a default one. That being said, the general syntax supported by ZnUrl is approximately scheme://username:password@host:port/segments?query#fragment The colon right after the host is reserved for a port, a path has to start with a / (unless you are using relative URL's, but then you need a parent context). This is why I changed your example, to make it work. There literally exist hundreds of schemes, some with very weird syntax. That is indeed the prerogative of a scheme, to define its own special syntax. However, the straightforward approach of the ZnUrl parser cannot recognise those. The question then becomes: how to provide an extension mechanism for exotic schemes ? Although the question has come up a couple of times, it has never been very urgent. I know that some people have programmed around this limitation, maybe they could tell us what they did. > It gives an instance of ZnUrl with #('git@gitlab.ferlicot.fr:Projet' > 'Bazard.git') as segments. > > What do you think guys about this issue? Could the flexibility of ZnUrls > be improved in order to be able to use it? Should Metacello use another way? > > To see the full discussions: > - Github issue: https://github.com/Metacello/metacello/issues/474 > - Metacello group discussion: > https://groups.google.com/forum/#!topic/metacello/QbpngL6Jhg8 > > Have a nice day :) > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Dec. 29, 2017

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

by philippe.back＠highoctane.be

On Dec 29, 2017 02:48, "Pierce Ng" <pierce(a)samadhiweb.com> wrote: 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. That would actually suit me very well too. Being able to implement domain logic stuff in Pharo embedded into the application will super charge productivity. +1 million Phil Pierce

Dec. 29, 2017

Re: [Pharo-dev] Best wishes for 2018

by Hilaire

Don't worrry, we love you guy! Happy new year Le 29/12/2017 Ã 10:27, Esteban Lorenzano a Ã©critÂ : > Thanks to everybody for allow me to be your âguy to hateâ:) > I will continue doing my best to make Pharo a better place for everybody, one step at a time. -- Dr. Geo http://drgeo.eu

Dec. 29, 2017

Flexibility of ZnUrl (For Metacello evolution)

by Cyril Ferlicot D.

Hi, In order to improve the usage of Pharo and the git integration there is some discussions around Metacello in order to be able to: - Load a private git project from Metacello API - Load a project hosted on a private server from Metacello API - Load a project hosted on a private server with non default ssh port from Metacello API - Depend on a private git project in a baseline - Depend on a project hosted on a private server in a baseline - Depend on a project hosted on a private server with non default ssh port in a baseline To achieve this, Metacello needs to be able to manage urls like: - 'git@gitlab.ferlicot.fr:Projet/Bazard.git' - 'ssh://git@gitlab.ferlicot.fr:3456/Projet/Bazard.git' and many others. Dale wants to use Zinc to manage urls's in Pharo. It works great for this url: 'ssh://git@gitlab.ferlicot.fr:3456/Projet/Bazard.git' asUrl It gives an instance of ZnUrl of the ssh scheme, gitlab.ferlicot.fr as host, 3456 as port, git as username and #('Project' 'Bazard.git') as segments. Now the problem is that it does not work well for this url: 'git@gitlab.ferlicot.fr:Projet/Bazard.git' asUrl It gives an instance of ZnUrl with #('git@gitlab.ferlicot.fr:Projet' 'Bazard.git') as segments. What do you think guys about this issue? Could the flexibility of ZnUrls be improved in order to be able to use it? Should Metacello use another way? To see the full discussions: - Github issue: https://github.com/Metacello/metacello/issues/474 - Metacello group discussion: https://groups.google.com/forum/#!topic/metacello/QbpngL6Jhg8 Have a nice day :) -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 29, 2017

Re: [Pharo-dev] Best wishes for 2018

by Esteban Lorenzano

Thanks Torsten, I was about to write a similar mail. Thanks to everybody for allow me to be your âguy to hateâ :) I will continue doing my best to make Pharo a better place for everybody, one step at a time. happy new year! Esteban > On 29 Dec 2017, at 09:39, Torsten Bergmann <astares(a)gmx.de> wrote: > > 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] an error in ZnResourceMetaUtils>>queryKeyValueSafeSet ?

by Esteban Lorenzano

Hi Sven, A POST with this form will fail on twitter api: POST /1.1/statuses/update.json HTTP/1.1 Host: api.twitter.com Content-Type: application/x-www-form-urlencoded Accept: */* Content-Length: 0 User-Agent: Zinc HTTP Components 1.0 (Pharo/7.0) status=testing? It will fail because of the â?â, if I remove ? from save and I encode as this: POST /1.1/statuses/update.json HTTP/1.1 Host: api.twitter.com Content-Type: application/x-www-form-urlencoded Accept: */* Content-Length: 0 User-Agent: Zinc HTTP Components 1.0 (Pharo/7.0) status=testing%3F it will be posted correctly. My doubt if this is a bug in queryKeyValueSafeSet or this is a particular problem on twitter. If the last, I didnât see a good way to change value of safe set for just one case (for now I just override the method, but this is clearly not good ;) ). cheers! Esteban > On 28 Dec 2017, at 13:00, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Esteban, > >> On 28 Dec 2017, at 11:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hi all, Sven >> >> Iâm doing some experiments with twitter and posting and I found that twitter does not accept a post with $? in the status string (it throws an error). Now, if I change ZnResourceMetaUtils>>queryKeyValueSafeSet removing $? from the safe set it works correctly. >> >> the question is: this is a twitter error or a ZnResourceMetaUtils>>queryKeyValueSafeSet error and the $? shouldnât be considered safe (and then it should be percent encoded?) >> >> cheers, >> Esteban > > I know that the last time I did the implementation, we looked very carefully in what characters are safe or not, and had some discussions about it. > > I am not familiar with the API you are trying to use. I am a bit confused by POST and 'status string', while encoding a query part of the URL. It is possible to show exactly the call that you are trying to make ? What does an equivalent curl -v call show ? Could you point to the actual API call documentation ? > > Sven > >

Dec. 29, 2017

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

by Denis Kudriashov

2017-12-29 10:07 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > 2017-12-28 22:29 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> >> 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? >> > > Raw memory file has time for searching for a string in the image 2.1s BUT > if the file is stored on disk, the time is 16.5s so about 10-times slower > than current version. I suppose that the original fast mechanism used > MultiByteFileStream but the new mechanism uses ZnCharacterReadStream. > For file sources we should use ZnBufferedReadStream over ZnCharacterReadStream. It should lead to similar performance as old MultiByteFileStream. > So, in the same conditions the compressed memory stream is almost 5-times > faster than disk access. We should try to find some optimization but I > think that it is not necessary to do it immediately. > > -- Pavel > > >> >> >>> >>> -- 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. 29, 2017

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

by Pavel Krivanek

2017-12-28 22:29 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > > 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? > Raw memory file has time for searching for a string in the image 2.1s BUT if the file is stored on disk, the time is 16.5s so about 10-times slower than current version. I suppose that the original fast mechanism used MultiByteFileStream but the new mechanism uses ZnCharacterReadStream. So, in the same conditions the compressed memory stream is almost 5-times faster than disk access. We should try to find some optimization but I think that it is not necessary to do it immediately. -- Pavel > > >> >> -- 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. 29, 2017

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

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

by Denis Kudriashov

Interesting to compare speed of search operation like "find string in sources" 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

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

by Denis Kudriashov

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. > It is unbelievable that we can have single image file. I think it is very attractive goal for Pharo 7. And it is so close. > > -- 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

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

by Pavel Krivanek

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. -- Pavel 2017-12-28 16:29 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: > Did a successful build of drgeo with this image. However Athens Canvas > broken again (see screenshot). Is it because missing image? There was not > complain during the image build though. Still don't know how to get the > trace of the error log. > > Build image is here[1] in case it is useful. > > Hilaire > > [1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0 > > > > Le 28/12/2017 Ã 15:50, Pavel Krivanek a Ã©crit : > >> >> 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. >> >> > -- > Dr. Geo > http://drgeo.eu > >

Dec. 28, 2017

Re: [Pharo-dev] Simple game framework

by Hilaire

IF there is a Pharo binding for SDL, why not audio from SDSL? Le 25/12/2017 Ã 19:32, ClÃ©ment Bera a Ã©critÂ : > 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

Dec. 28, 2017

Re: [Pharo-dev] Simple game framework

by Hilaire

What is the reason using Cairo over SDSL? Is not SDL just enought? 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

Dec. 28, 2017

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

by Hilaire

Did a successful build of drgeo with this image. However Athens Canvas broken again (see screenshot). Is it because missing image? There was not complain during the image build though.Â Still don't know how to get the trace of the error log. Build image is here[1] in case it is useful. Hilaire [1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0 Le 28/12/2017 Ã 15:50, Pavel Krivanek a Ã©critÂ : > > 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. > -- Dr. Geo http://drgeo.eu

Dec. 28, 2017

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

by Pavel Krivanek

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

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

by Denis Kudriashov

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?) > - 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). > > 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% > 20pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSuccessfulBuild/ > artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip > > Cheers, > -- Pavel > > >

Dec. 28, 2017

PR: Compressed sources inside the object memory

by Pavel Krivanek

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 - 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 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%20pull%20request%20and%20branch%20Pipeline/job/PR-631/ lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip Cheers, -- Pavel

Dec. 28, 2017

Re: [Pharo-dev] an error in ZnResourceMetaUtils>>queryKeyValueSafeSet ?

by Sven Van Caekenberghe

Hi Esteban, > On 28 Dec 2017, at 11:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi all, Sven > > Iâm doing some experiments with twitter and posting and I found that twitter does not accept a post with $? in the status string (it throws an error). Now, if I change ZnResourceMetaUtils>>queryKeyValueSafeSet removing $? from the safe set it works correctly. > > the question is: this is a twitter error or a ZnResourceMetaUtils>>queryKeyValueSafeSet error and the $? shouldnât be considered safe (and then it should be percent encoded?) > > cheers, > Esteban I know that the last time I did the implementation, we looked very carefully in what characters are safe or not, and had some discussions about it. I am not familiar with the API you are trying to use. I am a bit confused by POST and 'status string', while encoding a query part of the URL. It is possible to show exactly the call that you are trying to make ? What does an equivalent curl -v call show ? Could you point to the actual API call documentation ? Sven

Dec. 28, 2017

an error in ZnResourceMetaUtils>>queryKeyValueSafeSet ?

by Esteban Lorenzano

Hi all, Sven Iâm doing some experiments with twitter and posting and I found that twitter does not accept a post with $? in the status string (it throws an error). Now, if I change ZnResourceMetaUtils>>queryKeyValueSafeSet removing $? from the safe set it works correctly. the question is: this is a twitter error or a ZnResourceMetaUtils>>queryKeyValueSafeSet error and the $? shouldnât be considered safe (and then it should be percent encoded?) cheers, Esteban

Dec. 28, 2017

Can't load libgit2 in 7.0 on some major Linux distros

by Martin McClure

Took my first crack at running 7.0 last night. 64-bit, on Linux. Iceberg won't open; says that libgit2 is the wrong version. After some investigation, this is because: It's picking up the system's version of libgit2, not the version included with the vm. This is because: The version included with the VM depends on libcurl-gnutls.so.4. This library is not packed with the VM, nor is it on my system. A bit more investigation shows that although Ubuntu does seem to typically use libcurl-gnutls.so, other distributions (Red Hat / CentOS, Gentoo) do not. My Gentoo system's /usr/lib64/libgit2.so.0.24.6 depends on libcurl.so.4, not on libcurl-gnutls.so.4. I haven't looked at API differences and such, but would it be possible for Pharo to build libgit2 against libcurl instead of against libcurl-gnutls? Libcurl seems to be present on Ubuntu systems as well as on CentOS/RedHat and Gentoo, so might work more widely. Regards, -Martin

Dec. 27, 2017

Re: [Pharo-dev] roundUpTo:? truncatedTo:

by Martin McClure

On 12/26/2017 12:27 PM, Stephane Ducasse wrote: > Hi > > > I'm working on improving the number of named colors we have. > I got this list > And I did the following to convert numbers to float and I want to keep > only max three decimal "float" and "three decimal" are fundamentally incompatible goals. Float is a binary format, not decimal, so you cannot expect results to always be exact in decimal. > > Now I do not get > > 0.9420000000001 roundUpTo: 0.001 There are many numbers that cannot be represented exactly as floats. 1/1000 is one of them: 0.001 > (1/1000)Â Â Â Â Â --->Â true So what you're actually asking for is to round to some multiple of a binary number that is close to, but not quite exactly, 1/1000. Therefore, #roundUpTo: determines (correctly) that the answer should be 943 * 0.001, and computes that, and answers it. But since 0.001 is greater than 1/1000, the result is greater than 943/1000. There are a number of conceivable alternatives, depending on what you want. But here, it's not clear why you want to do rounding at all in this case -- the expense of a float is the same whether rounded or not, so if you want floats I'd leave them unrounded and therefore more accurately approximating the original input numbers. Or if you want them exact, use fractions instead of floats. Regards, -Martin

Dec. 27, 2017

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

by Bernhard Pieber

Hi Esteban, Thanks for asking. My one and only wish is more stability for the stable version, i.e. bug fixes for Pharo 6, especially the VMs but also the image. Thanks for Pharo! Cheers, Bernhard > Am 23.12.2017 um 17:58 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > Hi everybody, > > This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year. > Features, improvements, radical changes, etcâ¦. whatever you want. > > Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :) > > So, letâs those wishes come! > > cheers, > Esteban

Dec. 27, 2017

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

by Cyril Ferlicot D.

On 12/23/2017 06:57 PM, Cyril Ferlicot D. wrote: > On 12/23/2017 05:58 PM, Esteban Lorenzano wrote: >> Hi everybody, >> > > Hi :) > >> This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year. >> Features, improvements, radical changes, etcâ¦. whatever you want. >> > > I'll list the things I wanted the most those last months :) > > - To be able to load a private git project from a private server via > Metacello API > - To be able to depend on a git project from a private server in > BaselineOf/ConfigurationOf > - 64bits vm more recent that does not crash 1/4 of the time (It would > help to deploy apps for some customers with older linux distributions) > - 64bits Windows vm (But as far as I know, there is progress on this > side already) > - Continue to push Iceberg (I am not really specific because I want a > lot on that part. For more details, I open issues on Iceberg repository > often :) ) > > All those points are in the optic to make business with Pharo easier. I also forgot: a real headless :) > >> Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :) >> > > Of course :) > >> So, letâs those wishes come! >> > > Also, I would like to thanks everyone because I really like my Pharo > journey and it would not be possible without you! :) > >> cheers, >> Esteban >> > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 27, 2017

Re: [Pharo-dev] roundUpTo:? truncatedTo:

by Hilaire

My funny was ironical because ;-) : 1. I just learn about this #round: method. 2. it is doing a better job than #roundTo: 3. it is mathematically identical to #roundTo: but use positive power of 10 whereas the former use negative power of 10. I guess it produces a different impact on the internal representation of Float as powers of 2 sum It is doing a better job, it correctly rounds 1.45 to 1.5 and not 1.4: 1.45 roundTo: 0.1 "1.4000000000000001" 1.45 round: 1 "1.5" It looks like the right method to deprecate will be roundTo:, or may be there are cases when one method is better, and vis versa. I am curious. Le 26/12/2017 Ã 23:51, Nicolas Cellier a Ã©critÂ : > Hi Hilaire, > it' not just funny: it's the exact case round: was made for. > Note that there is an opened issue suggesting the removal of round: > (no time to check the exact ref now). -- Dr. Geo http://drgeo.eu

Dec. 27, 2017

Re: [Pharo-dev] Calendrical capabilities

by Stephane Ducasse

Excellent I did not know it. Stef On Wed, Dec 27, 2017 at 1:54 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > There is a port to Pharo (and gemstone) of Chronos here: > > > http://smalltalkhub.com/#!/~Chronos/Chronos > > > I think I last tested it in Pharo 4. > > > > > publius789 wrote >> This is very helpful. Nice holiday weekend reading! >> >> Sure, if its not too much trouble you can send it to me. >> >> Thanks. >> >> Regards, >> Jim >> >> -----Original Message----- >> From: Pharo-dev [mailto: > >> pharo-dev-bounces@.pharo > >> ] On Behalf Of Stephane Ducasse >> Sent: Saturday, December 23, 2017 5:02 PM >> To: Pharo Development List < > >> pharo-dev@.pharo > >> > >> Subject: Re: [Pharo-dev] Calendrical capabilities >> >> Aconcagua is available via the catalog. >> Here is what I found in my harddisc about chronos. >> I can send you the zipped file with old code (probably should be ported to >> Pharo). >> >> >> On Sat, Dec 23, 2017 at 10:32 PM, < > >> publius789@ > >> > wrote: >>> I am new to the Pharo world and looking at capabilities for potential >>> applications. >>> >>> >>> >>> One of the first things I am interested in is Calendar processing >>> capabilities. I havenât had a chance to look at the code yet, but >>> specifically how much does Pharoâs Date/Calendar capabilities match >>> that in the java.util package for Java 9? Additionally, is there any >>> way to give the number of business days between two dates for a >>> particular local calendar? If so, whatâs the format for a local >>> calendar? >>> >>> >>> >>> Iâm going to take a look at the code shortly, but if anyone can shed a >>> general light what currently exists it would be greatly appreciated. >>> >>> >>> >>> Regards, >>> >>> Jim > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Dec. 27, 2017

Re: [Pharo-dev] Distributing native libraries with Metacello

by Stephane Ducasse

Hi ronie We were discussing with guille that we need a notion of project repository so that people can access to external resources once they clone their repo. Right now we can use IceRepository "default". Stef On Wed, Dec 27, 2017 at 2:43 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hi All, > > During the last month I have been doing a massive refactoring to Woden 2. By > using Lowtalk for the math library, the requirement on the Lowcode VM is now > optional. However, there are still some native library dependencies required > for distributing Woden: > - AbstractGpu, a wrapper for graphics API (Vulkan, Metal and D3D12). > - AbstracPhysicsa wrapper for physics engines (Bullet). > > I saw that when loading Bloc via the Metacello script, it does download the > Moz2D dependency. So, I am wondering how I could do the same for Woden?. > > There is also a dependency on the data present in a repository with some > core assets, mostly the required shaders, and some textures. I am also > wondering wondering on how I could tell Metacello to clone this repository, > or download its zip file from GitHub? > > Best regards, > Ronie

Dec. 27, 2017

Re: [Pharo-dev] roundUpTo:? truncatedTo:

by Stephane Ducasse

BTW rountTo: does not solve my problem. I will check the printing solution. On Tue, Dec 26, 2017 at 11:51 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi Hilaire, > it' not just funny: it's the exact case round: was made for. > Note that there is an opened issue suggesting the removal of round: (no time > to check the exact ref now). > > Alternatives if round: is deprecated could be: > > (c / 255 roundTo: 1/1000) asFloat. > (c / 255 roundTo: 0.001s) asFloat. > > I didn't verify if Pharo did change that, but Squeak RGB color components > have 10 bits internally. > 10 bits is 1024. > So rounding to 1/1000 was not enough to distinguish different colors. > > Nicolas > > > > 2017-12-26 22:26 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: >> >> It i s funny to note how #round: message seems to have more success for >> that: >> >> 0.9420000000001 round: 3. >> "0.942" >> >> >> >> Le 26/12/2017 Ã 21:27, Stephane Ducasse a Ã©crit : >>> >>> 0.9420000000001 roundUpTo: 0.001 >>> and the same truncatedTo: 0.001 >>> do not work >> >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >

Dec. 27, 2017

Re: [Pharo-dev] roundUpTo:? truncatedTo:

by Stephane Ducasse

Hi nicolas Thanks for the information of color I was also looking for it. The other packages that extended color used 1/1000 so I followed the pattern. I was thinking that I should use something like "printInexactlyOn:" Now (too early for my brain to work) but I'm wondering the different between round and roundUpTo: I remember that once we discuss having an exact method where we can pass the precision. Stef On Tue, Dec 26, 2017 at 11:51 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi Hilaire, > it' not just funny: it's the exact case round: was made for. > Note that there is an opened issue suggesting the removal of round: (no time > to check the exact ref now). > > Alternatives if round: is deprecated could be: > > (c / 255 roundTo: 1/1000) asFloat. > (c / 255 roundTo: 0.001s) asFloat. > > I didn't verify if Pharo did change that, but Squeak RGB color components > have 10 bits internally. > 10 bits is 1024. > So rounding to 1/1000 was not enough to distinguish different colors. > > Nicolas > > > > 2017-12-26 22:26 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: >> >> It i s funny to note how #round: message seems to have more success for >> that: >> >> 0.9420000000001 round: 3. >> "0.942" >> >> >> >> Le 26/12/2017 Ã 21:27, Stephane Ducasse a Ã©crit : >>> >>> 0.9420000000001 roundUpTo: 0.001 >>> and the same truncatedTo: 0.001 >>> do not work >> >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >

Dec. 27, 2017