- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Crash on GC garbageCollect

by Ben Coman

There was a period where a new GC algorithm had some teething issues, but those were resolved. Where did you get the newest VMs? The one from your report seems old... "VM: 201708271955" What platform are you on? How are your starting your Image? Can you move your development to a fresh download of latest 6.1 Image & VM and report if that has any problems? http://pharo.org/download HTH cheers -ben On 25 May 2018 at 16:24, Andreas Brodbeck <dassi(a)mindclue.ch> wrote: > Hi all > > I have a 6.0 image which crashes on garbage collect. If I run "Smalltalk > garbageCollect" it crashes. The crash log is attached. But I don't really > understand that crash log. I run it with a 6.0 VM, tried it also with > newest 6.1 VM and 7.0 VM, but always the same error. > > I read here in the list about crash problems with GC, memory leaks and > similar, but I really don't see what I could do. > > Any pointers in which direction I could investigate? > > Thanks and cheers, > Andreas > > -- > Andreas Brodbeck > www.mindclue.ch > > >

May 25, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Stephan Eggermont

Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > I was looking at Beacon again to prepare integration. Some changes was > needed in baseline for better granularity. So I send pull request because I > have no permissions. > > But now I remember that we had idea to integrate only core part of Beacon > which requires MemoryLogger and TranscriptLogger. And we wanted to manage > logger backends using separate baselines. So we need separate repos to have > separate versioning. Why would you want separate baselines for that? And on top of that separate repos? Stephan

May 25, 2018

ImageReadWriter and GIFs

by Eric Gade

Hi guys, As mentioned in pharo-users, I am refactoring / fixing the implementation of GIFReadWriter, which currently doesn't work correctly. My primary motivation at the start came because I could not open animated GIFs in the World. I am close to having a solution, but could use some input from more experienced Smalltalkers and also those who have experience with ImageReadWriter and subclasses. # Primary Problem # The main problem I'm having: the whole ImageReadWriter infrastructure assumes it will be dealing with single Forms. GIFs, however, are files that can be packed with *many* images, each often having their own metadata about how they should be colored, positioned, and animated. This has presented me with a bit of a conundrum. I don't want to break Image processing functionality in the tools that already exist (chief example here is the "image previews" that display in an inspector when browsing FileReferences). However, I'm not sure what the best path to take is. So I'll explain what I have so far, and then follow up with some possible ideas about how to move forward. # What I have # 1) I have modified GIFReadWriter to actually read all of the sub-images itself (obviating AnimatedGIFReadWriter, which isn't necessary). These images are stored as "frames" (see 2) 2) Created AnimatedImageFrame, a class that wraps an underlying form with additional flags/information about how it should be processed in an animation 3) Created AnimatedImageMorph, which takes a collection of AnimatedImageFrames and cycles through them according to their rules. Also has information about size etc. # What I'm thinking # The above on its own will not work well in the existing Pharo system. What I'm thinking is that we need a class that decorates/subclasses/or is mostly polymorphic with Form to wrap collections of AnimatedImageFrames -- something to serve as the "model" to the AnimatedImageMorph. We could call it AnimatedImage. One advantage (hopefully) would be compatibility with the existing systems that assume all imported images are Forms. Another would be image manipulation like scaling, flipping, etc -- which looping and applying to all underlying frame forms. It would also give us concretely an object that embodies a GIF image the way a single Form embodies any other kind of image. Is there a better way? Should I just stick with AnimatedImageFrame and AnimatedImageMorph and count on other users/implementors to deal with GIFs differently? Thanks at all for any input / suggestions. -- Eric

May 25, 2018

[Pharo 7.0-dev] Build #951: 21966-bindings-ok-to-use-array-of-associations

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

There is a new Pharo build available! The status of the build #951 was: SUCCESS. The Pull Request #1413 was integrated: "21966-bindings-ok-to-use-array-of-associations" Pull request url: https://github.com/pharo-project/pharo/pull/1413 Issue Url: https://pharo.fogbugz.com/f/cases/21966 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 25, 2018

