Pharo-dev

By thread

pharo-dev@lists.pharo.org

2 participants
144614 messages

contribution workflow

by Ben Coman

I'm not sure how closely my contribution workflow matches the standard advertised, so just wanted to share it for feedback. I may remember wrongly, but my understanding of the advertised process was forking the "pharo-project/pharo" repo, then cloning from my fork. However I found it awkward to keep the "master" branch of my fork synchronised with upstream. What I ended up finding easiest is *always* cloning "pharo-project/pharo" then adding my "bencoman/pharo" repo as a remote. Iceberg then makes it simple to push just my working branches to my fork from where I can issue a PR. I never need to trouble synchronising the master branch in my fork. How does that compare to your contribution workflow? cheers -ben

Jan. 21, 2019

[Pharo 8.0] Build #16: FAILURE

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

There is a new Pharo build available! The status of the build #16 was: FAILURE. Could not extract further issue information from commit message: Merge branch 'Pharo7.0' into Pharo8.0 # Conflicts: # bootstrap/scripts/envversion.sh # bootstrap/scripts/transform_32_into_64.sh Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 21, 2019

[Pharo 7.0] Build #133: 22903-backport-to-P70fixes-on-bootstrap-scripts

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

There is a new Pharo build available! The status of the build #133 was: FAILURE. The Pull Request #2285 was integrated: "22903-backport-to-P70fixes-on-bootstrap-scripts" Pull request url: https://github.com/pharo-project/pharo/pull/2285 Issue Url: https://pharo.fogbugz.com/f/cases/22903 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 21, 2019

[Pharo 8.0] Build #15: Added tests about Context>>home and Context>>activeHome

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

There is a new Pharo build available! The status of the build #15 was: FAILURE. The Pull Request #2278 was integrated: "Added tests about Context>>home and Context>>activeHome" Pull request url: https://github.com/pharo-project/pharo/pull/2278 Issue Url: https://pharo.fogbugz.com/f/cases/2277 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 21, 2019

[Pharo 7.0] Build #132: 22887-TonelWritercreateDefaultOrganizationFrom-can-return-string

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

There is a new Pharo build available! The status of the build #132 was: FAILURE. The Pull Request #2267 was integrated: "22887-TonelWritercreateDefaultOrganizationFrom-can-return-string" Pull request url: https://github.com/pharo-project/pharo/pull/2267 Issue Url: https://pharo.fogbugz.com/f/cases/22887 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 21, 2019

[Pharo 8.0] Build #14: Context>>methodReturnContext now uses Context>>home instead of repliâ¦

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

There is a new Pharo build available! The status of the build #14 was: FAILURE. The Pull Request #2276 was integrated: " Context>>methodReturnContext now uses Context>>home instead of repliâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/2276 Issue Url: https://pharo.fogbugz.com/f/cases/2270 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 21, 2019

Esteban's ChangeLog week of 14 January 2019

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 14 January 2019 to 20 January 2019. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=14/1/2019&to=20/1/2019 ChangeLog ========= 14 January 2019: ---------------- * I just promoted a new VM as stable for Pharo 7.0. It is "201901051900-7a3c6b6" which is not the latest-latest (which is from 10/01), but it seems very likely to be stable enough :) cheers! Esteban

Jan. 21, 2019

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

by Eliot Miranda

Hi Marcus, On Fri, Jan 18, 2019 at 5:42 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 18 Jan 2019, at 14:26, ducasse <stepharo(a)netcourrier.com> wrote: > > > > 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. > > 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) > > > 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. > 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. > I find Bytesurgeon functionality, specifically a bytecode dis/assembler very useful, but wouldn't use it for the back end of the bytecode compiler. It adds overhead that has no benefit. But I use my version, MethodMassage, for lots of things: - transporting compiled methods from one dialect to another, e.g. to do in-image JIT compilation omg a method from Pharo in Squeak. - generating JIT test cases - generating methods that can't be generated from Smalltalk source, e.g. an accessor for a JavaScript implementation above Smalltalk where inst var 0 is the prototype slot and nil is unbound, and so in a loop one wants to fetch the Nth inst var from a temporary initialized to self, and ion the value is non-nil return it, otherwise setting the temporary to the prototype slot, hence walking up the prototype chain until an initialized inst var is found. I based mine around the messages that InstructionStream sends to the client in the interpretFooInstructionFor: methods; a client that catches doesNotUnderstand: then forms the basis of the disassembler. Simple and light-weight. Marcus _,,,^..^,,,_ best, Eliot

