- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Ben Coman

On 14 November 2017 at 23:55, Thomas Dupriez < thomas.dupriez(a)ens-paris-saclay.fr> wrote: > While working on writing a test, I discovered that just using stepThrough > instead of stepOver may not be the definitive solution. > > # Example1: When using the `value` message directly (instead of calling a > method that does that as in my previous example), the RunToHere moves the > debugSession to the `value` message and not the inside of the block. > > `meth2 > self halt. > [ > 1+1. > 2+2."< cursor before the RunToHere" > ] ">"value"<result of the RunToHere". > 3+3. > "Two stepInto are required after the RunToHere to reach the cursor > (the `+2` message)"` > > # Example2: Going back to using a dedicated method for evaluating the > block, but increasing the block's size. The RunToHere moves the > debugSession to the first message of the block instead of the pointed one. > > `meth3 > self halt. > MyClass new evalBlock: > [ > 1">"+1"< result of the RunToHere". > 2+2."< cursor before the RunToHere" > ]. > 3+3. > "One stepInto is required after the RunToHere to reach the cursor (the > `+2` message)"` > > cheers -thomas > In both cases, what happens with an additional step-Through? cheers -ben > > Le 13/11/2017 Ã 17:23, Thomas Dupriez a Ã©crit : > > > > Le 13/11/2017 Ã 15:56, Ben Coman a Ã©crit : > > > > On Mon, Nov 13, 2017 at 9:32 PM, Thomas Dupriez <thomas.dupriez@ens-paris- > saclay.fr> wrote: > >> >> >> Le 13/11/2017 Ã 14:08, Ben Coman a Ã©crit : >> >> >> >> On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez < >> thomas.dupriez(a)ens-paris-saclay.fr> wrote: >> >>> I dug a bit in this issue. Here are the results: >>> >>> >>> # Problem raised by Stephanne >>> Code like the following is open in the debugger: >>> >>> `myMethod >>> 1+1. <PROGRAMCOUNTER> >>> MyClass new myEvalBlock: [ >>> 2+2. <CURSOR> >>> ]. >>> 3+3.` >>> >>> The program counter is on the 1+1, the cursor is at the end of the 2+2 >>> line. >>> Right-click, "Run to here". >>> -> the program counter moves to the 3+3, and does not stop at the 2+2 >>> (where the cursor is). Even though the 2+2 does get evaluated (the >>> myEvalBlock method evaluates the blocks it receives). >>> If there was no code after the block, the debugger would jump back to >>> the caller of myMethod. >>> >>> # Why this happens >>> The implementation of RunToHere (source code below) is basically to >>> stepOver until the context is different or the source code position of the >>> program counter is higher or equal to the source code position of the >>> cursor/selection. >>> >>> Since the debugger uses stepOver, it executes myEvalBlock without >>> stopping, reaches the 3+3 and see it has gone further than the source code >>> position of the cursorm so it stops. >>> >>> Source code of DebugSession>>#runToSelection:inContext: >>> >>> `runToSelection: selectionInterval inContext: aContext >>> "Attempt to step over instructions in selectedContext until the >>> execution reaches the selected instruction. This happens when the >>> program counter passes the begining of selectionInterval. >>> >>> A not nill and valid interval is expected." >>> >>> (self pcRangeForContext: aContext) first >= selectionInterval >>> first >>> ifTrue: [ ^self ]. >>> self stepOver: aContext. >>> [ aContext == self interruptedContext and: [ (self >>> pcRangeForContext: aContext) first < selectionInterval first ] ] >>> whileTrue: [ self stepOver: aContext ]` >>> >>> # Observations and thoughts >>> - Replacing the stepOver with a stepInto -> This made the RunToHere >>> stops when resolving the 'new' message (because the context changes). >>> >> >> Thanks for looking into this Thomas. >> What happens if you use stepThrough rather than stepInto? >> >> cheers -ben >> >> >> Using `stepThrough: aContext` instead of `stepInto: aContext`, the >> RunToHere in the block stops at the intended place: the 2+2. >> Printing the sequence of `self pcRangeForContext: aContext` yields the >> following. It doesn't show precisely the stop in the block, and instead >> shows an interval encompassing the whole block. That's what I was using to >> see where the execution was going during the RunToHere loop so I guess >> that's not a precise enough indicator for this situation... >> (21 to: 22)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60) >> >> I also tried the case where the block does not get evaluated (changing >> myEvalBlock so that it does nothing). In this situation, the RunToHere with >> a stepThrough ends up at the intended place, the 3+3. >> >> So... just use stepThrough for the RunToHere I guess? >> > > Seems like expected behaviour. > Could you create an Issue/Pull Request to provide some concrete code to > review? > > Now the trick will be if you can devise some tests to go with this. > For examples perhaps look at senders of newDebugSessionNamed:startedAt: > including SpecDebugger>>testBasic. > > cheers -ben > > > > I opened an issue on FogBugz: https://pharo.fogbugz.com/f/cases/20687/ > > Attached are the file out of the test code (MyClass.st) and the fixed > runToSelection:inContext: (DebugSession-runToSelectioninContext). > I'll make a pull request tomorrow. > > For the test, I'm thinking about something like the following, that checks > the source code position of the pc after the runToSelection. (It's not > working yet) > Now that I think of it, the source code position of the pc will maybe be > the whole block (as experienced earlier) so this approach may end up not > working. > I'll come back to that tomorrow. > > Draft for a test: > `testRunToSelectionInContext > |context_ process_ session_| > "The variable names have an underscore to distinguish them from those > declared in the setUp method of this TestCase (DebuggerModelTest), which > are not suited for this test (because not making a debug session out of > suitable code)" > context_ := [1+1. > self evalBlock:[2+2]. > 3+3. > ] asContext. > process_ := Process > forContext: context_ > priority: Processor userInterruptPriority. > > session_:= process_ newDebugSessionNamed: 'test session' startedAt: > context_. > session_ runToSelection: (Interval from: 28 to: 27) inContext: > context_. > self assert: ((session_ pcRangeForContext: context_) first == 3)` > > cheers - Thomas > > >> Thomas >> >> >> >> >> >>> - Replacing the stepOver with stepInto and removing the equal condition >>> on contexts -> The RunToHere goes to the 3+3. Looking at the source code >>> position of the program counter, it doesn't enter the block and seems to >>> resolve it in a single step. I don't really get why that is, considering >>> using the stepInto button of the debugger does enter the block. Here is the >>> series of source code positions of the program counter during the >>> RunToHere: (21 to: 22)(34 to: 36)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: >>> 60)(65 to: 66). >>> However, removing the equal condition on contexts means that if the >>> method call returns before reaching the cursor, it won't stop! >>> >>> - An idea could be to have the RunToHere place a metalink on the >>> selected node and let the execution run until it hits the metalink, which >>> then updates the debugger. Potential problems are that it implies >>> installing a metalink on a method that is already on the stack, which may >>> not be that easy to do properly (in particular, it affects the program >>> counter since it changes the bytecode), and there is the potential case >>> where the metalink is never reached (for example imagine the myEvalBlock: >>> method of my example is just storing the block and not evaluating it). >>> >>> >>> Cheers, >>> Thomas >>> >>> >>> >>> Le 09/11/2017 Ã 22:06, Stephane Ducasse a Ã©crit : >>> >>>> Agreed. Thomas? It would be a good bone to ... (Un bon os a ronger) . >>>> >>>> Stef >>>> >>>> On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> The basic tools, such as debugger, are expected to work. If something >>>>> does not work, itâs a bug. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On Nov 8, 2017, at 11:59 PM, Tim Mackinnon <tim(a)testit.works> >>>>>> <tim(a)testit.works> wrote: >>>>>> >>>>>> I think it's broken in Pharo 6 too, as I often find it unreliable. >>>>>> >>>>>> It's hard to know what should work anymore - we really need a >>>>>> stabilisation release to let the dust settle. >>>>>> >>>>>> I'm always a bit reticent to report things as I'm not sure what you >>>>>> expect to work. >>>>>> >>>>>> Tim >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On 8 Nov 2017, at 20:40, Stephane Ducasse <stepharo.self(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> I have the following method and I have my cursor -MY CURSOR HERE- >>>>>>> I select the menu run to here and .... I exit the method. >>>>>>> :( >>>>>>> >>>>>>> Is run to here working in Pharo 70? >>>>>>> I start to get worry about the number of bugs I get when using >>>>>>> Pharo70. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> fileOut >>>>>>> "File out the receiver, to a file whose name is a function of the >>>>>>> change-set name and a unique numeric tag." >>>>>>> >>>>>>> | nameToUse | >>>>>>> self halt. >>>>>>> self class promptForDefaultChangeSetDirectoryIfNecessary. >>>>>>> nameToUse := (self defaultChangeSetDirectory / self name , 'cs') >>>>>>> nextVersion basename. >>>>>>> UIManager default >>>>>>> showWaitCursorWhile: >>>>>>> [ >>>>>>> | internalStream | >>>>>>> internalStream := (String new: 10000) writeStream. >>>>>>> >>>>>>> -MY CURSOR HERE- >>>>>>> >>>>>>> internalStream >>>>>>> header; >>>>>>> timeStamp. >>>>>>> self fileOutPreambleOn: internalStream. >>>>>>> self fileOutOn: internalStream. >>>>>>> self fileOutPostscriptOn: internalStream. >>>>>>> CodeExporter >>>>>>> writeSourceCodeFrom: internalStream >>>>>>> baseName: (nameToUse copyFrom: 1 to: nameToUse size - 3) >>>>>>> isSt: false ] >>>>>>> >>>>>>> >>>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "Value is always contextual." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >> >> > > >

