October 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Le 11 oct. 2015 Ã 18:42, Dale Henrichs a Ã©crit : > > > On 10/11/15 12:19 AM, stepharo wrote: >> >> >> Le 11/10/15 00:40, Dale Henrichs a Ã©crit : >>> Christophe, >>> >>> I still don't have a lot of time to read the paper and try to understand what you are trying to accomplish, >> you should read it. :) >> We wrote it for that and it is not boring nor long. > I scanned through it at the time and as I recall, I thought that the functionality described was already covered by git and BaselineOf ... but I did not read it in great detail and I did not (and still don't) have the time to compose a long-winded response:) >> >>> but I am curious how you think "package dependencies" will play with git-based projects? >>> >>> In git-based repositories I don't think you have the same type of dependency issues that one might have with monticello repositories --- In a monticello repository you have a whole range of possible package versions to pick from, but in a git-based repository the range of package versions is fixed to those that are committed together so the packages that are meant to work together are committed together. >> >> I think that this is only true for packages committed within the same repo. >> Now between porjects published in different repo you have to express them. >> I do not think that we all want to publish in the same repo and clone out everything. > ... and inter-project dependencies is what a BaselineOf does .... which brings me back to the conclusion that I reached when I scanned the paper:) >>> >>> In the bootstrap scenario, you would only have one version per package to choose from, so the packages that are meant to work together are committed together .... >>> >>> I guess I don't know what you mean when you say: >>>> we want to decouple a released version of a package from the working copy of the package version description (implies the creation of a package repository + a web interface on top of it to promote/search packages). >>> Perhaps a description of the problem being solved would help me understand. >> We want to be able to have a package market place where tools can grab dependencies without to load code >> and can compute the set of packages that should be loaded. >> >> When a package is released into the market: then it externalise its metadata so that a crawler can automatically build >> dependency graph and create specific distribution. > Okay. This is a problem .... but it happens to be a problem that Metacello "can solve/does solve" - so there must be something else (a deeper problem?) that I don't quite understand. > > With that said, if you are planning to replace Metacello, then I am excited:) But I will repeat that I hope that you are considering cross platform issues ... > > Perhaps at this point in time, I'd like to read some code. Then I can skip reading the paper and get a feel for how hard it will be to port to GemStone:) Well, the point is not to replace metacello but to go towards a per package metadata description allowing some flexibility with the introduction of virtual packages. This will allow, in a first time, to set up a package repository and more important, a web site on top of it. In a second time, I also want to enable more flexibility in expressing dependencies constraints (eg. > 2.0, 3.*, etc.). To achieve that, you need a very performant dependency solver and I would like to reuse linux ones (it has be done for ocaml by example) through CUDF (check http://mancoosi.org/) For now, I implemented a simple solver for static dependency constraints (=1.2). I checked Metacello implementation and it looked to me that approaches are a bit too far to be able to reuse the whole code. For sure, it is not as robust as Metacello is, because you enhanced it for years. What I want now, is to experiment (let's name it) Cargo Package Manager to see if it fits the needs. Pharo bootstrap is the first use case. What I would like, is that, at the end, the dependency solver get out of Pharo and that we use already existing linux ones. What will stay into Pharo are packages metadata and the way to load a list of packages.

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Hi Dale, Le 11 oct. 2015 Ã 00:40, Dale Henrichs a Ã©crit : > Christophe, > > I still don't have a lot of time to read the paper and try to understand what you are trying to accomplish, but I am curious how you think "package dependencies" will play with git-based projects? Dependencies are not tied to a Version Control System (monticello, git or whatever). Dependencies are a package concern. With a released version, at the end, we need to fech source code from a VCS (as we do not have a shared binary format): these steps are already done by MC*Repository classes, including git. > In git-based repositories I don't think you have the same type of dependency issues that one might have with monticello repositories --- In a monticello repository you have a whole range of possible package versions to pick from, but in a git-based repository the range of package versions is fixed to those that are committed together so the packages that are meant to work together are committed together. Git allows you to easily reference a set of packages working together. It works fine for packages of the same repository but you get back the problem since you deal with packages of other repositories. > In the bootstrap scenario, you would only have one version per package to choose from, so the packages that are meant to work together are committed together .... For the first step of the bootstrap, it will work but not for next steps where we will split the Pharo image into different projects. > I guess I don't know what you mean when you say: >> we want to decouple a released version of a package from the working copy of the package version description (implies the creation of a package repository + a web interface on top of it to promote/search packages). > Perhaps a description of the problem being solved would help me understand. When you develop, you have a working copy of a package meta-data, including dependencies. Actually, there are current dependencies of the package. You could avoid to refer to specific versions and just point to the package name as your working image should already have packages loaded. (kind of configurationOf baseline) When you release a version (strong act), then you "freeze" the current working version of the package meta-data and you publish it somewhere (a package repository) so that it becomes available to others. This metadata is not source cod, is easily accessible by tools and it becomes easy to build a web site on top of this to search / promote packages. So, the problems I'm trying to solve there are: do not be tied to a VCS and do not need to load code to "play" with packages metadata offer a central place to easily find the package you need (for example, java has http://central.sonatype.org/, php has https://packagist.org/, etc.) do not mix preoccupations: I do not want to have metadata of all released versions + working copy of a package at the same place Christophe

Oct. 12, 2015

[pharo-project/pharo-core] b3031d: 50381

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: b3031d243c04ad2bd5c673f9805499c4852e4661 https://github.com/pharo-project/pharo-core/commit/b3031d243c04ad2bd5c673f9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-12 (Mon, 12 Oct 2015) Changed paths: R Collections-Abstract.package/Collection.class/instance/accessing/atRandom.st R Collections-Abstract.package/Collection.class/instance/accessing/atRandom_.st R Collections-Abstract.package/SequenceableCollection.class/instance/accessing/atRandom_.st R Collections-Tests.package/SetTest.class/instance/some tests/testAtRandom.st R Collections-Unordered.package/Matrix.class/instance/accessing/atRandom.st R Collections-Unordered.package/Matrix.class/instance/accessing/atRandom_.st R Collections-Unordered.package/Set.class/instance/accessing/atRandom_.st R Kernel-Tests.package/RandomTest.class/README.md R Kernel-Tests.package/RandomTest.class/definition.st R Kernel-Tests.package/RandomTest.class/instance/running/setUp.st R Kernel-Tests.package/RandomTest.class/instance/tests/testNext.st M Kernel.package/Context.class/class/instance creation/basicNew_.st M Kernel.package/Context.class/instance/controlling/shortDebugStack.st M Kernel.package/Context.class/instance/printing/debugStackOn_.st M Kernel.package/Context.class/instance/printing/debugStack_on_.st M Kernel.package/Context.class/instance/printing/printOn_.st M Kernel.package/Exception.class/instance/handling/freeze.st R Kernel.package/Integer.class/instance/truncation and round off/atRandom.st R Kernel.package/Integer.class/instance/truncation and round off/atRandom_.st R Kernel.package/Random.class/README.md R Kernel.package/Random.class/class/instance creation/seed_.st R Kernel.package/Random.class/class/testing/bucketTest_.st R Kernel.package/Random.class/class/testing/theItsCompletelyBrokenTest.st R Kernel.package/Random.class/definition.st R Kernel.package/Random.class/instance/accessing/next.st R Kernel.package/Random.class/instance/accessing/nextInt_.st R Kernel.package/Random.class/instance/accessing/next_.st R Kernel.package/Random.class/instance/accessing/next_into_.st R Kernel.package/Random.class/instance/initialization/initialize.st R Kernel.package/Random.class/instance/initialization/seed_.st R Kernel.package/Random.class/instance/private/nextValue.st R Kernel.package/Random.class/instance/private/seed.st A Random.package/Random.class/README.md A Random.package/Random.class/class/instance creation/seed_.st A Random.package/Random.class/class/testing/bucketTest_.st A Random.package/Random.class/definition.st A Random.package/Random.class/instance/accessing/next.st A Random.package/Random.class/instance/accessing/nextInt_.st A Random.package/Random.class/instance/accessing/next_.st A Random.package/Random.class/instance/accessing/next_into_.st A Random.package/Random.class/instance/initialization/initialize.st A Random.package/Random.class/instance/initialization/seed_.st A Random.package/Random.class/instance/private/privateNextSeed.st A Random.package/Random.class/instance/private/privateNextValue.st A Random.package/Random.class/instance/private/seed.st A Random.package/RandomTest.class/README.md A Random.package/RandomTest.class/definition.st A Random.package/RandomTest.class/instance/running/setUp.st A Random.package/RandomTest.class/instance/tests/testIfCompletelyBroken.st A Random.package/RandomTest.class/instance/tests/testNext.st A Random.package/SharedRandom.class/README.md A Random.package/SharedRandom.class/class/accessing/globalGenerator.st A Random.package/SharedRandom.class/class/initialization/initialize.st A Random.package/SharedRandom.class/definition.st A Random.package/SharedRandom.class/instance/accessing/next.st A Random.package/SharedRandom.class/instance/accessing/nextInt_.st A Random.package/SharedRandom.class/instance/accessing/next_into_.st A Random.package/SharedRandom.class/instance/initialization/initialize.st A Random.package/extension/Collection/instance/atRandom.st A Random.package/extension/Collection/instance/atRandom_.st A Random.package/extension/Integer/instance/atRandom.st A Random.package/extension/Integer/instance/atRandom_.st A Random.package/extension/Matrix/instance/atRandom.st A Random.package/extension/Matrix/instance/atRandom_.st A Random.package/extension/SequenceableCollection/instance/atRandom_.st A Random.package/extension/Set/instance/atRandom_.st A Random.package/extension/SetTest/instance/testAtRandom.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50380.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50381.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50380.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50381.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50381 16761 Method source should not contain linefeeds in Kernel https://pharo.fogbugz.com/f/cases/16761 16577 Random should be in its own package https://pharo.fogbugz.com/f/cases/16577 http://files.pharo.org/image/50/50381.zip

Oct. 12, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50381 Home: https://github.com/pharo-project/pharo-core

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by stepharo

> > A BaselineOf has a single baseline method and only the "pure" > dependencies amongst the packages and projects needs to be expressed > ... and these dependency specs are about "as small" as you can get ... >> Yes but we want them per package. We do not work on that since more than one year by accident. >>>> >>>> When a package is released into the market: then it externalise its >>>> metadata so that a crawler can automatically build >>>> dependency graph and create specific distribution. >>> Okay. This is a problem .... but it happens to be a problem that >>> Metacello "can solve/does solve" - so there must be something else >>> (a deeper problem?) that I don't quite understand. >> But you have to load the configuration and somehow execute it so that >> it computes the dependencies and we do not want. > Do you recall that I have been reminding folks that the specifications > for ConfigurationOf and BaselineOf will someday become an XML file? > ... I have taken great pains over the years to preserve this > "expectation" ... Remember the choice to use classes was made as a > bootstrap convenience to avoid having to create tools ... 6 years > later and there is still a dearth of tools:) > > When you "execute" the code in a ConfigurationOf or BaselineOf, a > completely separate data structure is constructed using a well-defined > API and it is this "data structure" that does the real work ... it > would be very easy to convert a BaselineOf into an XML/JSON/STON file > without losing any information, unless you've have disregarding my > warnings:) > > There is nothing in Metacello "project specifications" that _depends_ > upon executing code ... I know what I meant was use of pragmas, chaining pragma, loading all the configuration information (different baselines....). >>> With that said, if you are planning to replace Metacello, then I am >>> excited:) But I will repeat that I hope that you are considering >>> cross platform issues ... >> Yes we do. First we wanted to make it work. Then we should have kind >> of virtual packages that act as platforms or project level > When you talk about "virtual packages", I would say that a BaselineOf > is pretty much a "virtual package" already. > > When it comes to cross-platform support there are several factors that > were built into Metacello from the very beginning: > > - it should be possible to USE a package on a different platform > than it was > originally written for without modifying the package itself > - it should be possible to SUBSTITUTE a platform-specific package with > another platform-specific package without modifying either of the > packages > - it should be possible to CHANGE the package dependencies based on > platform-dependent requirements without modifying any of the > packages > > The key here is that if one needs to change a package to use it on a > different platform then you lose the ability to share source code. I see well the reason. :) The last point is the most tricky one when we have per package dependencies. But I will let christophe answers. > > The BaselineOf satisfies these requirements, because the "project meta > data" is separate from the package/source code and the BaselineOf > itself is cross-platform. > > If you haven't thought about these issues from the very beginning, > then it may not be easy to shoe-horn support in after the fact ... I will let christophe answer. > > With all of that said, I really do love the idea of not having to > support Metacello anymore:) So I would like to see you succeed with > your effort! Thanks. We will need help definitively. >>> Perhaps at this point in time, I'd like to read some code. Then I >>> can skip reading the paper and get a feel for how hard it will be to >>> port to GemStone:) >> I do not know where christophe save his code but it is be public. > I may not have time to read a paper ... but I would have time to read > code:) :) > > Dale > >

