Re: [Pharo-dev] DebugSession>>activePC:

[ducasse via Pharo-dev]

--- Begin Message ---
>> 
>> On my TODO is to make it stand-alone and provide is as a “compatibility 
>> transform”, too.
> 
> I have to dig because I remember that I went over all the deprecation in 
> Pharo 60 and started to look at the ones that I 
> could “transformified” so that we get a nice package that rewrite more :)
> 
> 
>> So we can add it to methods that we want to keep for compatibility, but they 
>> will nevertheless transform the code automatically.
>> (this then might be disabled in production to not transform)
> 
> Yes I like that I will look for my code. 

Apparently I published under 

MCSmalltalkhubRepository
owner: 'PharoExtras'
project: ‘Migrator'

Several packages 
MigratorPharo60 contains what I did for Pharo60
probably 
Migrator contains some of the Pharo70 

Now I would like to understand how to organise it. 

I have the impression that we should keep the one that can be transformed.

I do not think that we should go to Pharo50 because it is too old. 

Stef




--- End Message ---

Re: [Pharo-dev] Better management of encoding of environment variables

[ducasse via Pharo-dev]

--- Begin Message ---

>>> I think that will just overcomplicate things. Right now, all Strings in 
>>> Pharo are unicode strings.
>> 
>> Cool. I didn't realise that.  But to be pedantic, which unicode encoding? 
>> Should I presume from Sven's "UTF-8 encoding step" comment below 
>> and the WideString class comment  "This class represents the array of 32 bit 
>> wide characters"
>> that the WideString encoding is UTF-32?  So should its comment be updated to 
>> advise that?
> 
> Not really, Pharo Strings are a collection of Characters, each of which is a 
> Unicode code point (yes a 32 bit one).
> 
> An encoding projects this rather abstract notion onto a sequence of bytes,
> 
> UTF-32 (ZnUTF32Encoder, https://en.wikipedia.org/wiki/UTF-32 
> ) is for example endian dependent.
> 
> Read the first part of
> 
> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/Zinc-Encoding-Meta/Zinc-Encoding-Meta.html
>  
> 

I love that book :)

This is too cool to have cool doc--- End Message ---

Re: [Pharo-dev] DebugSession>>activePC:

[ducasse via Pharo-dev]

--- Begin Message ---
Hi marcus

>> I simply love the dynamic rewriting this is just too cool. We should 
>> systematically use it. 
>> I will continue to use it in any deprecation. 
>> 
> 
> On my TODO is to make it stand-alone and provide is as a “compatibility 
> transform”, too.

I have to dig because I remember that I went over all the deprecation in Pharo 
60 and started to look at the ones that I 
could “transformified” so that we get a nice package that rewrite more :)


> So we can add it to methods that we want to keep for compatibility, but they 
> will nevertheless transform the code automatically.
> (this then might be disabled in production to not transform)