Nov. 15, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Thomas Dupriez

While working on writing a test, I discovered that just using stepThrough instead of stepOver may not be the definitive solution. # Example1: When using the `value` message directly (instead of calling a method that does that as in my previous example), the RunToHere moves the debugSession to the `value` message and not the inside of the block. `meth2 Â Â Â self halt. Â Â Â [ Â Â Â Â Â Â 1+1. Â Â Â Â Â Â 2+2."< cursor before the RunToHere" Â Â Â ] ">"value"<result of the RunToHere". Â Â Â 3+3. Â Â Â "Two stepInto are required after the RunToHere to reach the cursor (the `+2` message)"` # Example2: Going back to using a dedicated method for evaluating the block, but increasing the block's size. The RunToHere moves the debugSession to the first message of the block instead of the pointed one. `meth3 Â Â Â self halt. Â Â Â MyClass new evalBlock: Â Â Â [ Â Â Â Â Â Â 1">"+1"< result of the RunToHere". Â Â Â Â Â Â 2+2."< cursor before the RunToHere" Â Â Â ]. Â Â Â 3+3. Â Â Â "One stepInto is required after the RunToHere to reach the cursor (the `+2` message)"` cheers -thomas Le 13/11/2017 Ã 17:23, Thomas Dupriez a Ã©critÂ : > > > > Le 13/11/2017 Ã 15:56, Ben Coman a Ã©critÂ : >> >> >> On Mon, Nov 13, 2017 at 9:32 PM, Thomas Dupriez >> <thomas.dupriez(a)ens-paris-saclay.fr >> <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: >> >> >> >> Le 13/11/2017 Ã 14:08, Ben Coman a Ã©critÂ : >>> >>> >>> On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez >>> <thomas.dupriez(a)ens-paris-saclay.fr >>> <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: >>> >>> I dug a bit in this issue. Here are the results: >>> >>> >>> # Problem raised by Stephanne >>> Code like the following is open in the debugger: >>> >>> Â Â Â `myMethod >>> Â Â Â Â Â Â 1+1. <PROGRAMCOUNTER> >>> Â Â Â Â Â Â MyClass new myEvalBlock: [ >>> Â Â Â Â Â Â Â Â Â 2+2. <CURSOR> >>> Â Â Â Â Â Â ]. >>> Â Â Â Â Â Â 3+3.` >>> >>> The program counter is on the 1+1, the cursor is at the end >>> of the 2+2 line. >>> Right-click, "Run to here". >>> -> the program counter moves to the 3+3, and does not stop >>> at the 2+2 (where the cursor is). Even though the 2+2 does >>> get evaluated (the myEvalBlock method evaluates the blocks >>> it receives). >>> If there was no code after the block, the debugger would >>> jump back to the caller of myMethod. >>> >>> # Why this happens >>> The implementation of RunToHere (source code below) is >>> basically to stepOver until the context is different or the >>> source code position of the program counter is higher or >>> equal to the source code position of the cursor/selection. >>> >>> Since the debugger uses stepOver, it executes myEvalBlock >>> without stopping, reaches the 3+3 and see it has gone >>> further than the source code position of the cursorm so it >>> stops. >>> >>> Source code of DebugSession>>#runToSelection:inContext: >>> >>> Â Â Â `runToSelection: selectionInterval inContext: aContext >>> Â Â Â Â Â Â "Attempt to step over instructions in >>> selectedContext until the >>> Â Â Â Â Â Â execution reaches the selected instruction. This >>> happens when the >>> Â Â Â Â Â Â program counter passes the begining of >>> selectionInterval. >>> >>> Â Â Â Â Â Â A not nill and valid interval is expected." >>> >>> Â Â Â Â Â Â (self pcRangeForContext: aContext) first >= >>> selectionInterval first >>> Â Â Â Â Â Â Â Â Â ifTrue: [ ^self ]. >>> Â Â Â Â Â Â self stepOver: aContext. >>> Â Â Â Â Â Â [ aContext == self interruptedContext and: [ (self >>> pcRangeForContext: aContext) first < selectionInterval first ] ] >>> Â Â Â Â Â Â Â Â Â whileTrue: [ self stepOver: aContext ]` >>> >>> # Observations and thoughts >>> - Replacing the stepOver with a stepInto -> This made the >>> RunToHere stops when resolving the 'new' message (because >>> the context changes). >>> >>> >>> Thanks for looking into this Thomas. >>> What happens if you use stepThrough rather than stepInto? >>> >>> cheers -ben >> >> Using `stepThrough: aContext` instead of `stepInto: aContext`, >> the RunToHere in the block stops at the intended place: the 2+2. >> Printing the sequence of `self pcRangeForContext: aContext` >> yields the following. It doesn't show precisely the stop in the >> block, and instead shows an interval encompassing the whole >> block. That's what I was using to see where the execution was >> going during the RunToHere loop so I guess that's not a precise >> enough indicator for this situation... >> (21 to: 22)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60) >> >> I also tried the case where the block does not get evaluated >> (changing myEvalBlock so that it does nothing). In this >> situation, the RunToHere with a stepThrough ends up at the >> intended place, the 3+3. >> >> So... just use stepThrough for the RunToHere I guess? >> >> >> Seems like expected behaviour. >> Could you create an Issue/Pull Request to provide some concrete code >> to review? >> >> Now the trick will be if you can devise some tests to go with this. >> For examples perhaps look at senders of newDebugSessionNamed:startedAt: >> including SpecDebugger>>testBasic. >> >> cheers -ben >> > I opened an issue on FogBugz: https://pharo.fogbugz.com/f/cases/20687/ > > Attached are the file out of the test code (MyClass.st) and the fixed > runToSelection:inContext: (DebugSession-runToSelectioninContext). > I'll make a pull request tomorrow. > > For the test, I'm thinking about something like the following, that > checks the source code position of the pc after the runToSelection. > (It's not working yet) > Now that I think of it, the source code position of the pc will maybe > be the whole block (as experienced earlier) so this approach may end > up not working. > I'll come back to that tomorrow. > > Draft for a test: > Â Â Â `testRunToSelectionInContext > Â Â Â |context_ process_ session_| > Â Â Â "The variable names have an underscore to distinguish them from > those declared in the setUp method of this TestCase > (DebuggerModelTest), which are not suited for this test (because not > making a debug session out of suitable code)" > Â Â Â context_ := [1+1. > Â Â Â Â Â Â self evalBlock:[2+2]. > Â Â Â Â Â Â 3+3. > Â Â Â ] asContext. > Â Â Â process_ := Process > Â Â Â Â Â Â forContext: context_ > Â Â Â Â Â Â priority: Processor userInterruptPriority. > > Â Â Â session_:= process_ newDebugSessionNamed: 'test session' > startedAt: context_. > Â Â Â session_ runToSelection: (Interval from: 28 to: 27) inContext: > context_. > Â Â Â self assert: ((session_ pcRangeForContext: context_) first == 3)` > > cheers - Thomas > >> >> Thomas >> >> >>> >>> - Replacing the stepOver with stepInto and removing the >>> equal condition on contexts -> The RunToHere goes to the >>> 3+3. Looking at the source code position of the program >>> counter, it doesn't enter the block and seems to resolve it >>> in a single step. I don't really get why that is, >>> considering using the stepInto button of the debugger does >>> enter the block. Here is the series of source code positions >>> of the program counter during the RunToHere: (21 to: 22)(34 >>> to: 36)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60)(65 to: 66). >>> However, removing the equal condition on contexts means that >>> if the method call returns before reaching the cursor, it >>> won't stop! >>> >>> - An idea could be to have the RunToHere place a metalink on >>> the selected node and let the execution run until it hits >>> the metalink, which then updates the debugger. Potential >>> problems are that it implies installing a metalink on a >>> method that is already on the stack, which may not be that >>> easy to do properly (in particular, it affects the program >>> counter since it changes the bytecode), and there is the >>> potential case where the metalink is never reached (for >>> example imagine the myEvalBlock: method of my example is >>> just storing the block and not evaluating it). >>> >>> >>> Cheers, >>> Thomas >>> >>> >>> >>> Le 09/11/2017 Ã 22:06, Stephane Ducasse a Ã©critÂ : >>> >>> Agreed. Thomas? It would be a good bone to ... (Un bon >>> os a ronger) . >>> >>> Stef >>> >>> On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba >>> <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >>> >>> Hi, >>> >>> The basic tools, such as debugger, are expected to >>> work. If something does not work, itâs a bug. >>> >>> Cheers, >>> Doru >>> >>> >>> On Nov 8, 2017, at 11:59 PM, Tim Mackinnon >>> <tim(a)testit.works> <mailto:tim@testit.works> wrote: >>> >>> I think it's broken in Pharo 6 too, as I often >>> find it unreliable. >>> >>> It's hard to know what should work anymore - we >>> really need a stabilisation release to let the >>> dust settle. >>> >>> I'm always a bit reticent to report things as >>> I'm not sure what you expect to work. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>> On 8 Nov 2017, at 20:40, Stephane Ducasse >>> <stepharo.self(a)gmail.com >>> <mailto:stepharo.self@gmail.com>> wrote: >>> >>> Hi >>> >>> I have the following method and I have my >>> cursor -MY CURSOR HERE- >>> I select the menu run to here and .... I >>> exit the method. >>> :( >>> >>> Is run to here working in Pharo 70? >>> I start to get worry about the number of >>> bugs I get when using Pharo70. >>> >>> Stef >>> >>> >>> fileOut >>> "File out the receiver, to a file whose name >>> is a function of the >>> change-set name and a unique numeric tag." >>> >>> | nameToUse | >>> self halt. >>> self class >>> promptForDefaultChangeSetDirectoryIfNecessary. >>> nameToUse := (self defaultChangeSetDirectory >>> / self name , 'cs') >>> nextVersion basename. >>> UIManager default >>> showWaitCursorWhile: >>> [ >>> | internalStream | >>> internalStream := (String new: 10000) >>> writeStream. >>> >>> -MY CURSOR HERE- >>> >>> internalStream >>> header; >>> timeStamp. >>> self fileOutPreambleOn: internalStream. >>> self fileOutOn: internalStream. >>> self fileOutPostscriptOn: internalStream. >>> CodeExporter >>> writeSourceCodeFrom: internalStream >>> baseName: (nameToUse copyFrom: 1 to: >>> nameToUse size - 3) >>> isSt: false ] >>> >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com> >>> www.feenk.com <http://www.feenk.com> >>> >>> "Value is always contextual." >>> >>> >>> >>> >>> >>> >>> >>> >> >> >

