- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] Squeak and Tonel

by ducasse

Hi eliot What is common in your thread is that we always look like the super emotional, or bad guys. You never ask yourselves why Esteban left the VM mailing-list. And I do not see why you cannot fork Tonel to produce your own version. Git is about distributed projects. People do that all the time. You can take Tonel and hack it to death without having your hacks pushed back into Pharo and this is perfectly ok for us. So Esteban has the right to say no and you have the right to hack your own version. If you want to have some support for porting Scorch/Sista to github and loading you should ask but asking it more nicely. About the simulation of the UI, if you do not talk to us we cannot pay attention. I do not see why we cannot keep a package with the image level UI for the simulator. Now again you are talking about collaboration but you do not talk to us and you do not listen to us so do not expect that people are willing to spend their free time to help. > I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or elseâ, This is fun to ask Pharo not to grow up to use modern technology to manage source code under the premisses that Squeak cannot or will not. This is so funny how you state it. I will not comment more than that. People around are adults and they will be able to judge by themselves. > and considering leaving VMMaker altogether. If you leave VMMaker, let us know because we will port it to Github and make it work in Pharo. Esteban did it several times in the past. At least this will have the benefit to clarify the situation. I think that this is good that you tell us that you do not want to cooperate with us. This will have at least the impact to kick our ass and pay attention to us. > The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI. > > Here's the kind of crap people like Ducasse throw at me: > > "Eliot > > At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy > because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have > to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world > of the âopenâ smalltalk VM. " > > I am so over this crap. This is not a crap. I can restate what I said. Because of responsibility of a research team and creating a future for students. You know Iâm not alone, I have quite some responsibility towards PhD students of my group and yes I cannot make them fail by construction (or produce unadequate results) just by imposing them to use a system with far too many constraints. I will not ask them to work on the openSmalltalk vm directly because this is not their responsibilities to have to jump over newspeak ifdef and others. A job of a PhD is to be able to brainstorm and create new ideas. Look at Stefan Marr (He is working on SOM or Truffle). Now you can think that Iâm an asshole, arrogant, or I do not know pick what you want. ***I do not care***. I do not have Diva syndrome I have responsibilities towards people. I was discussing with some truffle experts and they told me that this is can be complex. I believe it. I would like to avoid pypy for obvious reasons. So what we will probably do for their PhD is to see if we can use a light version of opensmalltalk. I do not want to ask them to jump over many things that are totally useless for them all the time. PS: personnally I do not get why VMMaker would be the only project on earth that cannot be managed using git and Pharo. But for us the future is Git and we will continue to build on this infrastructure. Stef > > _,,,^..^,,,_ > best, Eliot

Feb. 17, 2019

Re: [Pharo-dev] [Ann] TelePharo and PharoThings adopted for Pharo 7

by Norbert Hartl

> Am 17.02.2019 um 21:03 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi. > > I released new versions of TelePharo (v0.3.0) and PharoThings (v0.2.3) adopted for Pharo 7 changes. > > PharoThings also includes new features from Alex Oliveira: > - Raspberry model B3 > - water alarm example > And few models of Arduino from @gaterfy. Can you elaborate on this? What has an arduino model to do here? Norbert > > Best regards, > Denis

Feb. 17, 2019

Re: [Pharo-dev] [squeak-dev] Squeak and Tonel

by Eliot Miranda

Hi All, Hi Torsten, Hi Jakob, On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > as some of you might already know "Tonel" is a file-per-class format for > monticello repositories [1]. > > In Pharo land many projects are already converted to it - as regular "file > tree" solution faces issues > with git handling due to very long file names / deep file hierarchy (often > leading to trouble on Windows). > > Dales's Rowan (a new project/package manager for Smalltalk) supports > FileTree and also Tonel > repositories [2]. There is also a tool to convert from STORE (VisualWorks > Source-Code Versioning System) > to Tonel format [3]. > > So I wonder about adoption of Tonel in Squeak land. > > Any status/comments? > Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code. This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors. I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstance". So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. ClÃ©ment had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista. I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI. Here's the kind of crap people like Ducasse throw at me: "Eliot At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. " I am so over this crap. _,,,^..^,,,_ best, Eliot

Feb. 17, 2019

[Ann] TelePharo and PharoThings adopted for Pharo 7

by Denis Kudriashov

Hi. I released new versions of TelePharo (v0.3.0) and PharoThings (v0.2.3) adopted for Pharo 7 changes. PharoThings also includes new features from Alex Oliveira: - Raspberry model B3 - water alarm example And few models of Arduino from @gaterfy. Best regards, Denis

Feb. 17, 2019

[Pharo 8.0] Build #85: 2552 Lint problem in #allUnreferencedInstanceVariables

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

There is a new Pharo build available! The status of the build #85 was: SUCCESS. The Pull Request #2553 was integrated: "2552 Lint problem in #allUnreferencedInstanceVariables" Pull request url: https://github.com/pharo-project/pharo/pull/2553 Issue Url: https://pharo.fogbugz.com/f/cases/2552 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2019

[Pharo 8.0] Build #84: 2571-RBPatternWrapperBlockNode-missing-sentMessages

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

There is a new Pharo build available! The status of the build #84 was: SUCCESS. The Pull Request #2572 was integrated: "2571-RBPatternWrapperBlockNode-missing-sentMessages" Pull request url: https://github.com/pharo-project/pharo/pull/2572 Issue Url: https://pharo.fogbugz.com/f/cases/2571 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2019

Re: [Pharo-dev] The HiDPI Issue

by Eric Gade