Yes I like that I will look for my code. 
> 
>> Now I have a simple question (You can explain it to me over lunch one of 
>> these days).
>> 
>> I do not get why RBAST would not be a good representation for the compiler?
>> I would like to know what is the difference.
>> 
> I think it is a good one. I have not yet seen a reason why not. But remember, 
> Roel left Squeak because his visitor pattern for the compiler was rejected as 
> a dumb idea… so there are definitely different views on core questions.
> 
> E.g. the RB AST is annotated and the whole things for sure uses a bit more 
> memory than the compiler designed for a machine from 1978.
> 
>> You mean that before going from BC to AST was difficult?
> 
> You need to do the mapping somehow, the compiler needs to remember the BC 
> offset in the code generation phase and the AST (somehow) needs to store that 
> information (either in every node or some table).
> 
>> How opal performs it? It does not use the source of the method to recreate 
>> the AST but he can do it from the BC?
>> 
> 
> It uses the IR (which I still am not 100% sure about, it came from the old 
> “ClosureCompiler” Design and it turned out to be quite useful, for example 
> for the mapping: every IR node retains the offset of the BC it creates, then 
> the IR Nodes
> retain the AST node that created them. 
> 
> -> so we just do a query: “IRMethod, give me the IRInstruction that created 
> BC offset X. then “IR, which AST node did create you? then the AST Node: what 
> is your highlight interval in the source?
> 
> The devil is in the detail as one IR can produce multiple byte code offsets 
> (and byte codes) and one byte code might be created by two IR nodes, but it 
> does seem to work with some tricks. 

ok I see.
And all in all it is really nice. 

> Which I want to remove by improving the mapping and even the IR more… there 
> is even the question: do we need the IR? could we not do it simpler? 
> 
> The IR was quite nice back when we tried to do things with byte code 
> manipulation (Bytesurgeon), now it feels a bit of an overkill. But it 
> simplifies e.g. the bc mapping.


We should document this because this is cool. 

Stef



--- End Message ---

Re: [Pharo-dev] DebugSession>>activePC:

[ducasse via Pharo-dev]

--- Begin Message ---
I simply love the dynamic rewriting this is just too cool. We should 
systematically use it. 
I will continue to use it in any deprecation. 

Now I have a simple question (You can explain it to me over lunch one of these 
days).

I do not get why RBAST would not be a good representation for the compiler?
I would like to know what is the difference.

You mean that before going from BC to AST was difficult?
How opal performs it? It does not use the source of the method to recreate the 
AST but he can do it from the BC?

Stef


>> 
> 
> But I like the “high level”: using a shared AST between the compiler and the 
> tools *and* having a mapping BC -> AST -> Text.
> 
> Of course I understand that the choice to use the RB AST for the compiler is 
> not a “traditional” one.. but it turned out to work very well *and* it brings 
> some amazing power, as we have now not only a mapping bc->text offset, but a 
> mapping bc->AST, too. This e.g. (just a a simple example) makes the magic of 
> the runtime transforming deprecations possible. See #transform on class 
> Deprecation, the #sourceNodeExecuted:
> 
> transform
>   | node rewriteRule aMethod |
>   self shouldTransform ifFalse: [ ^ self ].
>   self rewriterClass ifNil:[ ^ self signal ].
>   aMethod := self contextOfSender method.
>   aMethod isDoIt ifTrue:[^ self]. "no need to transform doits"
>   node := self contextOfSender sourceNodeExecuted.
>   rewriteRule := self rewriterClass new 
>   replace: rule key with: rule value.
>   (rewriteRule executeTree: node)
>   ifFalse: [ ^ self ].
>   node replaceWith: rewriteRule tree. 
>   Author 
>   useAuthor: 'AutoDeprecationRefactoring'
>   during: [aMethod origin compile: aMethod ast formattedCode 
> classified: aMethod protocol].   
> 
> 
>   Marcus

--- End Message ---

Re: [Pharo-dev] Better management of encoding of environment variables

[ducasse via Pharo-dev]

--- Begin Message ---
> 
> So making the primitives return ByteArray instances instead of ByteString 
> should be safe enough :).
> But this is in my opinion clearly a hack instead of fixing the real problem, 
> and we have to be careful to guard such patterns with comments everywhere 
> explaining why the bytearray conversion is really needed there…

Guillermo what is the correct way to do it?

> Would it be helpful to have getenv primitives that answer ByteArray
> instead, and to let all conversion (including in OSProcess) be done in
> the image?
> 
> Well, personally I would like that getenv/setenv and getcwd setcwd support 
> are not in a plugin but as a basic service provided by the vm.
> 
> Cheers,
> Guille
>  
> 
> Thanks,
> Dave
> 
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr 
> 
> 
> Web: http://guillep.github.io 
> Phone: +33 06 52 70 66 13

--- End Message ---

Re: [Pharo-dev] Purpose of VM [was: Re: Better management of encoding of environment variables]

[ducasse via Pharo-dev]

--- Begin Message ---

