- Pharo-dev - lists.pharo.org

Host window icon
by Cyril Ferlicot Feb. 21, 2019

Feb. 21, 2019

Hi, Currently, the CI of Pharo has two non random test failures. windows-32 / Tests-windows-32 / testHostWindowIcon â Windows32.Graphics.Tests.Primitives.DisplayScreenTest windows-32 / Tests-windows-32 / testHostWindowIconWrongTypeOfArgument â Windows32.Graphics.Tests.Primitives.DisplayScreenTest I know this was a part of the system was improved during Pharo 7 to be able to display a custom icon at the top of the window. Does someone knows why it is failing? Or should we investigate? -- Cyril Ferlicot https://ferlicot.fr

1 0

Question on KmGlobalDispatcher
by David Richards Feb. 20, 2019

Feb. 20, 2019

Why does the class name KmGlobalDispatcher have a small 'm'? Should it be more consistently named KMGlobalDispatcher, as all other classes in package: 'Keymapping-Core'? Object subclass: #KmGlobalDispatcher instanceVariableNames: 'dispatcher' classVariableNames: '' package: 'Keymapping-Core' Just curious why this name seems inconsistent. I don't recall seeing an inconsistency with class name prefixes in any other package group. Is this just a mistake, or rather an opportunity to learn something interesting about how classes should be named in Pharo? As a beginner, I'm not sure which. Thanks David

3 3

Re: [Pharo-dev] [squeak-dev] Squeak and Tonel
by Eliot Miranda Feb. 20, 2019

Feb. 20, 2019

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

8 22

Using Metacello scripting API with non-github repo
by Sven Van Caekenberghe Feb. 19, 2019

Feb. 19, 2019

Hi, My code lives in a private bitbucket git repo, how can I use this with the Metacello scripting API ? Metacello new repository: 'ssh://git@bitbucket.somehost.be:8899/xxx/t3-pharo.git'; baseline: 'BetaNineT3'; load: #('core' 'gb'). IOW, what is the correct URL ? Is that even possible, if not what is the alternative ? I created/used this repo before, using keys as authentication. Could one also use username/password authentication, like when deploying ? Sven

3 5

[Pharo 8.0] Build #91: Remove DebugSession>>activePC: and DebugSessio>>previousPC:
by ci-pharo-ci-jenkins2＠inria.fr Feb. 19, 2019

Feb. 19, 2019

There is a new Pharo build available! The status of the build #91 was: FAILURE. The Pull Request #2653 was integrated: "Remove DebugSession>>activePC: and DebugSessio>>previousPC:" Pull request url: https://github.com/pharo-project/pharo/pull/2653 Issue Url: https://pharo.fogbugz.com/f/cases/2274 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

About Iceberg
by Sven Van Caekenberghe Feb. 19, 2019

Feb. 19, 2019

Hi, This is a thank you note about Iceberg. I have been moving all my external and internal Pharo code to git/tonel/7 and on multiple occasions I have been pleasantly surprised about the functionality and performance of Iceberg. Basically, it just works. Finally, Pharo code lives in standard open source and commercial repositories (git, GitHub, Bitbucket, ...), without losing anything. I know that it took years to get here and that lots of code and community battles had to be fought. So thank you, to the whole team, you did a great job ! Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

4 3

[Pharo 8.0] Build #90: 2482 initial fuel update for pharo 8
by ci-pharo-ci-jenkins2＠inria.fr Feb. 19, 2019

Feb. 19, 2019

There is a new Pharo build available! The status of the build #90 was: FAILURE. The Pull Request #2483 was integrated: "2482 initial fuel update for pharo 8" Pull request url: https://github.com/pharo-project/pharo/pull/2483 Issue Url: https://pharo.fogbugz.com/f/cases/2482 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #89: 2651-CanvasencryptedParagraphboundscolor-has-no-senders-or-concrete-implementors
by ci-pharo-ci-jenkins2＠inria.fr Feb. 19, 2019

Feb. 19, 2019

There is a new Pharo build available! The status of the build #89 was: SUCCESS. The Pull Request #2652 was integrated: "2651-CanvasencryptedParagraphboundscolor-has-no-senders-or-concrete-implementors" Pull request url: https://github.com/pharo-project/pharo/pull/2652 Issue Url: https://pharo.fogbugz.com/f/cases/2651 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #88: Log the Target VM date and CommitHash during bootstrap
by ci-pharo-ci-jenkins2＠inria.fr Feb. 19, 2019

Feb. 19, 2019

There is a new Pharo build available! The status of the build #88 was: SUCCESS. The Pull Request #2650 was integrated: "Log the Target VM date and CommitHash during bootstrap" Pull request url: https://github.com/pharo-project/pharo/pull/2650 Issue Url: https://pharo.fogbugz.com/f/cases/Issue2459 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

The HiDPI Issue
by Eric Gade Feb. 18, 2019

Feb. 18, 2019

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

6 7