- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] pharo.prg is down

by ducasse

Thanks I did not know. > On 5 Feb 2019, at 22:33, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > There is a documentation I wrote when preparing server migration (none before) hosted at https://gitlab.inria.fr/RMOD/servers. > It is a private repository as it contains sensitive information. > >> Le 5 fÃ©vr. 2019 Ã 14:58, ducasse <stepharo(a)netcourrier.com> a Ã©crit : >> >> Do we have a document somwhere to know what to do >> if knowing people are in vacation? >> >> >> >>> On 5 Feb 2019, at 13:57, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: >>> >>> Thanks for the report. >>> I restarted the service. It is now back on line. >>> >>> Cheers, >>> Christophe >>> >>>> Le 5 fÃ©vr. 2019 Ã 13:41, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >>>> >>>> Hi, >>>> >>>> pharo.org looks down: >>>> https://downforeveryoneorjustme.com/pharo.org >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.feenk.com >>>> >>>> âHow do you feenk today?" >>>> >>>> >>> >>> >> >> >> > >

Feb. 18, 2019

Re: [Pharo-dev] shortcut to browser ref to a class

by ducasse

Yes it works. Sorry I was reading the ml Stef > On 6 Feb 2019, at 11:48, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Stef. > > cmd+n does not work for you? > > Ð²Ñ, 5 ÑÐµÐ²Ñ. 2019 Ð³., 19:21 ducasse stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>: > Hi > > Is it me or we lost cmd + shift B to browse refs to class in Calypso? > > Stef > > >

Feb. 18, 2019

Re: [Pharo-dev] The HiDPI Issue

by Eric Gade

Aha, interesting script. Related question: since I am a Launcher user, is there a way to modify how individual images are launched (for example, being able to use this script)? On Mon, Feb 18, 2019 at 8:52 AM Markus Fritsche <mfritsche(a)reauktion.de> wrote: > OT: Have a look at the ârun_scaledâ-script that uses xrpa. > > I am using KDE5 (before that XFCE with a dpi setting of 192). Sometimes it > resets scaling during a sleep, but it mostly works. > > Kind regards > Markus > > > -- Eric

Feb. 18, 2019

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

by Nicolas Cellier

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. 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. The question is whether it is possible to come to acceptable compromise? 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." > >

Feb. 18, 2019

Re: [Pharo-dev] The HiDPI Issue

by Markus Fritsche

OT: Have a look at the ârun_scaledâ-script that uses xrpa. I am using KDE5 (before that XFCE with a dpi setting of 192). Sometimes it resets scaling during a sleep, but it mostly works. Kind regards Markus

Feb. 18, 2019

[ANN] Iceberg 1.5.7 (pharo6 is back)

by Guillermo Polito

Hi all, I'm on vacations, so I've produced a new patch version of Iceberg :). This version restores compatibility with Pharo6, which was broken since latest changes done for Pharo7 64bit support. https://github.com/pharo-vcs/iceberg/releases/tag/v1.5.7 I hope people still using Pharo6 find this useful. You should be able now to use again the update script to use latest iceberg on it. I've updated the doc to point to the latest supported version: "load iceberg"Metacello new baseline: 'Iceberg'; repository: 'github://pharo-vcs/iceberg:v1.5.?'; onWarningLog; load. On this same direction, we have been discussing that v1.5.* will be the latest minor version supporting Pharo6. Still, we will keep integrating bugfixes and patches as they come. New versions (>= 1.6) will host the new features and will be available and maintained for both the stable Pharo7 and the in-development Pharo8 versions. Enjoy, Guille

Feb. 18, 2019

[Pharo 8.0] Build #87: Fix `Week>>year:week:` to return a correct ISO week (starting on Monday)

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

There is a new Pharo build available! The status of the build #87 was: FAILURE. The Pull Request #2508 was integrated: "Fix `Week>>year:week:` to return a correct ISO week (starting on Monday)" Pull request url: https://github.com/pharo-project/pharo/pull/2508 Issue Url: https://pharo.fogbugz.com/f/cases/2455 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 18, 2019

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

by Esteban Lorenzano

Hi, Iâm so not wanting to be part of this discussion, but here I am. Just because it was mentioned my name in a way I consider inaccurate. > On 17 Feb 2019, at 21:27, 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 <mailto:astares@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â. This is textually my answer (even with the English errors): â¦ âAnyway the answer will be no :) This was considered, and even the first implementation of tonel had it. Now, this was discarded because it does not works with git (or other file backends). It was not even me who complained first (as I said, I implemented it). It was Dale and other people used to work on git. Thing is, putting timestamps it will generate conflicts massively when there is no reason to it. So, we drop itâ¦ and we add support for the equivalent using the tool we use (iceberg gives you not just the author that modified last the method but all of them, along the history). I hope is an understandable reason?â And then in other mail of same thread I suggested an approach viable for squeak: "Now, what Iâm sure is that if you are trying of using the 100% of Monticello and to use git just as another repository backend, it will not work (we already tried). It will consume far too much effort and you will finish beating the purpose of use git and a file-based-format, and you will be in the worst of two worlds :) We started like that, and we ended up implementing Iceberg to take benefit of the tools we are using. In the middle, there was/is gitfiletree. (I think I suggested you to look at it to adapt it for tonel and squeak). Gitfiletree uses OSProcess to call git as external tool and it makes all the operations needed. â Now, what I was suggesting was a way to use tonel backed with OSProcess (which works in squeak) instead backing it with libgit2 as us. Since they need the blame support, they could use OSProcess and external git for it. Of course squeak (and any other dialect) are free to take tonel and adapt it to their needs (in fact, Mariano extended Tonel for VA specific things). And Pharo can read that format but it will ignore all extensions. Now, another problem is to WRITE: Pharo would write those packages in âpharo formatâ and that information would be lost. And in the case of VMMaker, if the idea is to be able to work on both sides, then Pharo needs to âhonourâ that format, it cannot just read it and ignore it later. So this creates an incompatibility that needs to be handled. Anyway, as you can see my answer was not ânot under any circumstancesâ. Was âno, because is not convenientâ. Esteban > > 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. 18, 2019

Esteban's ChangeLog week of 11 February 2019

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 11 February 2019 to 17 February 2019. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=11/2/2019&to=17/2/2019 ChangeLog ========= 14 February 2019: ----------------- * Small fix-a-day: [https://github.com/pharo-project/pharo/pull/2530](https://github.com/pharo-… (fix some tonel tests failing) cheers! Esteban

Feb. 18, 2019

VMMaker in Pharo [Was: Squeak and Tonel]

by Tudor Girba

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."

Feb. 18, 2019