February 2020 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Mm10s] 2020-02-10

by tesonep＠gmail.com

It's under construction, but here it is https://github.com/pharo-project/opensmalltalk-vm/wiki On Mon, Feb 10, 2020 at 10:46 AM Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Pablo, > > > On Mon, 10 Feb 2020 at 10:31, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > > > > Monday morning, time for the weekly mail meeting in 10 seconds! > > (just reply, inserting bullet points) > > > > ### Last week: > > > > - PharoVM wiki > > Is this publicly accessible? Can we have a link? > > Thanks! > Alistair > -- Pablo Tesone. tesonep(a)gmail.com

Feb. 10, 2020

Re: [Pharo-dev] [Mm10s] 2020-02-10

by Alistair Grant

Hi Pablo, On Mon, 10 Feb 2020 at 10:31, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > > Monday morning, time for the weekly mail meeting in 10 seconds! > (just reply, inserting bullet points) > > ### Last week: > > - PharoVM wiki Is this publicly accessible? Can we have a link? Thanks! Alistair

Feb. 10, 2020

[Mm10s] 2020-02-10

by Esteban Lorenzano

### Last week: * [objcbridge] finish migration of ObjCBridge to TFFI. Now everything works as expected, proxies inclusive (chich was absent before) * [spec2] fix a problem in the build of toolbars from commands (this one was new... it was working before). * [spec2] I spent some time figuring out what we need to fix the "sorted table+selection item" problem. Basically, selectedItem needs to be retrieved from sorted collection, not from original model. But this is problem because sorted collection lives in adapter part (or even worst on gtk). * Spec2: implement SpToolBarToggleButton * Spec2-doc: SpLabelPresenter * Spec2: bug: error mapping of $^ in gtk backend. * building a small tool to help me find image leaks. For now, is just a simpler way to visualise amount of instances (no graphics, just numbers). I may add other stuff later. It can be found at https://github.com/estebanlm/WAMO (WAMO=Where Are My Objects) * [newtools] I added some settings to change the default toolbar display mode. I like small icons, Stef likes big ones... like this we are all happy :) * [big images] testing different heuristics to make a big image (and killing my machine in the process) ### This week * More on work on speed up of big images (finish migration to notebook morph, start looking improvements on senders/implementors) * Work on idle vm * Spec2: work on dynamic layouts

Feb. 10, 2020

[Mm10s] 2020-02-10

by tesonep＠gmail.com

Monday morning, time for the weekly mail meeting in 10 seconds! (just reply, inserting bullet points) ### Last week: - PharoVM wiki - [Idle VM] Fix Allocation problem in Linux with MMAP - [TFFI] Fixing the build for use a given VM, so we can have different versions - [TFFI] Adding another development branch - [Pharo9] Retaking the Sista bytecode recompilation PR - [Idle VM] Make the idle VM uses the Pthread plugin supporting the main thread scheduling. - [PharoCOM] Making it work in 32 / 64 bits Pharo 8 - [PharoCOM] Making extensions for using Access API - Compiling VM for Linux in Ubuntu 18.03 - [Doc] Pass on VM booklet: Callback chapter - [LargeImages] Working on image generation - [LargeImages] Improving Speed of senders and implementors. ### This week (starting 2020-02-10), a.k.a the pipeline: - [Pharo9] Propose a PR for Fuel to support Sista - [VM] Fixing Tests in Idle - [Doc] Pass on VM booklet: Callback chapter / Preface - [VM] Documenting GC, participating in the GC code dojo. - [LargeImages] Working on improving the speed and responsiveness of large images. - [VM] SDL Plugin for Idle - [VM] Improving Speed of TFFI - [VM] REPL example / Interacting with an image from outside (?) - [PharoCOM] Fixing Pharo COM for Pharo8âs UFFI - [PharoCOM] Making it run with TFFI - [VM] Writing tests for JIT generation - [VM] Promote VM a Stable -- Pablo Tesone. tesonep(a)gmail.com

Feb. 10, 2020

Re: [Pharo-dev] Bug 18632 : Virtual Machine parameters need to be documented

by Nicolas Cellier

Hi Benoit, you are right to say that documentation is lacking. Alas, it's not going to fall from the sky: there's no such thing like a VM Pantheon with gods ruling the VM world, not even half-gods (well maybe one super-powered hero, we have to acknowledge that a 10x speedup was brought by his experience). Changes must come from the ground up, and if some metaphor is to be used, we'd rather want to cultivate the VM I would say. Every initiative is welcome, and encouraged, the source code is open, there is no will to protect by secret or obfuscation. We have almost 50 contributors reported on github, which is already a good starting point. I'd say every little contribution counts. So if someone wants to take a subject like VM parameters, I'm pretty sure that he/she will get all necessary precision from those sharing parts of the knowledge. It's also a very interesting way to get more insights in the VM. What should be discussed IMO is the form of documentation. Blog posts are nice. But they are individual initiatives, rather than collectively maintained and versioned documentation. Le sam. 8 fÃ©vr. 2020 Ã 04:17, Benoit St-Jean via Pharo-dev < pharo-dev(a)lists.pharo.org> a Ã©crit : > Eliot, > > I was referring to VM parameters (aka #vmParameterPut:at:). But now that > you mention it, it adds another level of complexity. When you specify > something in the command line arguments, how do you resolve the fact that > the command line argument tells you something that is different from what > is in the image? The mechanics of the VM stuff is like black magic to most > of us! You see, that's the type of question that is kinda "oral tradition" > : if no one ever told you, you don't know since it's not obvious and rarely > documented properly but, eh, it's written "somewhere" in the code of the > VM! It might seem obvious to a very few of you, especially yourself, since > you've been working on the VM long before my Vassili-Bykov-Days but for > most of us, it's a case of very-interesting-to-read-but-way-too-complex ! ;) > > To make a long story short, I was thinking about experimenting and trying > to implement "stuff" with something similar to VisualWorks's MemoryPolicy > (AbstractMemoryPolicy and subclasses to be more precise) for Pharo. It did > save my/our/TheProjects' ass quite a few times. Yes, you can write scripts > to customize a few things before you produce the "final" image but it is a > pain in the as_ (the polite SQL way of describing it) and you have to keep > track of artifacts (scripts, files, workspace code, whatever) to produce > the final image. With custom memory policies, everything resides in the > image and it is sooooooooooo much simpler to deal with! > > There is no such thing as a one-configuration-fits-all. That's why > different types of applications have different needs for GC, memory, > tenuring, memory-space sizes, etc. And quite frankly, VW' MemoryPolicy is > so far and by far the best solution I've seen to cope with that. There > ain't such thing as 2 identical applications that have the exact same > VM/GC/memory needs! > > I was able to build/read a "collection" of articles/posts/PDFs about GC > and the VM but, quite honestly, I kinda lost track of what is what and > which is which. Cog, Spur, stack or not, NewSpeak vs Squeak vs Pharo, 32 > vs 64 bits, jitted or not, and all permutations you can think of, for 99.9% > of us it is like trying to learn Mandarin in 2 days! I do/did read your > blog as well as the blog of ClÃ©ment BÃ©ra as well as Andres Valloud > posts/papers on the subject but in the VM world, things quickly get > complicated unless, like ObÃ©lix, you were born in it! I've read a gazillion > papers on the GC and various Smalltalk memory models written by John > McIntosh but are those papers/posts/articles still relevant? > > In other words Eliot (and your VM wizard friends), the VM (aka GC and > memory model) do need some "documentation love" for "the average > Smalltalker" ! ;) > On 2020-02-07 13:59, Eliot Miranda wrote: > > Hi Benoit, > > On Fri, Feb 7, 2020 at 8:20 AM Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Hi Benoit, >> for some reason (?), your email was marked as SPAM in gmail... >> There is a short description in primitiveVMParameter, which is found in >> generated code, for example: >> >> https://raw.githubusercontent.com/OpenSmalltalk/opensmalltalk-vm/Cog/src/vm… >> or VMMaker source code (you can also find VMMaker source code in pharo vm >> github repo, no time to dig). >> >> Le jeu. 6 fÃ©vr. 2020 Ã 12:45, Benoit St-Jean via Pharo-dev < >> pharo-dev(a)lists.pharo.org> a Ã©crit : >> >>> I was looking for some documentation on VM parameters (are they read, >>> read-write or write only as well as the expected argument type) and came >>> across that issue on the old FogBugz database. >>> >> > Are you talking just about vmParameterAt:[put:]/vm parameterAt:[put:] or > are you also talking about command line arguments (pharos-vm --help/squeak > -help)? > If the former, there are much more current comments in trunk Squeak > SmalltalkImage>>vmParameterAt:[put:] than in Pharo; you could usefully copy > that across. The comments in the two methods accurately specify which > parameters are read/write, and which persist in the image header. > > But I agree, more verbose documentation would be very helpful; the current > documentation is very terse, and while it describes what the parameters are > and whether they are writable, it really doesn't describe what the systems > that they operate on actually do. I'm happy to collaborate with you in > developing better documentation. If you will do the writing I will happily > consult. Does that work? > > >>> >>> https://pharo.fogbugz.com/f/cases/18632/Virtual-Machine-parameters-need-to-… >>> >>> I tried looking it up on GitHub but couldn't find it. Am I missing >>> something or I should open an issue? I'm working on something related >>> to various memory settings and not having any info on a lot of these >>> parameters doesn't help. While I could meticulously read tons of C code >>> of the VM and pinpoint exactly what I need to know for each and everyone >>> of these undocumented parameters, I'd gladly do it myself if any of the >>> VM guys (ClÃ©ment, Pablo, Alexandre or Eliot) have notes/documents/links >>> that could help me do it. >>> >>> tia >>> >>> -- >>> ----------------- >>> BenoÃ®t St-Jean >>> Yahoo! Messenger: bstjean >>> Twitter: @BenLeChialeux >>> Pinterest: benoitstjean >>> Instagram: Chef_Benito >>> IRC: lamneth >>> GitHub: bstjean >>> Blogue: endormitoire.wordpress.com >>> "A standpoint is an intellectual horizon of radius zero". (A. Einstein) >>> >>> >>> > > -- > _,,,^..^,,,_ > best, Eliot > > -- > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > GitHub: bstjean > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > >

Feb. 9, 2020

Re: [Pharo-dev] methods not registered in packages?

by Tudor Girba

Excellent catch! Ok, I will open an issue. Cheers, Doru > On Feb 9, 2020, at 3:04 PM, tesonep(a)gmail.com wrote: > > Hi Doru, > thanks for checking this behavior. Those methods are not correctly > packaged because those are methods added from a trait. Nowadays, > #methods returns all the methods in the class (the ones defined in the > class and the ones defined in the used traits) and #localMethods > returns the methods defined only in the class. > > I think it is a good issue to open so we can discuss which is the best > API for it. Maybe the existing one is not good. To me, #methods should > not return all the methods from the method dictionary or we have to > encourage to use the #localMethods where #methods is used. > I am not sure about what is the answer, so the issue to discuss will be perfect. > > Cheers, > Pablo > > On Sun, Feb 9, 2020 at 8:16 AM Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> While trying to measure the size of code, I stumbled across an interesting problem: it seems that some methods have a package, but the package does not list. >> >> packagedMethods := RPackageOrganizer default packages flatCollect: #methods. >> methods := ProtoObject withAllSubclasses flatCollect: #methods. >> diff := methods \ packagedMethods. >> diff size. >> â7249" >> >> Looking at bit closer, it looks like the methods do have a package and that they point to the package that is in the package organizer, so that is good: >> >> diff select: [ :each | each package isNil ] >> "an OrderedCollection()". >> >> diff select: [ :each | (RPackageOrganizer default packages includes: each package) not ]. >> "an OrderedCollection()â >> >> However, when we ask the package, it does not know about the method: >> >> diff select: [ :each | each package methods includes: each ] >> "an OrderedCollection()â >> >> >> Is this a known problem or should I open an issue (I did not find a bug report for it)? >> >> >> Cheers, >> Doru >> >> >> -- >> feenk.com >> >> "Presenting is storytelling." >> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Feb. 9, 2020

Re: [Pharo-dev] methods not registered in packages?

by tesonep＠gmail.com

Hi Doru, thanks for checking this behavior. Those methods are not correctly packaged because those are methods added from a trait. Nowadays, #methods returns all the methods in the class (the ones defined in the class and the ones defined in the used traits) and #localMethods returns the methods defined only in the class. I think it is a good issue to open so we can discuss which is the best API for it. Maybe the existing one is not good. To me, #methods should not return all the methods from the method dictionary or we have to encourage to use the #localMethods where #methods is used. I am not sure about what is the answer, so the issue to discuss will be perfect. Cheers, Pablo On Sun, Feb 9, 2020 at 8:16 AM Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > While trying to measure the size of code, I stumbled across an interesting problem: it seems that some methods have a package, but the package does not list. > > packagedMethods := RPackageOrganizer default packages flatCollect: #methods. > methods := ProtoObject withAllSubclasses flatCollect: #methods. > diff := methods \ packagedMethods. > diff size. > â7249" > > Looking at bit closer, it looks like the methods do have a package and that they point to the package that is in the package organizer, so that is good: > > diff select: [ :each | each package isNil ] > "an OrderedCollection()". > > diff select: [ :each | (RPackageOrganizer default packages includes: each package) not ]. > "an OrderedCollection()â > > However, when we ask the package, it does not know about the method: > > diff select: [ :each | each package methods includes: each ] > "an OrderedCollection()â > > > Is this a known problem or should I open an issue (I did not find a bug report for it)? > > > Cheers, > Doru > > > -- > feenk.com > > "Presenting is storytelling." > > -- Pablo Tesone. tesonep(a)gmail.com

Feb. 9, 2020

[Ann] Concurrent Programming in Pharo is available

by StÃ©phane Ducasse

On http://books.pharo.org/booklet-ConcurrentProgramming/ <http://books.pharo.org/booklet-ConcurrentProgramming/> S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / 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

Feb. 9, 2020

The expanding Pharo ecosystem

by Sven Van Caekenberghe

Hi, Let's take a moment to contemplate on the breath and the depth of the expanding Pharo ecosystem. So much is happening that it is very hard to keep track, let alone look at everything or try it out. Marcus' excellent curated Pharo Newsletter is one place to see this. Take the February 2020 list of New/Updated Libraries and Frameworks at the end: https://mailchi.mp/pharo/pharo-newsletter-february-2020 This is one of the longest enumerations I have seen so far. The great thing is that it is like that almost every month. Check out the archive: https://us11.campaign-archive.com/home/?u=6f667565c2569234585a7be77&id=0486… Of course, GitHub is also a good way to see this happening. The main entry being: https://github.com/pharo-project/ Which contains several overviews: https://github.com/pharo-project/PharoMap https://github.com/pharo-open-documentation/awesome-pharo Topic tags automatically organise some projects: https://github.com/topics/pharo https://github.com/topics/pharo-smalltalk What all this comes down to is that Pharo has many recently developed, actively maintained options to get your job done: to model your domain, to build your user interface, to talk to other systems, to speak other protocols, to interface with the world, to deploy and to deliver your applications. Similarly, Pavel recently did a very good job at the describing why Pharo itself is so great: https://github.com/pavel-krivanek/pharoMaterials/blob/master/features/Pharo… So thanks to all of you for helping to make Pharo into what it is. Thanks to our users: for your questions, you're feedback, your bug reports. Thanks to those helping out others on the mailing lists. Thanks to everyone who ever blogged or otherwise wrote about their experiences with Pharo. Thanks to the contributors involved in constantly improving Pharo with Pull Requests, to those working hard to maintain the process and the machinery behind the development process. Thanks to all the developers producing and maintaining the many libraries and frameworks that help us in our day to day work. Thanks to those writing documentation. Thank you. Sven PS: This is already a long email, but I know that I forgot many important points, feel free to add them in reply. -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Feb. 9, 2020

methods not registered in packages?

by Tudor Girba

Hi, While trying to measure the size of code, I stumbled across an interesting problem: it seems that some methods have a package, but the package does not list. packagedMethods := RPackageOrganizer default packages flatCollect: #methods. methods := ProtoObject withAllSubclasses flatCollect: #methods. diff := methods \ packagedMethods. diff size. â7249" Looking at bit closer, it looks like the methods do have a package and that they point to the package that is in the package organizer, so that is good: diff select: [ :each | each package isNil ] "an OrderedCollection()". diff select: [ :each | (RPackageOrganizer default packages includes: each package) not ]. "an OrderedCollection()â However, when we ask the package, it does not know about the method: diff select: [ :each | each package methods includes: each ] "an OrderedCollection()â Is this a known problem or should I open an issue (I did not find a bug report for it)? Cheers, Doru -- feenk.com "Presenting is storytelling."

Feb. 9, 2020