Oct. 12, 2015

Re: [Pharo-dev] MultistateLabelMorph still required

by Marcus Denker

> On 12 Oct 2015, at 01:38, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > from Web history I see that it was a Polymorph extension from Gary Chambers: > "Added MultistateLabelMorph that can adapt to interaction sates from buttons." > > http://forum.world.st/update-1-1-11293-Polymorph-Enhancements-td1680386.html > > In Pharo5.0 Latest update: #50380 one can see that it is not referenced. > Do we still need it or can we move it to deprecated? > I would say we deprecate. Marcus

Oct. 12, 2015

MultistateLabelMorph still required

by Torsten Bergmann

Hi, from Web history I see that it was a Polymorph extension from Gary Chambers: "Added MultistateLabelMorph that can adapt to interaction sates from buttons." http://forum.world.st/update-1-1-11293-Polymorph-Enhancements-td1680386.html In Pharo5.0 Latest update: #50380 one can see that it is not referenced. Do we still need it or can we move it to deprecated? Thanks T.

Oct. 11, 2015

Re: [Pharo-dev] Yet another Athens font thread

by Nicolai Hess

2015-10-09 22:43 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > No, they are needed. Because glyphs must be calculated (getGlyphs:of:) > after(!) setting font size. Otherwise there are huge gaps between > characters. > When font problem appears, some characters are of size 14 even if font > size 10. So glyphs of big characters have larger extent as it should be. In > your example you set font size and fix font, so all characters are rendered > correctly, but at wrong positions. That is a source of unnecessary gaps. > Ok, I understand. In what situation do you see huge gaps between glyphs? I only know about the problem of wrong sized glyphs. > Thete is a way to break font: > > 1) Get new pharo image > 2) Get Bloc > 3) Switch to bloc > 4) remove all morphs > 5) save and quite > 6) open image > 7) open nautilus > > Do something to fix font. Repeat 4-7. If fix is "fake" fonts will be > broken.. > On Oct 9, 2015 10:31 PM, "Nicolai Hess" <nicolaihess(a)web.de> wrote: > >> >> >> 2015-10-08 18:05 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: >> >>> Do you remember a hack with scaling? (scaleBy: 1.0001(a)1.0001) It makes >>> letters to have the same height, so no more huge ones with small fonts. But >>> it doesn't fix a bug when letters have wrong width so there is a space >>> between characters. The same effect can be achieved if we set font size >>> manually after setting scaled font before drawing glyphs with cairo. It >>> means that at some point we get wrong calculated glyphs. So if we "fix" >>> scaled font before glyph calculation - the problem would be gone. In the >>> patch I set scaled font, manually apply font size, retrieve "fixed" scaled >>> font and calculate glyphs based on it. >>> >>> Also after investigation I found something interesting. If we clean real >>> font of a logical font the problem gets fixed for some period of time. I >>> assume that FreeTypeFont gets broken after a while and logical font always >>> returns broken real font. Setting realFont to nil forces logical font to >>> create a new working free type font. As soon as new free type font is >>> created cairo produces scaled font and caches it. So actual problem lies >>> deep in FreeTypeFont... >>> >>> I even opened two images: one with broken fonts and one with working. >>> Then I compared in inspector two free type fonts - they are absolutely the >>> same and have identical instance variable in a whole object tree, except of >>> handler pointers to C structure which I can't inspect from pharo... >>> >>> Saving image fixes fonts because of >>> >>>> LogicalFont>>shutDown: quitting >>>> self allSubInstances do: [:i | i clearRealFont]. >>> >>> >>> Cheers, >>> Alex >>> >> >> This is great. >> >> I looked at your change. And noticed the call to >> setFontSize >> this was never called until now. Maybe this was the problem. >> >> Now, I just changed >> >> renderGlyphs: cairoGlyphs >> >> font lock. >> canvas >> setPathMatrix; >> setScaledFont: font; >> setFontSize: originalFont pixelSize. "<< new " >> canvas paint loadOnCairoCanvas: canvas. >> >> canvas showGlyphs: cairoGlyphs address size: cairoGlyphs size. >> font unlock. >> >> And it seems the font issue is gone. Maybe the other changes (set and get >> scaled font in #glyphsOf:from:to: ) >> isn't needed? (needs more tests) >> >> >> >>> On Thu, Oct 8, 2015 at 5:43 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>>> How did you fix it? >>>> Am 08.10.2015 17:06 schrieb "Aliaksei Syrel" <alex.syrel(a)gmail.com>: >>>> >>>>> Hi >>>>> >>>>> It looks like I fixed that weird text rendering problem... Just get >>>>> the latest Athens-Cairo. >>>>> >>>>> Cheers, >>>>> Alex >>>>> >>>>> On Mon, Aug 3, 2015 at 9:32 PM, Nicolai Hess <nicolaihess(a)web.de> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> 2015-06-10 12:01 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> I noticed that if I force use "Source Code Pro" as standard font for >>>>>>> all elements in the image I never have problems with font rendering. In >>>>>>> case of "Source Sans Pro" font is just not usable becasue of rendering bugs >>>>>>> on mac, windows and linux(?). If "Lucida Sans Pro" is used - no bugs too. >>>>>>> >>>>>>> Because bug is reproducable on all platform - it's platform >>>>>>> independent bug. >>>>>>> Because it's reproducable only with one specific font - maybe it's >>>>>>> not an athens issue but bug in font itself and if someone could >>>>>>> change/update Source Sans Pro to a newly version or to a similar font the >>>>>>> problem will be solved? >>>>>>> >>>>>> >>>>>> Did you try to use a new font version ? >>>>>> I don't know exactly how embedded fonts are included. I tried to >>>>>> create the font with a newer version but it did not work ( or at least I >>>>>> could not see any difference). >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Alex >>>>>>> >>>>>> >>>>>> >>>>> >>> >>

Oct. 11, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/11/15 11:40 AM, stepharo wrote: > >> >>> I think that this is only true for packages committed within the >>> same repo. >>> Now between porjects published in different repo you have to express >>> them. >>> I do not think that we all want to publish in the same repo and >>> clone out everything. >> ... and inter-project dependencies is what a BaselineOf does .... >> which brings me back to the conclusion that I reached when I scanned >> the paper:) > Yes probably but you have to have a BaselineOf for every package. > Because we want to have the dependency expressed in every package and > not in > a gigantic "project" configuration of. If you are talking about ConfigurationOf, then I agree that they can be gigantic, but 99% of the junk in a configuration is completely eliminated when you use a BaselineOf ... 99% of the junk in a configuration is dedicated to plugging the gap between monticello as an SCM and built-in capabilities for git ... A BaselineOf has a single baseline method and only the "pure" dependencies amongst the packages and projects needs to be expressed ... and these dependency specs are about "as small" as you can get ... > >>> >>> When a package is released into the market: then it externalise its >>> metadata so that a crawler can automatically build >>> dependency graph and create specific distribution. >> Okay. This is a problem .... but it happens to be a problem that >> Metacello "can solve/does solve" - so there must be something else (a >> deeper problem?) that I don't quite understand. > But you have to load the configuration and somehow execute it so that > it computes the dependencies and we do not want. Do you recall that I have been reminding folks that the specifications for ConfigurationOf and BaselineOf will someday become an XML file? ... I have taken great pains over the years to preserve this "expectation" ... Remember the choice to use classes was made as a bootstrap convenience to avoid having to create tools ... 6 years later and there is still a dearth of tools:) When you "execute" the code in a ConfigurationOf or BaselineOf, a completely separate data structure is constructed using a well-defined API and it is this "data structure" that does the real work ... it would be very easy to convert a BaselineOf into an XML/JSON/STON file without losing any information, unless you've have disregarding my warnings:) There is nothing in Metacello "project specifications" that _depends_ upon executing code ... > >> With that said, if you are planning to replace Metacello, then I am >> excited:) But I will repeat that I hope that you are considering >> cross platform issues ... > Yes we do. First we wanted to make it work. Then we should have kind > of virtual packages that act as platforms or project level When you talk about "virtual packages", I would say that a BaselineOf is pretty much a "virtual package" already. When it comes to cross-platform support there are several factors that were built into Metacello from the very beginning: - it should be possible to USE a package on a different platform than it was originally written for without modifying the package itself - it should be possible to SUBSTITUTE a platform-specific package with another platform-specific package without modifying either of the packages - it should be possible to CHANGE the package dependencies based on platform-dependent requirements without modifying any of the packages The key here is that if one needs to change a package to use it on a different platform then you lose the ability to share source code. The BaselineOf satisfies these requirements, because the "project meta data" is separate from the package/source code and the BaselineOf itself is cross-platform. If you haven't thought about these issues from the very beginning, then it may not be easy to shoe-horn support in after the fact ... With all of that said, I really do love the idea of not having to support Metacello anymore:) So I would like to see you succeed with your effort! > >> Perhaps at this point in time, I'd like to read some code. Then I can >> skip reading the paper and get a feel for how hard it will be to port >> to GemStone:) > I do not know where christophe save his code but it is be public. I may not have time to read a paper ... but I would have time to read code:) Dale