> > 
> > And if it's in the image you get to do the programming in Smalltalk rather 
> > than C or Slang, which is more fun for most of us. And, let's face it, fun 
> > is an important metric in an open-source project -- things that are fun are 
> > much more likely to get done.
> 
> +100
> 
> The VM *is* developed in Smalltalk
> https://www.researchgate.net/publication/328509577_Two_Decades_of_Smalltalk_VM_Development_Live_VM_Development_through_Simulation_Tools
>  
> 
It is not the point of the message of Martin. I imagine that Martin and Sven 
understand it perfectly that the VM is written in Slang and that there
is a simulator. Still many of us agree with their analysis. The VM logic should 
be on execution and try to delegate to the image most of the rest. 

Stef--- End Message ---

Re: [Pharo-dev] Some clarifications (was DebugSession>>activePC:)

[ducasse via Pharo-dev]

--- Begin Message ---
So when I read your emails everything looks perfect from your side. 
So let it be.

Stef


> On 16 Jan 2019, at 23:15, Eliot Miranda  wrote:
> 
> Hi Stef,
> 
> 
> thanks for taking the time to respond so thoughtfully.
> 
> On Mon, Jan 14, 2019 at 12:20 AM ducasse  > wrote:
> Hi Eliot
> 
> I would like to make some clarifications. 
> 
> Preamble: 
> --
> I was thinking that I should not reply but I think that I have the right to 
> clarify a bit because I do not like several points. 
> I reply as Stef "the guy that had the vision of Pharo and that spent 10 years 
> pushing and building Pharo.”
> So I think that it makes me credible enough.
> 
> You do not have to defend your credentials.  The community is aware of your 
> contributions.
>  
> 
> My points:
> -
> - With you this is always the same: I’m too emotional and it ends 
> everything. Stephane is emotional 
> so we cannot communicate with him. You often place yourself as a 
> professional and that I’m emotional. 
> Could you stop this little game because to me it starts to be a bit 
> boring? Or I will just put a filter and 
> trash systematically your emails. 
> 
> I do not say "Stephane is emotional so we cannot communicate with him.".  I 
> do think you let your emotions show too much and that it makes communication 
> with you difficult.  But more importantly, a leader is more effective if they 
> can reign in their emotions and not criticize people in public, and so on.  I 
> mention your emotionality not to denigrate you but to hope that communication 
> in the community can improve.  You have as much to gain as anyone, arguably 
> more, from not taking things so personally and being less emotional.  If we 
> analyze the above statement we see that it is coercive: stop criticizing my 
> emotionality or I will stop reading your emails.  One could instead be open: 
> "Why is it that you criticize me as being emotional?", "Can you give me 
> evidence of me being emotional?" etc.  Instead you open with a defensive 
> position, and with a threat.  If, later on, having started filtering out my 
> emails, you found you had to respond again, because we have common interests 
> and those interests cause us to need to interact, you will put yourself in a 
> weak position having to back track on your filtering.
> 
> 
> - Last week you told us that time bombing our process was a bad idea 
> in an answer about settings
> keeping references instead of releasing them. 
> 
> No.  I said that my opinion is that time boxing releases is a bad idea. This 
> is not about settings, it is about the content of releases. For me, a release 
> is done when it satisfactorily meets objective release criteria: tests pass, 
> a subset of new features planned for the release are functional, etc.  That 
> releasing something that is incomplete or broken does not help.  I base this 
> on long experience with VisualWorks, Qwaq and Squeak.  
> 
> First this had nothing to do with the problem.
> You see P7 was delayed because we considered that the system was not 
> ready but P7 should be released.   
> May I make the remark that the world is using time-based delivery?
> 
> May I make the remark that what others choose to do does not make it right?
>  
> - About CMake, you may be right that makefile is better than CMake 
> but a part of the world is using 
> CMake and the net result is that we lost our effort and 
> infrastructure just to follow you. Ronie uses CMake.  
> Igor which I consider as a talented developer used CMake because he 
> thought it was the best tool 
> he should use. 
> 
> Yes, and I disagree about the way that they use it, and for good reason.  I 
> have defended my use of Makefiles for a long time, for objective reasons.  I 
> have also proposed good ways for using CMake (to derive a platform-specific 
> header file defining available platform-specific features).  But my objection 
> to Igor's process was that he generated sources on each build.  And my 
> objections to Ronie's use of CMake for the minheadless build are that a) it 
> is slow and b) explicit feature sets are much better than the implicit 
> feature sets that arise when using CMake.
>  
> - About infrastructure and process.
> I wanted to check the REplugin this week end because we should use it 
> since the world
> is using Perl reg-expression and I could not find the code of the 
> plugin on github.
> I saw that some plugin code is not even versioned and only available 
> on a strange ftp and it was surprising 
> to me. I’m still surprised that after 3 years (when esteban requested 
> that all plugin code are grouped together
> in a single place, this is still not the case). 
> 
> Esteban is free to move the code into VMMaker.oscog.  VMMaker.oscog below to 
> 