Nov. 14, 2017

Re: [Pharo-dev] Thank you

by Sven Van Caekenberghe

> On 14 Nov 2017, at 09:20, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > yesterday I have seen this interesting talk: > > https://www.youtube.com/watch?v=VS6IpvTWwkQ&app=desktop > > ...where pictures like this were presented: > > https://image.slidesharecdn.com/iscodereviewthesolution-confraria-141101115… > > I would like to thank to StÃ©phane Ducasse, Esteban Lorezano, Marcus Denker, Tudor Girba and many others for their ungrateful hard work on collecting and managing funds and human resources so we are closer to the first picture. > > Afterwards I would like to thank to all consortium and association members as well as all the contributors for their support of our common dream - better Pharo. > > THANK YOU! +1e6 > Best regards > -- Pavel -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Nov. 14, 2017

Re: [Pharo-dev] Thank you

by Ben Coman

Thanks Pavel. Really liked it. Apart from the core integrators, I think our community is well placed with a spread of maintainers across the different corners of the system. I thought the follow-on vid is also quite applicable, particularly the animal shelter analogy... Volunteering for != Working at nonprofit As a volunteer myself, its good to have the benefit of people paid to "bring it all together". * https://www.youtube.com/watch?v=bjAinwgvQqc cheers -ben On 14 November 2017 at 16:20, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > yesterday I have seen this interesting talk: > > https://www.youtube.com/watch?v=VS6IpvTWwkQ&app=desktop > > ...where pictures like this were presented: > > https://image.slidesharecdn.com/iscodereviewthesolution- > confraria-141101115613-conversion-gate01/95/is-code- > review-the-solution-20-638.jpg?cb=1414843392 > > I would like to thank to StÃ©phane Ducasse, Esteban Lorezano, Marcus > Denker, Tudor Girba and many others for their ungrateful hard work on > collecting and managing funds and human resources so we are closer to the > first picture. > > Afterwards I would like to thank to all consortium and association members > as well as all the contributors for their support of our common dream - > better Pharo. > > THANK YOU! > > Best regards > -- Pavel > > >