Beacon for Pharo 7

by Denis Kudriashov

Hi. I was looking at Beacon again to prepare integration. Some changes was needed in baseline for better granularity. So I send pull request because I have no permissions. But now I remember that we had idea to integrate only core part of Beacon which requires MemoryLogger and TranscriptLogger. And we wanted to manage logger backends using separate baselines. So we need separate repos to have separate versioning. What you think to create new org "pharo-logging" for this purpose? It looks like current approach to manage common projects (pharo-vcs, pharo-ide). Another question is what we want: copy of BeaconCore into Pharo or load it separately like Iceberg and Calypso? We can start with loading then we will decide. Best regards, Denis

May 25, 2018

[Pharo 7.0-dev] Build #950: 21925-SharedPool-subclasses-should-not-trigger-class-not-referenced--QA-Rule-if-they-are-used

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

There is a new Pharo build available! The status of the build #950 was: FAILURE. The Pull Request #1381 was integrated: "21925-SharedPool-subclasses-should-not-trigger-class-not-referenced--QA-Rule-if-they-are-used" Pull request url: https://github.com/pharo-project/pharo/pull/1381 Issue Url: https://pharo.fogbugz.com/f/cases/21925 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 25, 2018

Re: [Pharo-dev] [SPAM] feenk log

by Graham＠inspired

"What is more important: To be happy, or to make happy?" My response: âTo be happy by making happyâ! ;) Sent from my iPad > On 25 May 2018, at 13:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > "What is more important: To be happy, or to make happy?"

May 25, 2018

[Pharo 7.0-dev] Build #949: 21965-SmaltlalkImagecompiler--use-globals-as-default-environment-not-just-self

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

There is a new Pharo build available! The status of the build #949 was: FAILURE. The Pull Request #1416 was integrated: "21965-SmaltlalkImagecompiler--use-globals-as-default-environment-not-just-self" Pull request url: https://github.com/pharo-project/pharo/pull/1416 Issue Url: https://pharo.fogbugz.com/f/cases/21965 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 25, 2018

Re: [Pharo-dev] feenk log

by Denis Kudriashov

Hi Tudor. Very impressive progress. I have one question about scrolling support. How it works or is it works with elements which are based on infinite layout like mentioned grid widget? Does grid implemented with PannableElement too? 2018-05-25 14:30 GMT+03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > We were a bit silent the last couple of months. Quite a bit happened in > the meantime, so here is a summary (for more fine grained announcements, > you can follow us on Twitter): > > ---- > Bloc > ---- > > - Scrolling. We finally have a good scrolling support: > https://twitter.com/feenkcom/status/991690465224331264 > This might sound like a trivial feature, but it turns out it is not. We > had a bug that forced us to rethink the support quite deeply in order to be > able to debug it. To do this, we now can simulate time in Bloc, which is > really cool: > https://twitter.com/feenkcom/status/989797367523233797 > https://twitter.com/feenkcom/status/988753142299938817 > (as a side note, the bug we fought with was the last > > - Pannable element is a combination of a scrollable element with a > scalable element, and it offers the possibility either to zoom in/out + > scroll, or to fit screen and resize when the parent resizes. > > - PDF, SVG, PNG, JPG export (based on the underlying Moz2D support): > https://twitter.com/feenkcom/status/976580153802358786 > https://twitter.com/feenkcom/status/976578060429484032 > > - Better curve support: > https://twitter.com/feenkcom/status/990967109193781249 > https://twitter.com/feenkcom/status/990971530615107584 > > - Better debugging support for understanding bounds: > https://twitter.com/feenkcom/status/989138457288167424 > > ---- > Brick > ---- > > - We now have simple list and columned list widgets. The list is both fast > and scalable and supports rows of variable heights: > https://twitter.com/feenkcom/status/984744251920658432 > https://twitter.com/feenkcom/status/984143821192744961 > > - Basic tab widget: > https://twitter.com/feenkcom/status/974420432240685062 > > - Looks: a mechanism for specifying element-specific composition and > interaction. > > ---- > GT > ---- > > - Documenter saw some major improvements. Just a reminder, Documenter is > the tool that enables live programming and previews directly within Pillar > documents. > We now have a capability similar to notebooks like Jupyter: > https://twitter.com/feenkcom/status/996310432225820672 > We use it extensively to document our code. For example, here is a > tutorial about playing with looks in Bloc: > https://twitter.com/feenkcom/status/973899862482866176 > And we can also express whole tutorials based on Epicea: > https://twitter.com/feenkcom/status/999975333972541440 > > - Diagrammer. We now have better editing support for detailed things such > as arrow head: > https://twitter.com/feenkcom/status/976341449267531776 > While Diagrammer is apparently a tool for diagrams, it has a rather > generic design that can be utilized for all sorts of use cases. For > example, one side effect is that now all elements can be visually edited: > https://twitter.com/feenkcom/status/982656456968241152 > > - Mondrian: Using the new pannable element, we can now zoom in/out and > scroll, and we can also set element to fit screen. We can also drag > elements around. > > - Inspector: we now have an initial support for multiple views associated > with an object. The support is similar to the one from the current > inspector. > > > Have fun, > The feenk team > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > > >

May 25, 2018

feenk log

by Tudor Girba

Hi, We were a bit silent the last couple of months. Quite a bit happened in the meantime, so here is a summary (for more fine grained announcements, you can follow us on Twitter): ---- Bloc ---- - Scrolling. We finally have a good scrolling support: https://twitter.com/feenkcom/status/991690465224331264 This might sound like a trivial feature, but it turns out it is not. We had a bug that forced us to rethink the support quite deeply in order to be able to debug it. To do this, we now can simulate time in Bloc, which is really cool: https://twitter.com/feenkcom/status/989797367523233797 https://twitter.com/feenkcom/status/988753142299938817 (as a side note, the bug we fought with was the last - Pannable element is a combination of a scrollable element with a scalable element, and it offers the possibility either to zoom in/out + scroll, or to fit screen and resize when the parent resizes. - PDF, SVG, PNG, JPG export (based on the underlying Moz2D support): https://twitter.com/feenkcom/status/976580153802358786 https://twitter.com/feenkcom/status/976578060429484032 - Better curve support: https://twitter.com/feenkcom/status/990967109193781249 https://twitter.com/feenkcom/status/990971530615107584 - Better debugging support for understanding bounds: https://twitter.com/feenkcom/status/989138457288167424 ---- Brick ---- - We now have simple list and columned list widgets. The list is both fast and scalable and supports rows of variable heights: https://twitter.com/feenkcom/status/984744251920658432 https://twitter.com/feenkcom/status/984143821192744961 - Basic tab widget: https://twitter.com/feenkcom/status/974420432240685062 - Looks: a mechanism for specifying element-specific composition and interaction. ---- GT ---- - Documenter saw some major improvements. Just a reminder, Documenter is the tool that enables live programming and previews directly within Pillar documents. We now have a capability similar to notebooks like Jupyter: https://twitter.com/feenkcom/status/996310432225820672 We use it extensively to document our code. For example, here is a tutorial about playing with looks in Bloc: https://twitter.com/feenkcom/status/973899862482866176 And we can also express whole tutorials based on Epicea: https://twitter.com/feenkcom/status/999975333972541440 - Diagrammer. We now have better editing support for detailed things such as arrow head: https://twitter.com/feenkcom/status/976341449267531776 While Diagrammer is apparently a tool for diagrams, it has a rather generic design that can be utilized for all sorts of use cases. For example, one side effect is that now all elements can be visually edited: https://twitter.com/feenkcom/status/982656456968241152 - Mondrian: Using the new pannable element, we can now zoom in/out and scroll, and we can also set element to fit screen. We can also drag elements around. - Inspector: we now have an initial support for multiple views associated with an object. The support is similar to the one from the current inspector. Have fun, The feenk team -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

May 25, 2018