[Pharo-dev] wish for p8: parserewriter UI

[Stéphane Ducasse via Pharo-dev]

--- Begin Message ---
Hi 

I’m rewriting around 400 methods following a pattern that the parsetree 
rewritter could easily 
transform for me and I would love to have a UI and integrate the tools did by 
Yuriy to understand patterns as a default tool in the tool ecosystem. 

stef


Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / 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

--- End Message ---

Re: [Pharo-dev] Availability of Smallapack in Pharo6.0

[Stéphane Ducasse via Pharo-dev]

--- Begin Message ---

> 
> Hi Denis,
> OK, but hiding is troubling...
> When I came from VW, I found that Squeak categories matching package names 
> was a quick and dirty hack.
> Since then, I find it works remarkably well, it is somehow a declarative meta 
> information (method property), and I much prefer that to hidden package 
> classification accessible from an IDE only.

I agree :) and I told that several times in the past :)
We also lost the inplace edit and the logic sometimes is super confusing. 

> It still happens to me to loose methods in VW because they are not packaged 
> or wrongly packaged, so I'm not sure that cleaning is winning in that case.
> And if you go with multiple classifications, then there's no reason to not 
> keep the hack.

For now multiple classifications is not in our priority since our list is 
already too long. 

> 
> But I'll come back to it, tools are generally better in ph7 than ph6. Stay 
> tuned.


Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / 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

--- End Message ---

[Pharo-dev] About resurrecting the RE package and plugin

[ducasse via Pharo-dev]

--- Begin Message ---
Hi 

I would really like to resurrect the REPlugin and its image side abstraction 
because
I think that this is important to support Perl level regex since it will help 
people to reuse their knowledge. 
If you are interested in helping let us know. 

Stef

<>
--- End Message ---

Re: [Pharo-dev] DebugSession>>activePC:

[ducasse via Pharo-dev]

--- Begin Message ---
Eliot I would like also two points to this.

- First we asked thomas to write tests about the debugger model and you see if 
they would be tests about methods we could understand 
that they are used and control what they do. So we should all thank thomas for 
his energy in this not so easy task.

- Second it would be nice if you could refrain to be systematically negative 
about what we are doing. I think that our development process
is much better than many others :) It is not perfect because this does not 
exist. 
I think that we are doing a great job make Smalltalk cool. And yes it may 
happen that one untested, undocumented method
get lost. I think that we are doing pretty good given the resources we have. 

Stef