Nov. 14, 2017

Re: [Pharo-dev] UFFI/Sista/Scorch

by ClÃ©ment Bera

Hi Ben, This is the work that Ronie did. You have lower level bytecodes in the SistaV1 bytecode set which can be used for parameters marshalling. Ronie has a prototype where the marshalling of FFI calls is generated image-side once and reused for all calls. For now, if Scorch does not recognise the primitive (and it does not recognise FFI calls), the send is just marked as non inlineable. Hence this works but is not really optimised. Cheers On Tue, Nov 14, 2017 at 11:48 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 13 Nov 2017, at 22:30, Ben Coman <btc(a)openinworld.com> wrote: > > > Just curious regarding Slide 16 [1] which indicates UFFI sequence is... > 1. Generate bytecodes for marshalling > 2. Re-send method invocation > > Do the bytecodes get cached so that (1.) is only down once? > > What impact is Sista/Scorch expected to have on UFFI? > Considering for example that the commonly used method... > ffiCall: fnSpec > ^ (self ffiCalloutIn: thisContext sender) > convention: self ffiCallingConvention; > function: fnSpec module: self ffiLibraryName > ...has several message sends. > > [1] https://www.slideshare.net/esug/unifiedffi-a-common- > language-for-the-outside-world > > > we still do not sit to solve the problem, but we have a strategy: SISTA > bytecode set contains bytecodes to invoque primitives which means possible > to do a primitive call inside a method (it does not needs to be an > independent method). This way, the optimiser can work also on methods that > ends on primitives. > As far as I know, adapting to SISTA will not be very complicated. But of > course, there will be some work needed. > > > btw, Slide 2 gave me a nice chuckle to start the day. Stabilization is a > difficult/boring task with highly visible issues which Esteban bears the > brunt of dealing with, along with accompanying pressures. I'd like to take > this random opportunity to thank Esteban for his continuing efforts, and > also previous Consortium engineers (Igor) and those supporting them. We > wouldn't be where we are today without such a focal point. > > > thanks :) > > Esteban > > > cheers -ben > > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Nov. 14, 2017