Jan. 21, 2019

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

by Eliot Miranda

Hi Marcus, On Fri, Jan 18, 2019 at 5:15 AM Marcus Denker via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > > On 11 Jan 2019, at 20:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Thomas, > > > > forgive me, my first response was too terse. Having thought about it > in the shower it becomes clear :-) > > > >> On Jan 11, 2019, at 6:49 AM, Thomas Dupriez < > tdupriez(a)ens-paris-saclay.fr> wrote: > >> > >> Hi, > >> > >> Yes, my question was just of the form: "Hey there's this method in > DebugSession. What is it doing? What's the intention behind it? Does > someone know?". There was no hidden agenda behind it. > >> > >> @Eliot > >> > >> After taking another look at this method, there's something I don't > understand: > >> > >> activePC: aContext > >> ^ (self isLatestContext: aContext) > >> ifTrue: [ interruptedContext pc ] > >> ifFalse: [ self previousPC: aContext ] > >> > >> isLatestContext: checks whether its argument is the suspended context > (the context at the top of the stack of the interrupted process). And if > that's true, activePC: returns the pc of **interruptedContext**, not of the > suspended context. These two contexts are different when the debugger opens > on an exception, so this method is potentially returning a pc for another > context than its argument... > >> > >> Another question I have to improve the comment for this method is: > what's the high-level meaning of this concept of "activePC". You gave the > formal definition, but what's the point of defining this so to speak? What > makes this concept interesting enough to warrant defining it and giving it > a name? > > > > There are two âmodesâ where a pc us mapped to a source range. One is > when stepping a context in the debugger (the context is on top and is > actively executing bytecodes). Here the debugger stops immediately before > a send or assignment or return, so that for sends we can do into or over, > or for assignments or returns check stack top to see what will be assigned > or returned. In this mode we want the pc of the send, assign or return to > map to the source range for the send, or the expression being assigned or > returned. Since this is the âcommon caseâ, and since this is the only > choice that makes sense for assignments ta and returns, the bytecode > compiler constructs itâs pc to source range map in terms of the pc of the > first byte if the send, assign or return bytecode. > > > > The second âmodeâ is when selecting a context below the top context. > The pc for any context below the top context will be the return pc for a > send, because the send has already happened. The compiler could choose to > map this pc to the send, but it would not match what works for the common > case. Another choice would appear be to have two map entries, one for the > send and one for the return pc, both mapping to the source range. But this > wouldnât work because the result of a send might be assigned or returned > and so there is a potential conflict. I stead the reasonable solution is > to select the previous pc for contexts below the top of context, which will > be the pc for the start of the send bytecode. > > > > > I checked with Thomas > > -> for source mapping, we use the API of the method map. The map does the > âget the mapping for the instruction beforeâ, it just needs to be told that > we ask the range for an active context: > > #rangeForPC:contextIsActiveContext: > > it is called > > ^aContext debuggerMap > rangeForPC: aContext pc > contextIsActiveContext: (self isLatestContext: aContext) ] > > So the logic was move from the debugger to the Map. (I think this is even > your design?), and thus the logic inside the debugger is not needed > anymore. > "Design" is giving my code a little too much respect. I was desperately trying to get something to work to be able to deploy Cog with the new closure model. I happily admit that DebuggerMethodMap in Squeak is ugly code. It had to be extended recently to handle full blocks. But it would be great to rewrite it. I dream of a harmonisation of Squeak/Pharo/Cuis execution classes such that we have the same Context, CompiledCode, CompiledBlock, CompiledMethod, debuggerMap and BytecodeEncoder (which is effectively the back end of the compiler that generates bytecode, and the interface to the debugger when bytecode is analyses or executed in the debugger), which would make my life easier maintaining the VM and execution classes, especially as we introduce Sista. I think Opal as a separate compiler is great; the work you've done with mustBeBoleanMagic is superb. At the same time the Squeak compiler is fine for its job and I still find it easier to understand than Opal (probably because I'm not spending enough time with it). One major reason for the harmonization is bug fixes. Right now I use SistaV1 and 64-bits as my default work environment, in a 64-bit Squeak image that was compiled with V3PlusClosures, so that half the code base (the base image) is the old bytecode set, but all of VMMaker is the new bytecode set & full blocks. So far in the past few months I've fixed a few issues with pc mapping, debugging in the different bytecode sets, searching for literals with full blocks, fixing Slang for full blocks, etc. And I'd like these bug fixes to make it into Pharo too. If this speaks to you Marcus, maybe we can try and figure out a path that doesn't ruffle too many feathers. -> For the question why the AST node of the Block has no simple method to > check if it is an âisOptimizedâ block (e.g. in an ifTrue:): Yes, that might > be nice. The reason why is is not there is that the compiler internally > using OCOptimizedBlockScope and a check on the AST level was never needed. > I would have added it as soon as it would be needed (quite easy to do). > OK. isOptimized is something I use a lot when analyzing parse trees in looking at the relationship between bytecode and hit code. For example it is key to work I;'m doing right now on register allocation for Sista. On the AST level there is already a check, though, if a *send* is > optimized, which is used for code generation (#isInlined). > The Squeak versions here are MessageNode>>isOptimized, isOptimizedLoop & isOptimizedWhileLoop The question why we did not add more compatibility layers to the old AST is > that is is quite different.. so even with some methods here and there 99% > of clients need changes, so I did not even investigate it too much. With > the idea that if we end up in a situation where we need just a method, we > can just add it as needed. > Reasonable. I simply have to maintain compatibility for the two parse trees. > In general, I have no srtong feelings about the details of the > implementation of Opal. Itâs just what was possible, with the resources and > the understanding that I had at the point it was done. There are for sure > even mistakes. I always make mistakes. > I can join you in all of these for the Squeak compiler. It was not possible to have someone to pair with when modifying the Squeak compiler to conform to my closure design; I was in a tiny startup and had to do all execution technology work. And I always make mistakes too :-) > In addition, it is based on a prior compiler which was done for a > different closure model whose Design-choices influenced it too much I > think, sometimes good, sometimes not. > > But I like the âhigh levelâ: using a shared AST between the compiler and > the tools *and* having a mapping BC -> AST -> Text. > Yes, this is great. > 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]. > +10 > Marcus _,,,^..^,,,_ best, Eliot

Jan. 21, 2019

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

by Eliot Miranda

Hi Guille, > On Jan 18, 2019, at 6:04 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >> On Fri, Jan 18, 2019 at 2:46 PM Ben Coman <btc(a)openinworld.com> wrote: >> >>> On Fri, 18 Jan 2019 at 21:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> > On 18 Jan 2019, at 14:23, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> > >>> > >>> > 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? > > None :D > > That's the funny thing, they are not encoded. > > Actually, you should see Strings as collections of Characters, and Characters defined in terms of their abstract code points. > ByteStrings are an optimized (just more compact) version that stores codepoints that fit in a byte. And Spur supports 16-bit strings too, which would be versions that store code points that fit in doublebytes. >> cheers -ben >> >>> Characters are represented with their corresponding unicode codepoint. >>> > If all characters in a string have codepoints < 256 then they are just stored in a bytestring. Otherwise they are WideStrings. >>> > >>> > I think assuming a single representation for strings, and then encode when interacting with external apps/APIs is MUCH simpler. >>> >>> Absolutely ! >>> >>> (and yes I know that for outgoing FFI calls that might mean a UTF-8 encoding step, so be it). > > > -- > > 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

Jan. 19, 2019

Jump to page: