- Pharo-dev - lists.pharo.org

Question on KmGlobalDispatcher

by David Richards

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

Feb. 19, 2019

Re: [Pharo-dev] Using Metacello scripting API with non-github repo

by Cyril Ferlicot

On Tue, Feb 19, 2019 at 2:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 ? Hi, I think non default ssh port will not be supported by Metacello. I had to add it for gitlab to be able to reference repositories from a self hosted gitlab with non default ssh port. I guess the same can be done for bitbucket but it I doub it's already done. For Gitlab I added it in MCGitlabRepository for the Metacello part and in the Iceberg extensions of this class to use the new infos in Iceberg. (Method scpUrl) > > Sven > > > -- Cyril Ferlicot https://ferlicot.fr

Feb. 19, 2019

Re: [Pharo-dev] Using Metacello scripting API with non-github repo

by Sven Van Caekenberghe

I can add that Iceberg _can_ clone from my URL, it just seems that Metacello doesn't understand it. > On 19 Feb 2019, at 14:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 > >

Feb. 19, 2019

Using Metacello scripting API with non-github repo

by Sven Van Caekenberghe

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

Feb. 19, 2019

[Pharo 8.0] Build #91: Remove DebugSession>>activePC: and DebugSessio>>previousPC:

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

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…

Feb. 19, 2019

Re: [Pharo-dev] [Pharo-users] About Iceberg

by Tim Mackinnon

Yes I agree - when there is so much discussion and debate going on, its easy to lose sight of the hard work and determination that went into getting us to this brave new world. I too want to shout a big thank you for the tooling and also the support that goes along with that. I love been able to think a bit more polyglot, and use tools/languages more easily side by side - although of course I want to hold on to what makes Smalltalk special (which is tons of stuff). I particularly love being able to feel like its easier to contribute - updating readmeâs and docs is trivial in a web browser now - just correct them and submit a PR. And on the receiving side - GitHub makes it easy to discuss the fix, alter it, or simply approve it. Equally - modern build tools easily detect the change, pull the code and rebuild and package it (and cheap scalable infrastructure). Its also getting easier and easier to submit code fixes too - and the VCS skills you learn doing this are transferable beyond Smalltalk - so its a big win win. So yes guys - thanks for hanging in for us! Tim > On 19 Feb 2019, at 08:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 > > > > >

Feb. 19, 2019

[Pharo 8.0] Build #90: 2482 initial fuel update for pharo 8

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

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…

Feb. 19, 2019

[Pharo 8.0] Build #89: 2651-CanvasencryptedParagraphboundscolor-has-no-senders-or-concrete-implementors

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

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…

Feb. 19, 2019

Re: [Pharo-dev] About Iceberg

by Damien Pollet

ð On Tue, 19 Feb 2019 at 10:06, Hilaire <hilaire(a)drgeo.eu> wrote: > I join your thank you note, although I only use one half, the tonel > part, it is pleasant to be able to commit to file base repository and > use related tools. > > Le 19/02/2019 Ã 09:50, Sven Van Caekenberghe a Ã©crit : > > This is a thank you note about Iceberg. > > -- > Dr. Geo > http://drgeo.eu > > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Feb. 19, 2019

Re: [Pharo-dev] [Vm-dev] VMMaker in Pharo [Was: Squeak and Tonel]

by Tudor Girba

Hi Nicolas, > On Feb 18, 2019, at 3:12 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Hi Tudor, > Retrieving author and timestamp from git history is doable. > The question is whether it will be still possible to contribute thru MC or not. > If it is metadataless MC, there's no point, it's unusable. > I think that the minimal metadata we have to maintain is the last MC ancestor. This can be done by convention thru a .last_mc_ancestor file. Of course, there will be conflicts, but easy to (automatically) solve. > That could also lie in commit message, but is somehow a bit more fragile... it would mean scanning thru ancestry for getting such information. > By symmetry, merged agit sha should be in mc commit, either a specific file in mcz, or commit message. That sounds intriguing and interesting at the same time. However, I do not have a qualified enough opinion on this matter. > Also note that vmmaker history as proposed in opensmalltalk pr was broken (no respect of branch topology). Maybe retry with Squot? > https://github.com/hpi-swa/Squot > There is still a problem of synching commits of other packages (cog, various plugins ...), and if nobody is working on it, we are condemned to a mediocre solution. > IMO, a broken history has not much interest. We know it was broken, and thank you for pointing it out. We went through multiple iterations, and we think the latest one should be better. Please take a look and let us know if you still find issues: https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker > The question is whether it is possible to come to acceptable compromise? As I wrote in the reply to Eliot, I believe the main point at this moment is not Git, but getting the VMMaker code to run in Pharo. I think we should start there, and see if we can produce an alternative environment that provides value. Cheers, Doru > Le lun. 18 fÃ©vr. 2019 Ã 07:33, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > Hi Eliot, > > You raise a few technical concerns related to VMMaker that seem addressable: > > 1. Rendering technology: Both in Pharo and in GT, there exist in-image canvases, Athens and Sparta respectively, that are backend independent. This allows us to have image-based drawing logic, like BitBlt or even better, the drawing capabilities that Juan Vuletich built in Morphic 3, transparently. In fact, we even started to look at the code from Morphic 3 and we think itâs not much effort to make it work behind Sparta. This would provide a complete solution that would not rely on any external libraries. > > 2. Git history. We used to have the author and timestamp in the metadata of Tonel but because it generated unwanted conflicts it was decided to remove it. I think this is a good decision and one based on the experience of using it. But, why do you think the algorithm of retrieving Git could not be made to work in Squeak? Is there a specific technical reason, or is it more that you do not see the effort being spent in this direction? I am asking to understand what could a possible solution be. > > > But, letâs take a step back. George and Andrei did move the VMMaker code, including all its history, into Git using (and enhancing) https://github.com/peteruhnak/git-migration. > > The code is here: > https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker > > Our goal was to make the code loadable and runnable in Pharo through Git. We have a reproducible process to produce this history, and this means that we can also synchronize all changes from the Monticello VMMaker repository and produce a history-preserving Git repository. > > The current code comes with a BaselineOfVMMaker that loads in Pharo, and the code generation seems to work to a good extent without much effort. There is still work that needs to be done especially on the simulation part, but we think most of it can be addressed through a Pharo-specific package that provides compatibility logic. > > I see two benefits for doing this: > 1. It allows people in Pharo to play with the VM within the Pharo context and consequently contribute. > 2. It allows us to build an environment dedicated for VM development without affecting the current contribution process. We can judge later whether this is useful. > > Cheers, > Doru > > > > On Feb 17, 2019, at 9:27 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > 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 > > -- > www.feenk.com > > âSoftware has no shape. Actually, it has no one shape. It has many." > -- www.feenk.com âHow do you feenk today?"

Feb. 19, 2019