- Pharo-dev - lists.pharo.org

CodeCity and Spec

by Yuriy Tymchuk

Hi all, are there any suggestions for integrating CodeCity into Spec? E.g. using CodeCity visualisation in a view build by Spec. Uko

June 13, 2014

Re: [Pharo-dev] [website] new news entry: talk NDC Oslo

by Sven Van Caekenberghe

On 13 Jun 2014, at 09:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: > If the fonts get much larger, having several panes side-by-side makes things look ugly and you kind of lose the perspective :(. I think the GTTools take up too much screen space. I know that today we have bigger screens and we should use them, but still. This is of course a subjective opinion, a feeling.

June 13, 2014

Re: [Pharo-dev] [website] new news entry: talk NDC Oslo

by Tudor Girba

The room was flat with several monitors around, and people could see well (I tested beforehand). If the fonts get much larger, having several panes side-by-side makes things look ugly and you kind of lose the perspective :(. That is why I am so looking forward for Bloc (so that I can scale things nicely) :). Cheers, Doru On Fri, Jun 13, 2014 at 7:50 AM, stepharo <stepharo(a)free.fr> wrote: > Hi doru > > did you get problems with the fonts? Because I was wondering why you did > not make them a bit larger. > > Stef > > On 11/6/14 16:10, Tudor Girba wrote: > > Thanks :). > > Just some background information: > > As you can see, I used the GTInspector to show the liveliness of the > system. I actually used the Moose image + some other goodies (like Seaside, > Postgres connection and a couple of others). I tried this story for the > first time, and while it still needs a bit of polishing, I think it works > well on two levels: > - you can use it as an argument for people to start adopting Pharo as a > programming platform by emphasizing the liveliness, > - but at the same time you can use the same demo to show how using Pharo > can replace scripting, querying and charting tools for common tasks like > string, file system or db manipulation. This in itself is a niche that we > can tap on. > > The result was that people actually got excited, and the message rippled > a bit and I got to do several other demos outside the public session. > > Every step you saw in the demo is setup through a script that gets > triggered from the world menu. These scripts spawns windows and sets the > state of objects. It's really simple, but it accelerates the demo. My goal > is to get a demo that can be repeated by others in other contexts out of > the box. There are still some setup issues, but once I get it done, I will > make it more public. In the meantime, if you want to contribute or play > with it you can use the following script in a Moose image: > > Gofer new > smalltalkhubUser: 'PharoExtras' project: 'PostgresV2'; > configuration; > load. > (#ConfigurationOfPostgresV2 asClass project version: '2.0-baseline') load. > > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-PostgresV2'; > package: 'GT-InspectorExtensions-XML'; > load. > > Gofer new > smalltalkhubUser: 'RichardWettel' project: 'CodeCity'; > configuration; > loadDevelopment. > > Gofer new > smalltalkhubUser: 'PharoExtras' project: 'MorphExamplesAndDemos'; > package: 'MorphExamplesAndDemos'; > load. > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-MorphExamplesAndDemos'; > load. > > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-Scenery'; > load. > > > Cheers, > Doru > > > > On Wed, Jun 11, 2014 at 11:31 AM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> very good presentation that clearly shows the capabilities of Pharo. If >> that does not convince people to use / try pharo, nothing will :) >> >> >> On Wed, Jun 11, 2014 at 11:33 AM, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >> >>> Hi, >>> >>> I added a new entry: >>> >>> http://pharo.org/news/playing-with-live-objects >>> >>> >>> Marcus >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

June 13, 2014

Re: [Pharo-dev] Spur Squeak Trunk Image Available

by Eliot Miranda

