- Pharo-dev - lists.pharo.org

Migrating your projects to GitHub? Do not forget to tag your project!

by Esteban Lorenzano

Hello, Just a gentle reminder to tag your project as âPharoâ, so a search engine can find it better! Esteban

April 14, 2020

Re: [Pharo-dev] Not seeing hidden character is confusing :)

by tbrunz

Something like this, yes. And the visualized codes in the editor should be the *default* view -- there are little to no cases where embedded non-printable control codes would be intentional. I can't even think of a case where you would want to press a key combination to make them disappear... And I would argue that turning off this visualization of non-printable codes should be a menu choice to toggle them invisible, not a key sequence. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 14, 2020

Re: [Pharo-dev] Not seeing hidden character is confusing :)

by Christopher Fuhrman

> > It was a CTRL-X The context was pair-programming (we were using HonorÃ©'s Mac). I'm not much of a Mac user anymore, and so on Windows I do CTRL-X to cut (it's a reflex). But on a Mac one must use the Command key, right? I think this is how it happened, but I'm not 100% sure. On Mon, 13 Apr 2020 at 16:13, Christopher Fuhrman < christopher.fuhrman(a)etsmtl.ca> wrote: > HonorÃ© and I had a debugging session during my sabbatical that was 2+ > hours because of a frustrating hidden character that got inserted in a > string that was executed in a Shell command. It was not possible to see it > in the Pharo editor. > > It was a CTRL-X at some point, here's the commit where I removed it: > https://github.com/fuhrmanator/GitMiner/commit/0b1e564ba2c25fb9cf7dfa925b06… > > On Mon, 13 Apr 2020 at 15:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> Hi >> >> I have the impression that we can introduce hidden characters >> while typing code and this is a problem to me because we do not see them >> :) >> I got for example selhiddenf and it can lead to strange situations. >> >> I will try to chase the key combinations that produce them and see how we >> can control and avoid this situation. >> If you find the key combination please let me know. >> >> 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 >> >> > > -- > Christopher Fuhrman, P.Eng., PhD > > *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de > l'informationÃTS (Ãcole de technologie supÃ©rieure)* > > http://profs.etsmtl.ca/cfuhrman > +1 514 396 8638 > *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec* > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

April 13, 2020

Re: [Pharo-dev] Not seeing hidden character is confusing :)

by Christopher Fuhrman

HonorÃ© and I had a debugging session during my sabbatical that was 2+ hours because of a frustrating hidden character that got inserted in a string that was executed in a Shell command. It was not possible to see it in the Pharo editor. It was a CTRL-X at some point, here's the commit where I removed it: https://github.com/fuhrmanator/GitMiner/commit/0b1e564ba2c25fb9cf7dfa925b06… On Mon, 13 Apr 2020 at 15:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I have the impression that we can introduce hidden characters > while typing code and this is a problem to me because we do not see them :) > I got for example selhiddenf and it can lead to strange situations. > > I will try to chase the key combinations that produce them and see how we > can control and avoid this situation. > If you find the key combination please let me know. > > 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 > > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

April 13, 2020

Re: [Pharo-dev] Not seeing hidden character is confusing :)

by Cyril Ferlicot

Shift + space = insecable space It would be cool to be able to toggle a mode as in text editor where hidden characters are represented by a symbol. https://www.avrfreaks.net/sites/default/files/notepadpp.PNG On Mon, Apr 13, 2020 at 8:44 PM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Hi > > I have the impression that we can introduce hidden characters > while typing code and this is a problem to me because we do not see them :) > I got for example selhiddenf and it can lead to strange situations. > > I will try to chase the key combinations that produce them and see how we > can control and avoid this situation. > If you find the key combination please let me know. > > 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 > -- Cyril Ferlicot https://ferlicot.fr

April 13, 2020

Re: [Pharo-dev] Not seeing hidden character is confusing :)

by tesonep＠gmail.com

Yes... We need to show something. At least in the code editor, when it is clear we don't want them. On Mon, Apr 13, 2020, 20:44 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I have the impression that we can introduce hidden characters > while typing code and this is a problem to me because we do not see them :) > I got for example selhiddenf and it can lead to strange situations. > > I will try to chase the key combinations that produce them and see how we > can control and avoid this situation. > If you find the key combination please let me know. > > 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 > >

April 13, 2020

Not seeing hidden character is confusing :)

by StÃ©phane Ducasse

Hi I have the impression that we can introduce hidden characters while typing code and this is a problem to me because we do not see them :) I got for example selhiddenf and it can lead to strange situations. I will try to chase the key combinations that produce them and see how we can control and avoid this situation. If you find the key combination please let me know. 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

