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

Re: [Pharo-dev] Simple game framework

by Stephane Ducasse

This code can be just in a method of subclass of BlGameElement. You should really try because Bloc is really nice. And this is not a layer this is the future Morphic. Now if you work on SDL instead of Athens (remember Athens is an API) when we will change SDL for the next low level framework you will have to change. Stef On Mon, Jan 1, 2018 at 5:50 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi Stef, > > A complete port of the SDL capabilities > (http://wiki.libsdl.org/Introduction) will be super nice (audio) and > improved stability. > > For your students, the perspective on the game is likely 2 months, may be 6 > months; you know I have longer perspective - DrGeo was slowly developed and > crafted for 20 years; therefore stability on the code is very important for > me as I will have to work over long period. That's the reason I don't fell > at ease relying on many code layers. For your students, as the horizon is > counted in months it is a null consideration, not for me. Not to mention > there are uncertainty over this layers. Moreover these layers will make hard > to my student to understand what's going on, if they want to dig in. > > I am not sure how far will get me this reflexion, but for my students, I can > imagine different models of 2D games: board games, horizontal/vertical > scrolling games, isometric games. Each one can be optimized differently. > Banks of sprites and audio will be already there to get started the > students. The models will encapsulate SDL, as PyGame is doing, but still > easilly accessible. > > I imagine such an environment to rely only on two layers: SDL and spec, the > later if some dedicated user interface is needed for the game designer; but > a lot should happen in the class browser. > > I found this Python PyGame code bellow rather easy to understand. Will it be > possible to produce an equally understandable Smalltalk code with the layers > your are proposing? > > importsys,pygamepygame.init()size=width,height=320,240speed=[2,2]black=0,0,0screen=pygame.display.set_mode(size)ball=pygame.image.load("ball.bmp")ballrect=ball.get_rect()while1:foreventinpygame.event.get():ifevent.type==pygame.QUIT:sys.exit()ballrect=ballrect.move(speed)ifballrect.left<0orballrect.right>width:speed[0]=-speed[0]ifballrect.top<0orballrect.bottom>height:speed[1]=-speed[1]screen.fill(black)screen.blit(ball,ballrect)pygame.display.flip() > > > Hilaire > > Your time stamp bellow is a strike! ;) > vvvvvvvvvvvvvvvvvvvvvv > > Le 01/01/2018 Ã 00:00, Stephane Ducasse a Ã©crit : >> >> 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 >>> >>> >>> > > -- > Dr. Geo > http://drgeo.eu > > >

Jan. 2, 2018

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

by Stephane Ducasse

Hi henry I had problems to compare the two versions because they are probably on multiple mails. Could you email it? Because convenient methods are important but I do not see the point. Stef (in my constant quest for the better) On Tue, Jan 2, 2018 at 1:13 PM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Stephane Ducasse-3 wrote >> 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@ > >> > 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 > > Maybe it's just me, but I'd a big fan of convenience methods over explicit > stacking when it comes to multi-layer streams. > - It documents the intended/valid ways to stack (such as which streams it > makes sense to wrap in a ZnCrPortableWriteStream, or which streams one > normally would want to #buffered:do:) > - It makes the transition (in terms of conciseness) from "traditional" > filestreams less jarring (provided convenience methods provide sensible > defaults). > > Say, for instance, a #withEncoding:do:* on read/writeStream, so instead of > the above, one can do: > > fileName := FileSystem disk checkName: fileName fixErrors: true. > (outputStream :=(File named: fileName) writeStream) > withEncoding: 'utf8' > do: [:encodedWriteStream | > encodedWriteStream nextPutAll: aStream contents]. > outputStream close. > > and > aFileReference writeStreamDo: [ :outputStream | > outputStream withEncoding: 'utf8' do: [:encodedStream | > encodedStream nextPutAll: aStream contents. ]]. > or > input := aFileReference readStreamDo: [ :inputStream | > inputStream withEncoding: 'utf8' do: [:decodingStream | > decodingStream contents]] > > It's more involved than the current multibytestreams, but takes away the > burden of determining the correct stack of ZnStreams for the common case. > For instance, you'd normally want file write streams to also be wrapped by a > buffered stream, and have a single flush at end of withEncoding:do:, while > the same isn't necessary for withEncoding:do: on the base WriteStream class. > > Cheers, > Henry > > *Bad name, I know, but you get the point. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Jan. 2, 2018

[Pharo 7.0-dev] Build #400: 20891-Changesorter-should-prompt-with-a-file-dialog

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

There is a new Pharo build available! The status of the build #400 was: SUCCESS. The Pull Request #628 was integrated: "20891-Changesorter-should-prompt-with-a-file-dialog" Pull request url: https://github.com/pharo-project/pharo/pull/628 Issue Url: https://pharo.fogbugz.com/f/cases/20891 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 2, 2018

[Pharo 7.0-dev] Build #399: 20899-Add-comments-to-Color-methods

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

There is a new Pharo build available! The status of the build #399 was: SUCCESS. The Pull Request #633 was integrated: "20899-Add-comments-to-Color-methods" Pull request url: https://github.com/pharo-project/pharo/pull/633 Issue Url: https://pharo.fogbugz.com/f/cases/20899 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 2, 2018

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

by Henrik Sperre Johansen

Stephane Ducasse-3 wrote > 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@ > > 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 Maybe it's just me, but I'd a big fan of convenience methods over explicit stacking when it comes to multi-layer streams. - It documents the intended/valid ways to stack (such as which streams it makes sense to wrap in a ZnCrPortableWriteStream, or which streams one normally would want to #buffered:do:) - It makes the transition (in terms of conciseness) from "traditional" filestreams less jarring (provided convenience methods provide sensible defaults). Say, for instance, a #withEncoding:do:* on read/writeStream, so instead of the above, one can do: fileName := FileSystem disk checkName: fileName fixErrors: true. (outputStream :=(File named: fileName) writeStream) withEncoding: 'utf8' do: [:encodedWriteStream | encodedWriteStream nextPutAll: aStream contents]. outputStream close. and aFileReference writeStreamDo: [ :outputStream | outputStream withEncoding: 'utf8' do: [:encodedStream | encodedStream nextPutAll: aStream contents. ]]. or input := aFileReference readStreamDo: [ :inputStream | inputStream withEncoding: 'utf8' do: [:decodingStream | decodingStream contents]] It's more involved than the current multibytestreams, but takes away the burden of determining the correct stack of ZnStreams for the common case. For instance, you'd normally want file write streams to also be wrapped by a buffered stream, and have a single flush at end of withEncoding:do:, while the same isn't necessary for withEncoding:do: on the base WriteStream class. Cheers, Henry *Bad name, I know, but you get the point. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 2, 2018

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

by Sven Van Caekenberghe

> On 31 Dec 2017, at 16:01, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > I created a pull request to fix it: > https://github.com/pharo-project/pharo/pull/632 This implementation (which is not using #position) is acceptable. Nice tests. I am still a bit puzzled by the usefulness of this method though.

Jan. 2, 2018

Re: [Pharo-dev] Simple game framework

by Hilaire

Jan. 1, 2018

Re: [Pharo-dev] Simple game framework

by Hilaire

Hi Stef, A complete port of the SDL capabilities (http://wiki.libsdl.org/Introduction) will be super nice (audio) and improved stability. For your students, the perspective on the game is likely 2 months, may be 6 months; you know I have longer perspective - DrGeo was slowly developed and crafted for 20 years; therefore stability on the code is very important for me as I will have to work over long period. That's the reason I don't fell at ease relying on many code layers. For your students, as the horizon is counted in months it is a null consideration, not for me. Not to mention there are uncertainty over this layers. Moreover these layers will make hard to my student to understand what's going on, if they want to dig in. I am not sure how far will get me this reflexion, but for my students, I can imagine different models of 2D games: board games, horizontal/vertical scrolling games, isometric games. Each one can be optimized differently. Banks of sprites and audio will be already there to get started the students. The models will encapsulate SDL, as PyGame is doing, but still easilly accessible. I imagine such an environment to rely only on two layers: SDL and spec, the later if some dedicated user interface is needed for the game designer; but a lot should happen in the class browser. I found this Python PyGame code bellow rather easy to understand. Will it be possible to produce an equally understandable Smalltalk code with the layers your are proposing? importsys,pygamepygame.init()size=width,height=320,240speed=[2,2]black=0,0,0screen=pygame.display.set_mode(size)ball=pygame.image.load("ball.bmp")ballrect=ball.get_rect()while1:foreventinpygame.event.get():ifevent.type==pygame.QUIT:sys.exit()ballrect=ballrect.move(speed)ifballrect.left<0orballrect.right>width:speed[0]=-speed[0]ifballrect.top<0orballrect.bottom>height:speed[1]=-speed[1]screen.fill(black)screen.blit(ball,ballrect)pygame.display.flip() Hilaire Your time stamp bellow is a strike! ;) Â Â vvvvvvvvvvvvvvvvvvvvvv Le 01/01/2018 Ã 00:00, Stephane Ducasse a Ã©critÂ : > 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 >> >> >> -- Dr. Geo http://drgeo.eu

Jan. 1, 2018

upToAll: for ZnCharacterReadStream

by Bernhard Pieber

I have created another pull request with an implementation for #upToAll: for ZnCharacterReadStream: https://github.com/pharo-project/pharo/pull/634 Here is the case: https://pharo.fogbugz.com/f/cases/20905 CI checks are in progress. Does that make it the first contribution in 2018? ;-) Let me know what you think. Happy New Year Bernhard

Jan. 1, 2018

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

by Norbert Hartl

To be honest this is a beta virtual swarm where the exact number of deployed images is. It is less load here because it is beta. The production swarm has more machines. But the images are restricted to 128 MB heap and the machine has 64 GB memory. So no problem! Norbert > Am 01.01.2018 um 14:04 schrieb Bernhard Pieber <bernhard(a)pieber.com>: > > And all on one machine?! Wow. > > Happy New Year > Bernhard > >> Am 31.12.2017 um 14:18 schrieb Norbert Hartl <norbert(a)hartl.name>: >> >> 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

Jan. 1, 2018