Re: [Pharo-dev] UFFI/Sista/Scorch

by Esteban Lorenzano

> On 13 Nov 2017, at 22:30, Ben Coman <btc(a)openinworld.com> wrote: > > > Just curious regarding Slide 16 [1] which indicates UFFI sequence is... > 1. Generate bytecodes for marshalling > 2. Re-send method invocation > > Do the bytecodes get cached so that (1.) is only down once? > > What impact is Sista/Scorch expected to have on UFFI? > Considering for example that the commonly used method... > ffiCall: fnSpec > ^ (self ffiCalloutIn: thisContext sender) > convention: self ffiCallingConvention; > function: fnSpec module: self ffiLibraryName > ...has several message sends. > > [1] https://www.slideshare.net/esug/unifiedffi-a-common-language-for-the-outsid… <https://www.slideshare.net/esug/unifiedffi-a-common-language-for-the-outsid…> we still do not sit to solve the problem, but we have a strategy: SISTA bytecode set contains bytecodes to invoque primitives which means possible to do a primitive call inside a method (it does not needs to be an independent method). This way, the optimiser can work also on methods that ends on primitives. As far as I know, adapting to SISTA will not be very complicated. But of course, there will be some work needed. > > btw, Slide 2 gave me a nice chuckle to start the day. Stabilization is a difficult/boring task with highly visible issues which Esteban bears the brunt of dealing with, along with accompanying pressures. I'd like to take this random opportunity to thank Esteban for his continuing efforts, and also previous Consortium engineers (Igor) and those supporting them. We wouldn't be where we are today without such a focal point. thanks :) Esteban > > cheers -ben