Oct. 11, 2015

taskbarThumbnail leaks memory?

by Henrik Nergaard

It looks like the taskbarThumbnails might be leaking memory. When moving the mouse across the taskbar viewing the different thumbnails the memory usage increases by quite a lot (viewed in the taskmanager (Windows) ). I made an example script to illustrate the resource usage. Test scenario: 20 windows; 1 Playground, 19 Nautilus browsers (these are minimized). =============== Create Test Scenario ======================== 19 timesRepeat: [ Nautilus openOnClass: Object. World doOneCycle. ]. World doOneCycle. World submorphs select: [ :m | m isKindOf: NautilusWindow ] thenDo: [ :m | m minimize ] ===== Enumerate the mouse moving from one taskbarButton to the next ======= | delay | delay := [ :msToWait | | t | t := Time now asMilliSeconds. [ (Time now asMilliSeconds - t) < msToWait ] whileTrue: [ World doOneCycle ]. ]. 20 timesRepeat: [ World submorphs detect: [:m | m isTaskbar ] ifFound: [ :taskbar | taskbar orderedTasks collect: [ :task | task morph ] thenDo: [ :morph | | button | button := (taskbar taskButtonOf: morph). morph taskbarButtonEntered: button event: nil in: nil. delay value: 100. morph taskbarButtonLeft: button event: nil in: nil. delay value: 100 ] ]. Smalltalk garbageCollect. ]. ============================================================ Results: (Newest Win vm -> Image 50377) opening the 20 Windows RAM used is 70MB. 1 iteration: 93MB 20 iterations: 130MB \ 190 MB when garbageCollect is commented out. Should the resource usage be that high? (a taskbarThumbnail is deleted before the next one is shown...) Best regards, Henrik

Oct. 11, 2015