On Thu, Jun 12, 2014 at 10:48 PM, stepharo <stepharo(a)free.fr> wrote: > Thanks eliot. > As soon as it is available for Pharo we will try with some large moose > images. > OK, but just so you know I'm not going to do the Pharo bootstrap. I hope someone in your team will have a go. I'm happy to help but I don't know Pharo well enough to do this. It's a matter of making sure the Monticelo packages can be edited. The Squeak code may just work but I wouldn't know. > > Stef > > > On 13/6/14 01:41, Eliot Miranda wrote: > >> Hi All, >> >> it gives me great pleasure to let you know that a spur-format trunk >> Squeak image is finally available at http://www.mirandabanda.org/ >> files/Cog/SpurImages/. Spur VMs are available at >> http://www.mirandabanda.org/files/Cog/VM/VM.r2987/. >> >> Spur is a new object representation and garbage collector for >> Squeak/Pharo/Croquet/Newspeak. >> >> Features >> The object representation is significantly simpler than the existing one, >> and hence permits a lot of JIT optimizations, in particular allocating >> objects in machine code. This speeds up new, new: et al, but also speeds >> up blocks because contexts and closures are now allocated in machine code. >> It also provides immediate characters, so for example accessing wide >> strings is much faster in Spur, since characters do not have to be >> instantiated to represent characters with codes greater than 255. >> >> The garbage collector has a scavenger and a global scan-mark-compact >> collector. The scavenger is significantly faster than the existing >> pointer-reversal scan-mark-compact, hence GC performance is much improved. >> >> The memory manager manages old space as a sequence of segments, as >> opposed to the single contiguous space provided by the existing memory >> manager. The memory manager grows the heap a segment at a time, and can >> and will release empty segments back to the host OS after a full GC. Hence >> Spur is able to grow the heap to the limit of available memory without one >> having to specify the VM's memory size at start-up. >> >> The object representation uses "lazy forwarding" to implement become:, >> creating copies of objects that are becommed, and forwarding the existing >> objects to the copies. While Spur still scans the stack zone on become to >> ensure no forwarding pointers to the receiver exist in stack frames (for >> check-free push and store instance variable operations), it does not scan >> the entire heap, catching sends to forwarded objects as part of the normal >> message send class checks, hence following forwarding pointers lazily, and >> eliminating forwarders during GC. The existing memory manager does a full >> memory sweep and compact to implement become. Hence Spur provides the >> performance advantages of direct pointers while providing a significantly >> faster become. >> >> While Spur uses moving GC (scavenging and compaction on full GC), just >> like the existing memory manager, Spur supports pinning, the ability to >> stop an object from moving. Old space objects will not be moved if pinned. >> Attempting to pin a new space object causes a become, forwarding the new >> space object to a pinned copy in old space. This allows simpler >> interfacing with foreign code through the FFI, since one can hand out >> references to pinned objects in the knowledge that they will not be moved >> by the GC. >> >> Finally Spur supports ephemerons in a simple and direct way, providing >> pre-mortem per-instance finalization. Although the image-level support >> needs to be written, it should soon be possible to improve the finalization >> of entities such as buffered files (ensuring they are flushed before being >> GCed), etc. >> >> >> Future Work >> Spur is as yet a work in progress. The 32-bit implementation is usable >> and appears stable. The major missing component is an incremental >> scan-mark GC that should eliminate long pauses due to the global >> scan-mark-compact GC (which is still invoked at snapshot time). I hope to >> start on this soon. But another key facet of Spur is that the object >> header format and the sizes of objects are common between 32- and 64-bits. >> In 32-bit and 64-bit Spur, object bodies are multiples of 8 bytes, so >> there may be an unused slot at the end of a 32-bit object with an odd >> number of slots. Hence Spur is close to providing a "true" 64-bit system, >> one with 61-bit SmallIntegers, and 61-bit SmallFloats (objects with the >> same precision, but less range that 64-bit Float, done by stealing bits >> from the exponent field). I look forward to collaborating with Esteban >> Lorenzano on 64-bit Spur and hope that it will be available early next year. >> >> >> Experience >> I am of course interested in reports of performance effects. Under >> certain, hopefully rare circumstances, Spur may actually be slower (one is >> when the number of processes involved in process switching exceeds the >> number of stack pages in the stack zone). But my limited experience is >> that Spur is significantly faster than the existing VM. Please post >> experiences, both positive and negative. >> >> Finally, caveat emptor! This is alpha code. Bugs may result in image >> corruption. If you do use Spur, please try and back up your work just in >> case. And if anything does go wrong please let me know, preferrably >> providing a reproducible case. >> >> >> Enjoy! >> Eliot Miranda >> > > > -- best, Eliot

June 13, 2014

Re: [Pharo-dev] Performance for Video Games(Woden Video)

by ClÃ©ment Bera

This is very good. As Doru said, please show something at Esug. 3D graphics are always very nice to show. 2014-06-13 6:51 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Very nice! > > Will you be showing some of these at ESUG? > > Doru > > > On Fri, Jun 13, 2014 at 5:16 AM, Ronie Salgado <roniesalg(a)gmail.com> > wrote: > >> I am working on making a video game engine in Pharo. Recently added a FPS >> counter and recorded some samples: http://youtu.be/-2ida5Q1mbg . >> >> Lets say I was quite surprised, so I have yet a lot more to optimize, but >> a good trick seems to be making some computation in the GPU. >> >> In this video, I show 6 early examples. The water example is still >> incomplete, missing reflection/refractions, but it shows what happens when >> I compute the water waves using a shader in the GPU. >> >> Please, pay a close attention to the FPS count. >> >> BTW, it feels slow because of the screen capture and the tearing is there >> because I haven't enabled vsync, but I have support for it. >> >> Greetings, >> Ronie Salgado >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

June 13, 2014

Re: [Pharo-dev] HowToMakeYourOwnTutorial, how to launch my own?

by Serge Stinckwich