Ben: > Would you volunteer for early testing of windowing driven from Image side > of headless-VM ? Yeah I would love to help test this. However, there's a good chance I'm going to return this new laptop for its lower resolution variant (I have a System76 Galago Pro). The HiDPI situation in Linux is, for the moment, not especially great. Some if it has to do with the whole X vs Wayland (vs NVIDIA) fiasco. But other than that, this is definitely something I'd be willing to help out with. Tim: > Eric - I had the same feeling a few years ago when I got a retina laptop > and found Pharo a bit fuzzy on the eyes (although itâs true that with time > you start to notice it less) > I think Apple has some secret sauce when dealing with scaling across different applications on their Retina displays. Xorg and friends do not have this magic on the Linux side. On a 3k 13/14inch screen, without switching my monitors resolution down in the settings, Pharo is downright microscopic (I don't have my new laptop with me otherwise I'd post a screenshot). The only way to deal with this is to completely switch my resolution and scaling factors at the system settings level every time I want to use Pharo. For other applications this might involve a restart, too, which is no bueno. The GToolkit stuff is promising and I had been waiting for this Bloc-in-external-window capability. With regard to the HiDPI stuff, it doesn't make a difference on Linux -- it's just as "small" as anything in the main Morphic window. Again, I think this is because Apple (maybe Windows too?) has more control over their whole graphics stack and can perform some kind of magic to deal with scaling across applications. Thanks for the replies, all.

Feb. 16, 2019

[Pharo 8.0] Build #83: 2562 Remove unused cache from TermInfoCharacter

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

There is a new Pharo build available! The status of the build #83 was: SUCCESS. The Pull Request #2563 was integrated: "2562 Remove unused cache from TermInfoCharacter" Pull request url: https://github.com/pharo-project/pharo/pull/2563 Issue Url: https://pharo.fogbugz.com/f/cases/2562 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2019

Re: [Pharo-dev] The HiDPI Issue

by Tim Mackinnon

Eric - I had the same feeling a few years ago when I got a retina laptop and found Pharo a bit fuzzy on the eyes (although itâs true that with time you start to notice it less). Anyway - Iâm not sure anyone has actually mentioned that you can download the latest Glamourous Toolkit (https://gtoolkit.com/#install <https://gtoolkit.com/#install> - take the prebuilt image) and then open a playground (with all other windows closed) and evaluate: Bloc preferableHostClass: BlOSWindowHost Then try one of the examples in the GT menu (donât go full screen in your image), and this will open a second native window rendered in retina quality. Its still a bit alpha - you get a warning dialog that you have to click ignore on 3 times - but then it keeps running. It is also obviously unoptimised at this point too. I think this gives a welcome glance of the future - so there is hope. Tim > On 16 Feb 2019, at 11:04, ducasse <stepharo(a)netcourrier.com> wrote: > > Hi Eric > > I will let esteban reply carefully :) > Now my take on this is > that we want to go via SDL and other backends to solve the problems (event dropping, display) > Back in October, Esteban fixed the SDL/OSWindows so that Bloc people can get rid of the > VM rendering and be free. > > This is the path to go. > For Bloc I (personally and discussing with Alain) think that there is 4-6 months of work (if I would overselling it I would have said that this is 2 month work) to clean it and tight it up - (not talking about Widgets). I personnally do not want Design like Glamour or GT in the system (too many announcers). > So we will take time to do real code review. > > So our roadmap is > - make sure that Pharo can work headless > - check the impact of SDL/OSWindow > - focus on new spec version so that we can have our tools migrated and we do not have to > rewrite them once more. > > Pharo 90 probably focus on Bloc. > > > Stef > >> On 15 Feb 2019, at 17:52, Eric Gade <eric.gade(a)gmail.com> wrote: >> >> Hello, >> >> I know that others have posted about this before but I wanted to get the current status. >> >> I've recently had to buy a new laptop that came with a HiDPI display. Generally (especially on Linux systems) this makes Pharo unusable. Though there are font size increase and scaling options in the Pharo system settings, these do not work as a solution -- buttons are still tiny, there is inconsistent scaling behavior across morphic, etc. The overall problem can be described as: in Pharo, one pixel equals one "point," and so the interface is incredibly small on these HiDPI screens (3k etc). >> >> These HiDPI screens are becoming more common, both as laptop and as external displays. Their main advantage is that they can render text very crisply. In the HN post announcing the release of P7, there were one or two complaints about this issue. It does make it hard to demonstrate to others (as I do often) the power of developing in Pharo. >> >> Here are some questions I have about this issue: >> 1) What is the current state of affairs in dealing with this issue, if any? >> 2) Would this require VM changes (I assume it would)? If so, what might those entail? >> 3) If this does require VM changes, I assume the Squeak people would want in on it? >> 4) Is the current plan to wait for Bloc to resolve these issues and/or would switching to Bloc resolve these issues at all anyway? >> 5) Related -- where can one start to learn about current VM architecture and development practices? >> >> That said I'm not here to just bellyache. While I don't have any VM experience, I'm willing to jump in and try to work on it if someone can point me in the right direction. Or perhaps this is too specialized a task... >> >> Thanks >> >> -- >> Eric > > >

Feb. 16, 2019

[Pharo 8.0] Build #82: 2554 Epicea: EpApplyPreviewer sourceEntries and logBrowserModel ivars not used

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

There is a new Pharo build available! The status of the build #82 was: FAILURE. The Pull Request #2555 was integrated: "2554 Epicea: EpApplyPreviewer sourceEntries and logBrowserModel ivars not used" Pull request url: https://github.com/pharo-project/pharo/pull/2555 Issue Url: https://pharo.fogbugz.com/f/cases/2554 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2019