April 13, 2020

Re: [Pharo-dev] [Vm-dev] Pony for Pharo VM

by Ben Coman

Hi Shaping, Just to get in the right frame of mind, consider that because of the Blub Paradox (http://www.paulgraham.com/avg.html) you are going to have a hard time convincing people to "change to this language because of Feature X" just by saying so. You need to dig deeper. Now I I took a quick look to see what I could learn about Pony and the main interesting thing is its "Reference Capabilities". Indeed, it seems Pony's purpose is the POC for that research. I watched two videos... [1] Ãredev 2017 - Joe McIlvain - Pony - A Language for Provably Safe Lockless Concurrency https://www.youtube.com/watch?v=9NH4bVfbvYI [2] Sophia Drossopoulou - Pony for Safe, Fast, concurrent programs - Codemesh 2017 https://www.youtube.com/watch?v=e_bES30tFqI So my "quick" assessment is to consider Reference Capabilities not a Type System but a Meta-type System. [2] says "They are not a property of an object, but define how I can look at an object." To summarize the videos... [1]@29:15... [image: image.png] [image: image.png] [2]@13:40... [image: image.png] [2]@24:40... [image: image.png] [2]@28:30... [image: image.png] So you say... > I want to use the Pony concurrency model at the Smalltalk level. Thatâs the gist of it. > Otherwise, I want a Smalltalk, not a statically compiled language. I believe you have the wrong end of the the stick promoting that the VM needs to be redeveloped using Pony to get the Reference Capabilities at the Smalltalk level. After you Ahead-Of-Time compile the VM, the compiler is left behind. The features of the compiler don't automatically flow through to Smalltalk level. A third option could be to extend to the existing "Immutability capability" of the VM. The six Reference Capabilities might be stored in the Spur Object Header using a re-purposed Immutability bit plus the two free "green" bits. https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/ "Reference Capabilities for Dynamic Languages" could be a strong PhD project. cheers -ben On Fri, 10 Apr 2020 at 17:56, Shaping <shaping(a)uurda.org> wrote: > > Hi Ken. > > Not to discourage people, but I have not seen cases where a "strong > type system would be able to scale for _real_ Smalltalk applications. > > Youâre right. It doesn't. I'm not suggesting that. > > The type safety is not for app-level Smalltalk development. It's for building the VM only. > > The six ref-cap ideas for sharing data reliably between actors are not hard to grasp, but they take some getting used to, and involve some mental load. I don't want that much (concurrency-related or any other) implementation detail in the domain layer, much in the same vein as: I donât use Forth because I donât want to see stack acrobatics (ROTs and DUPs, etc.) amidst domain-level state-changes (FirePhotonTorpedo). Itâs distracting. It dilutes focus on the domain work/layer, and tends to cause mistakes there. > > > > The programmerâs domain logic and the concurrency-integrity provided by the ref-caps are different layers of thought and structure. The ref-caps are, however, mixed freely with domain logic in current Pony code. I think thatâs a mistake. But thatâs how it is now. I think of this layer mixing as an intermediate design stage of Pony. I want to abstract-out some or all ref-caps as the VM is built. > > Pony language is not the remarkable thing here. I see it as a better C or better Rust. Itâs very good (as Algol-60-ish-looking crap-syntaxes go), but thatâs not what this is about. Itâs about the actor programming, the concurrency model, and the guarantees given by use of the ref-caps. We would still obviously need to respect the Pony compilerâs determination of where ref-cap use is correct or not. Your Pony program wonât compile if you donât use the ref-caps correctly, and you donât get the guarantees or a running program without the compile. Much easier, therefore, might be to go the other way by changing Pony to support dynamic types without violating the invariants that allow the ref-caps (under the hood, abstracted out) to make the concurrency guarantees. Work Smalltalk dynamism into Pony, instead of building a Smalltalk VM with Pony.

April 13, 2020

[Pharo 9.0] Build #233: Introduce UnhandledException hierarchy

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

There is a new Pharo build available! The status of the build #233 was: FAILURE. The Pull Request #6131 was integrated: "Introduce UnhandledException hierarchy" Pull request url: https://github.com/pharo-project/pharo/pull/6131 Issue Url: https://github.com/pharo-project/pharo/issues/unhandledExceptionHier Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 13, 2020

[Pharo 9.0] Build #232: FAILURE

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

There is a new Pharo build available! The status of the build #232 was: FAILURE. Could not extract further issue information from commit message: Update cleanup-report.md Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 13, 2020