On Thu, Jun 12, 2014 at 3:06 PM, Marc-Philippe Huget <mphuget(a)gmail.com> wrote: > Hello everybody, Hi Marc-Philippe, > I try to do a tutorial for our project and I decided to use ProfStef, so I > follow the instructions as given in HowToMakeYourOwnTutorial, so > * no problem to create a class inheriting from AbstractClass > * creating two protocols lessons and tutorial > * a method tutorial returning the list of tutorials as an array > * a method per tutorial > > My only problem is regarding running this tutorial > In ProfStef, we do ProfStef go but here, go is not recognized > If I change from AbstractTutorial to PharoTutorial, I obviously have go, > goOn and next but this is not my tutorial > > I guess this is a problem of player, but how? Thanks in advance for your > help If you want to made a Tutorial, you have to take a look also on the work of Stephan Eggermont. He send a message on the ml recently about that: http://forum.world.st/Support-for-demos-td4742101.html I'm also interested to use his work, let's try to share. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 13, 2014

Re: [Pharo-dev] HowToMakeYourOwnTutorial, how to launch my own?

by Max Leske

On 12.06.2014, at 15:06, Marc-Philippe Huget <mphuget(a)gmail.com> wrote: > Hello everybody, > > I try to do a tutorial for our project and I decided to use ProfStef, so I follow the instructions as given in HowToMakeYourOwnTutorial, so > * no problem to create a class inheriting from AbstractClass > * creating two protocols lessons and tutorial > * a method tutorial returning the list of tutorials as an array > * a method per tutorial > > My only problem is regarding running this tutorial > In ProfStef, we do ProfStef go but here, go is not recognized > If I change from AbstractTutorial to PharoTutorial, I obviously have go, goOn and next but this is not my tutorial > > I guess this is a problem of player, but how? Thanks in advance for your help > > Regards, > mph > Assuming your new tutorial class is named MyNewTutorial, you simply run PharoTurorial goOn: MyNewTutorial And if you want it to be a bit nicer to look at, you can add a #go method on the class side: MyNewTutorial class compile: 'go PharoTutorial goOn: selfâ HTH, Max

June 13, 2014

Re: [Pharo-dev] [website] new news entry: talk NDC Oslo

by stepharo

Hi doru did you get problems with the fonts? Because I was wondering why you did not make them a bit larger. Stef On 11/6/14 16:10, Tudor Girba wrote: > Thanks :). > > Just some background information: > > As you can see, I used the GTInspector to show the liveliness of the > system. I actually used the Moose image + some other goodies (like > Seaside, Postgres connection and a couple of others). I tried this > story for the first time, and while it still needs a bit of polishing, > I think it works well on two levels: > - you can use it as an argument for people to start adopting Pharo as > a programming platform by emphasizing the liveliness, > - but at the same time you can use the same demo to show how using > Pharo can replace scripting, querying and charting tools for common > tasks like string, file system or db manipulation. This in itself is a > niche that we can tap on. > > The result was that people actually got excited, and the message > rippled a bit and I got to do several other demos outside the public > session. > > Every step you saw in the demo is setup through a script that gets > triggered from the world menu. These scripts spawns windows and sets > the state of objects. It's really simple, but it accelerates the demo. > My goal is to get a demo that can be repeated by others in other > contexts out of the box. There are still some setup issues, but once I > get it done, I will make it more public. In the meantime, if you want > to contribute or play with it you can use the following script in a > Moose image: > > Gofer new > smalltalkhubUser: 'PharoExtras' project: 'PostgresV2'; > configuration; > load. > (#ConfigurationOfPostgresV2 asClass project version: '2.0-baseline') load. > > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-PostgresV2'; > package: 'GT-InspectorExtensions-XML'; > load. > > Gofer new > smalltalkhubUser: 'RichardWettel' project: 'CodeCity'; > configuration; > loadDevelopment. > > Gofer new > smalltalkhubUser: 'PharoExtras' project: 'MorphExamplesAndDemos'; > package: 'MorphExamplesAndDemos'; > load. > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-MorphExamplesAndDemos'; > load. > > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-Scenery'; > load. > > > Cheers, > Doru > > > > On Wed, Jun 11, 2014 at 11:31 AM, kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>> wrote: > > very good presentation that clearly shows the capabilities of > Pharo. If that does not convince people to use / try pharo, > nothing will :) > > > On Wed, Jun 11, 2014 at 11:33 AM, Marcus Denker > <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > Hi, > > I added a new entry: > > http://pharo.org/news/playing-with-live-objects > > > Marcus > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

June 13, 2014

Re: [Pharo-dev] Spur Squeak Trunk Image Available

by stepharo