Nov. 14, 2017

Re: [Pharo-dev] Pharo6.1 is hangs and then crashes

by Pavel Krivanek

Thank you for reporting https://pharo.fogbugz.com/f/cases/20691/infinite-recursion-when-evaluating-… -- Pavel 2017-11-14 10:47 GMT+01:00 Yuriy Babah <babah.yuriy06(a)gmail.com>: > Hi! > I don't know haw important this is, but > > when executing: > ' 45 56' matchesRegex: '(\s+\d+){2}' > > > Pharo6.1 is hangs and then crashes > > Os Window7x64, > dump file is not creating. > >

Nov. 14, 2017

Pharo6.1 is hangs and then crashes

by Yuriy Babah

Hi! I don't know haw important this is, but when executing: ' 45 56' matchesRegex: '(\s+\d+){2}' Pharo6.1 is hangs and then crashes Os Window7x64, dump file is not creating.

Nov. 14, 2017

[Pharo 7.0-dev] Build #293: 20686-disabling-of-FreeType-fonts-should-set-bitmap-Source-Pro-fonts

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

There is a new Pharo build available! The status of the build #293 was: SUCCESS. The Pull Request #476 was integrated: "20686-disabling-of-FreeType-fonts-should-set-bitmap-Source-Pro-fonts" Pull request url: https://github.com/pharo-project/pharo/pull/476 Issue Url: https://pharo.fogbugz.com/f/cases/20686 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 14, 2017

[Pharo 7.0-dev] Build #292: 20166-wrong-cliprect-on-transformed-athens-canvas

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

There is a new Pharo build available! The status of the build #292 was: SUCCESS. The Pull Request #477 was integrated: "20166-wrong-cliprect-on-transformed-athens-canvas" Pull request url: https://github.com/pharo-project/pharo/pull/477 Issue Url: https://pharo.fogbugz.com/f/cases/20166 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 14, 2017