> On 10 Jan 2019, at 15:11, Eliot Miranda  wrote:
> 
> Hi Thomas,
> 
>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
>>  wrote:
>> 
>> 
> 
> in a stack of contexts the active pc is different for the top context.  For 
> other than the top context, a context’s pc will be pointing after the send 
> that created the context above it, so to find the pc of the send one finds 
> the previous pc.  For the top context its pc is the active pc.
> 
> Typically the debugger is invoked in two different modes, interruption or 
> exception. When interrupted, a process is stopped at the next suspension 
> point (method entry or backward branch) and the top context in the process is 
> the context to be displayed in the debugger.  When an exception occurs the 
> exception search machinery will find the signaling context, the context that 
> raised the exception, which will be below the search machinery and the 
> debugger invocation above that. The active pc of the signaling context will 
> be the of for the send of digbsl et al.
> 
> So the distinction is important and the utility method is probably useful.
> 
> Do you want to remove the method simply because there are no senders in the 
> image?
> 
> If so, this is indicative of a serious problem with the Pharo development 
> process.  In the summer I ported VMMaker.oscog to Pharo 6.  Now as feenk try 
> and build a VMMaker.oscog image on Pharo 7, the system is broken, in part 
> because of depreciations and in part because useful methods (isOptimisedBlock 
> (isOptimizedBlock?) in the Opal compiler) have been removed.
> 
> Just because a method is not in the image does not imply it is not in use.  
> It simply means that it is not in use in the base image.  As the system gets 
> modularised this issue will only increase.  There are lots of collection 
> methods that exist as a library that are not used in the base image and 
> removing them would clearly damage the library for users.  This is the case 
> for lots of so-called system code.  There are users out there, like those of 
> us in the vm team, who rely on such system code, and it is extremely 
> unsettling and frustrating to have that system code change all the time.  If 
> Pharo is to be a useful platform to the vm team it has to be more stable.



--- End Message ---

Re: [Pharo-dev] DebugSession>>activePC:

[ducasse via Pharo-dev]

--- Begin Message ---
Thomas can you integrate such comments in the debugger class comment

@Eliot thanks for the explanation. 
About the method removed, could you please react less negatively? It would be 
nice. 
I cannot believe that you the guy that know the VM would get stopped to open a 
bug entry telling us that isOptimizedBlock
has been removed and it should not. How much time opening a bug entry can take? 
Under 1 min I guess. 
So why if marcus removed it inadvertly would you want to make him feel bad?
I don’t want people to feel bad. We can do mistake. I prefer a living system 
where people can make mistake
over a system that is frozen. In that case I prefer to go and code in Java or 
javascript for many obvious reasons. 
May be it was removed because it was in an extension method. 
So if you do not collaborate then how can we know it?

Stef

Usually at home I move the dirt outside so that people can take them away. 
Now if my kids tells me not to throw away then I don’t.



> On 10 Jan 2019, at 15:11, Eliot Miranda  wrote:
> 
> Hi Thomas,
> 
>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
>>  wrote:
>> 
>> 
> 
> in a stack of contexts the active pc is different for the top context.  For 
> other than the top context, a context’s pc will be pointing after the send 
> that created the context above it, so to find the pc of the send one finds 
> the previous pc.  For the top context its pc is the active pc.
> 
> Typically the debugger is invoked in two different modes, interruption or 
> exception. When interrupted, a process is stopped at the next suspension 
> point (method entry or backward branch) and the top context in the process is 
> the context to be displayed in the debugger.  When an exception occurs the 
> exception search machinery will find the signaling context, the context that 
> raised the exception, which will be below the search machinery and the 
> debugger invocation above that. The active pc of the signaling context will 
> be the of for the send of digbsl et al.
> 
> So the distinction is important and the utility method is probably useful.
> 
> Do you want to remove the method simply because there are no senders in the 
> image?
> 
> If so, this is indicative of a serious problem with the Pharo development 
> process.  In the summer I ported VMMaker.oscog to Pharo 6.  Now as feenk try 
> and build a VMMaker.oscog image on Pharo 7, the system is broken, in part 
> because of depreciations and in part because useful methods (isOptimisedBlock 
> (isOptimizedBlock?) in the Opal compiler) have been removed.
> 
> Just because a method is not in the image does not imply it is not in use.  
> It simply means that it is not in use in the base image.  As the system gets 
> modularised this issue will only increase.  There are lots of collection 
> methods that exist as a library that are not used in the base image and 
> removing them would clearly damage the library for users.  This is the case 
> for lots of so-called system code.  There are users out there, like those of 
> us in the vm team, who rely on such system code, and it is extremely 
> unsettling and frustrating to have that system code change all the time.  If 
> Pharo is to be a useful platform to the vm team it has to be more stable.



--- End Message ---