Thanks eliot. As soon as it is available for Pharo we will try with some large moose images. Stef On 13/6/14 01:41, Eliot Miranda wrote: > Hi All, > > it gives me great pleasure to let you know that a spur-format > trunk Squeak image is finally available at > http://www.mirandabanda.org/files/Cog/SpurImages/. Spur VMs are > available at http://www.mirandabanda.org/files/Cog/VM/VM.r2987/. > > Spur is a new object representation and garbage collector for > Squeak/Pharo/Croquet/Newspeak. > > Features > The object representation is significantly simpler than the existing > one, and hence permits a lot of JIT optimizations, in particular > allocating objects in machine code. This speeds up new, new: et al, > but also speeds up blocks because contexts and closures are now > allocated in machine code. It also provides immediate characters, so > for example accessing wide strings is much faster in Spur, since > characters do not have to be instantiated to represent characters with > codes greater than 255. > > The garbage collector has a scavenger and a global scan-mark-compact > collector. The scavenger is significantly faster than the existing > pointer-reversal scan-mark-compact, hence GC performance is much improved. > > The memory manager manages old space as a sequence of segments, as > opposed to the single contiguous space provided by the existing memory > manager. The memory manager grows the heap a segment at a time, and > can and will release empty segments back to the host OS after a full > GC. Hence Spur is able to grow the heap to the limit of available > memory without one having to specify the VM's memory size at start-up. > > The object representation uses "lazy forwarding" to implement become:, > creating copies of objects that are becommed, and forwarding the > existing objects to the copies. While Spur still scans the stack zone > on become to ensure no forwarding pointers to the receiver exist in > stack frames (for check-free push and store instance variable > operations), it does not scan the entire heap, catching sends to > forwarded objects as part of the normal message send class checks, > hence following forwarding pointers lazily, and eliminating forwarders > during GC. The existing memory manager does a full memory sweep and > compact to implement become. Hence Spur provides the performance > advantages of direct pointers while providing a significantly faster > become. > > While Spur uses moving GC (scavenging and compaction on full GC), just > like the existing memory manager, Spur supports pinning, the ability > to stop an object from moving. Old space objects will not be moved if > pinned. Attempting to pin a new space object causes a become, > forwarding the new space object to a pinned copy in old space. This > allows simpler interfacing with foreign code through the FFI, since > one can hand out references to pinned objects in the knowledge that > they will not be moved by the GC. > > Finally Spur supports ephemerons in a simple and direct way, providing > pre-mortem per-instance finalization. Although the image-level > support needs to be written, it should soon be possible to improve the > finalization of entities such as buffered files (ensuring they are > flushed before being GCed), etc. > > > Future Work > Spur is as yet a work in progress. The 32-bit implementation is > usable and appears stable. The major missing component is an > incremental scan-mark GC that should eliminate long pauses due to the > global scan-mark-compact GC (which is still invoked at snapshot time). > I hope to start on this soon. But another key facet of Spur is that > the object header format and the sizes of objects are common between > 32- and 64-bits. In 32-bit and 64-bit Spur, object bodies are > multiples of 8 bytes, so there may be an unused slot at the end of a > 32-bit object with an odd number of slots. Hence Spur is close to > providing a "true" 64-bit system, one with 61-bit SmallIntegers, and > 61-bit SmallFloats (objects with the same precision, but less range > that 64-bit Float, done by stealing bits from the exponent field). I > look forward to collaborating with Esteban Lorenzano on 64-bit Spur > and hope that it will be available early next year. > > > Experience > I am of course interested in reports of performance effects. Under > certain, hopefully rare circumstances, Spur may actually be slower > (one is when the number of processes involved in process switching > exceeds the number of stack pages in the stack zone). But my limited > experience is that Spur is significantly faster than the existing VM. > Please post experiences, both positive and negative. > > Finally, caveat emptor! This is alpha code. Bugs may result in image > corruption. If you do use Spur, please try and back up your work just > in case. And if anything does go wrong please let me know, > preferrably providing a reproducible case. > > > Enjoy! > Eliot Miranda

June 13, 2014

Re: [Pharo-dev] Performance for Video Games(Woden Video)

by Tudor Girba

Very nice! Will you be showing some of these at ESUG? Doru On Fri, Jun 13, 2014 at 5:16 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > I am working on making a video game engine in Pharo. Recently added a FPS > counter and recorded some samples: http://youtu.be/-2ida5Q1mbg . > > Lets say I was quite surprised, so I have yet a lot more to optimize, but > a good trick seems to be making some computation in the GPU. > > In this video, I show 6 early examples. The water example is still > incomplete, missing reflection/refractions, but it shows what happens when > I compute the water waves using a shader in the GPU. > > Please, pay a close attention to the FPS count. > > BTW, it feels slow because of the screen capture and the tearing is there > because I haven't enabled vsync, but I have support for it. > > Greetings, > Ronie Salgado > -- www.tudorgirba.com "Every thing has its own flow"

June 13, 2014