August 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] eventual crashes pharo vm

by henry

Hi Eliot, I have disabled that test for the time being. It will require some deeper thought regarding immediate selectors, I think, and I am deep into another area right now. As mustBeBoolean is from inside the VM, a different approach may be the right solution. A part of me thinks autocoercion between msg sending (async) and msg calling (sync) is what is needed, but I want continuation-based VatSemaphores to prevent a liveness lock on the event loop to support. Again, I have not thought deep enough in this area. Thanks again for your help, - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 16, 2017 10:32 PM > UTC Time: August 17, 2017 2:32 AM > From: eliot.miranda(a)gmail.com > To: henry <henry(a)callistohouse.club> > Marcus Denker <marcus.denker(a)inria.fr>, Pharo Development List <pharo-dev(a)lists.pharo.org>, Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > Hi Henry, > > On Wed, Aug 16, 2017 at 6:33 PM, henry <henry(a)callistohouse.club> wrote: > >> That is good news, that it is due to this code doing funniness than a VM issue. This code trying to bring asynchrony within a synchronous environment brings new issues. >> >> What do you think that right solution is to the issue of a call expected to be immediate, change out to go eventual until the arguments resolve? > > I'm not informed enough to know. One could implement mustBeBoolean in the ERef hierarchy and resolve the promise before going on. One could rely on the mustBeBooleanMagic: if one wanted a fully lazy system. I don't know the trade-offs between the two. I do know that while the miustBeBooleanMagic: solution is cool and fun it is extremely slow. So if performance is an issue use the first approach. > >> How can it be structured correctly on the stack without generic functions? I think with the double dispatch of an eventual but I have not spend much time in this particular area. > > Yes that's an issue There is already a problem with #==. It needs to be symmetric for correctness. > >> Preventing the vm from crashing would be a good interim step but even here I am not sure how to go about crafting a solution. > > Well, the issue is simply that the wrong pc is chosen for the continuation after the mustBeBoolean. I'm sure the right answer is straight-forward to obtain. > >> Thank you for investigating this. > > You're welcome. > >> - HH >> >> On Wed, Aug 16, 2017 at 20:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> Hi Henry, Hi Marcus, >>> >>> On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: >>> >>>> Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers >>>> >>>> http://www.squeaksource.com/TurquoiseTesting.html >>>> >>>> - HH >>> >>> I took a look at this and I think you've found a bug in the mustBeBooleanMagic: code. What's happening is a mustBeBoolean in Integer>>* due to evaluating >>> 10 * 42 eventual >>> in RefsTest>>testFailureArithmeticPrimitivesWithPromiseArgument >>> >>> Since 42 eventual is a NearERef the SmallInteger>>* primitive fails and does ^super * anInteger (where anInteger is the NearERef). So that evaluates Integer>>* >>> >>> Integer>>* aNumber >>> "Refer to the comment in Number * " >>> aNumber isInteger ifTrue: >>> [^ self digitMultiply: aNumber >>> neg: self negative ~~ aNumber negative]. >>> ^ aNumber adaptToInteger: self andSend: #* >>> >>> aNumber, being a NearERef, answers a PromiseERef for the isInteger send, and this provokes a mustBeBoolean for the isInteger ifTrue: [... >>> >>> After the mustBeBooleanMagic: the stack looks wrong. The activation of Integer>>*, which is about to do >>> ^ aNumber adaptToInteger: self andSend: #* >>> does not have enough items on the stack. Instead of containing >>> a NearERef (for 42) >>> 10 >>> #* >>> it contains >>> a PromiseERef (for 42 eventual isInteger) >>> >>> and the send of #adaptToInteger:andSend: ends up taking more form the stack than the VM can handle and it crashes. The bug appears to be with the use of sendNode irInstruction nextBytecodeOffsetAfterJump in Object>>mustBeBooleanMagic: since execution should resume at bytecode 55 below, but does so at bytecode 57 >>> >>> 41 <10> pushTemp: 0 >>> 42 <D0> send: isInteger >>> 43 <AC 09> jumpFalse: 54 >>> 45 <70> self >>> 46 <10> pushTemp: 0 >>> 47 <70> self >>> 48 <D1> send: negative >>> 49 <10> pushTemp: 0 >>> 50 <D1> send: negative >>> 51 <E2> send: ~~ >>> 52 <F3> send: digitMultiply:neg: >>> 53 <7C> returnTop >>> 54 <10> pushTemp: 0 >>> 55 <70> self >>> 56 <24> pushConstant: #* >>> 57 <F5> send: adaptToInteger:andSend: >>> 58 <7C> returnTop >>> >>> So the positioning of the context's pc must be before any argument marshaling for the next send, not simply the send itself. >>> >>> Put a breakpoint at the end of Object>>mustBeBooleanMagic: and add initlaPC and resumePC temporaries at the beginning and capture them via >>> initialPC := context pc. >>> at the beginning and then >>> context pc: (resumePC := sendNode irInstruction nextBytecodeOffsetAfterJump) >>> to see what I'm seeing. >>> >>> Phew. Glad it's not a VM bug :-) >>> >>> HTH >>> _,,,^..^,,,_ >>> best, Eliot > > -- > _,,,^..^,,,_ > best, Eliot

Aug. 17, 2017

Re: [Pharo-dev] eventual crashes pharo vm

by Eliot Miranda

Hi Henry, On Wed, Aug 16, 2017 at 6:33 PM, henry <henry(a)callistohouse.club> wrote: > That is good news, that it is due to this code doing funniness than a VM > issue. This code trying to bring asynchrony within a synchronous > environment brings new issues. > > What do you think that right solution is to the issue of a call > expected to be immediate, change out to go eventual until the arguments > resolve? > I'm not informed enough to know. One could implement mustBeBoolean in the ERef hierarchy and resolve the promise before going on. One could rely on the mustBeBooleanMagic: if one wanted a fully lazy system. I don't know the trade-offs between the two. I do know that while the miustBeBooleanMagic: solution is cool and fun it is extremely slow. So if performance is an issue use the first approach. > How can it be structured correctly on the stack without generic functions? > I think with the double dispatch of an eventual but I have not spend much > time in this particular area. > Yes that's an issue There is already a problem with #==. It needs to be symmetric for correctness. > Preventing the vm from crashing would be a good interim step but even here > I am not sure how to go about crafting a solution. > Well, the issue is simply that the wrong pc is chosen for the continuation after the mustBeBoolean. I'm sure the right answer is straight-forward to obtain. > Thank you for investigating this. > You're welcome. > > - HH > > > On Wed, Aug 16, 2017 at 20:46, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Hi Henry, Hi Marcus, > > On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: > >> Hi all. I was testing with this eventual_test package and it blows up the >> pharo 6.1 vm. I'd welcome pointers >> >> http://www.squeaksource.com/TurquoiseTesting.html >> >> - HH >> > > I took a look at this and I think you've found a bug in the > mustBeBooleanMagic: code. What's happening is a mustBeBoolean in > Integer>>* due to evaluating > 10 * 42 eventual > in RefsTest>>testFailureArithmeticPrimitivesWithPromiseArgument > > Since 42 eventual is a NearERef the SmallInteger>>* primitive fails and > does ^super * anInteger (where anInteger is the NearERef). So that > evaluates Integer>>* > > Integer>>* aNumber > "Refer to the comment in Number * " > aNumber isInteger ifTrue: > [^ self digitMultiply: aNumber > neg: self negative ~~ aNumber negative]. > ^ aNumber adaptToInteger: self andSend: #* > > aNumber, being a NearERef, answers a PromiseERef for the isInteger send, > and this provokes a mustBeBoolean for the isInteger ifTrue: [... > > After the mustBeBooleanMagic: the stack looks wrong. The activation of > Integer>>*, which is about to do > ^ aNumber adaptToInteger: self andSend: #* > does not have enough items on the stack. Instead of containing > a NearERef (for 42) > 10 > #* > it contains > a PromiseERef (for 42 eventual isInteger) > > and the send of #adaptToInteger:andSend: ends up taking more form the > stack than the VM can handle and it crashes. The bug appears to be with > the use of sendNode irInstruction nextBytecodeOffsetAfterJump in > Object>>mustBeBooleanMagic: since execution should resume at bytecode 55 > below, but does so at bytecode 57 > > 41 <10> pushTemp: 0 > 42 <D0> send: isInteger > 43 <AC 09> jumpFalse: 54 > 45 <70> self > 46 <10> pushTemp: 0 > 47 <70> self > 48 <D1> send: negative > 49 <10> pushTemp: 0 > 50 <D1> send: negative > 51 <E2> send: ~~ > 52 <F3> send: digitMultiply:neg: > 53 <7C> returnTop > 54 <10> pushTemp: 0 > 55 <70> self > 56 <24> pushConstant: #* > 57 <F5> send: adaptToInteger:andSend: > 58 <7C> returnTop > > So the positioning of the context's pc must be before any argument > marshaling for the next send, not simply the send itself. > > Put a breakpoint at the end of Object>>mustBeBooleanMagic: and add > initlaPC and resumePC temporaries at the beginning and capture them via > initialPC := context pc. > at the beginning and then > context pc: (resumePC := sendNode irInstruction > nextBytecodeOffsetAfterJump) > to see what I'm seeing. > > > Phew. Glad it's not a VM bug :-) > > HTH > _,,,^..^,,,_ > best, Eliot > > -- _,,,^..^,,,_ best, Eliot

Aug. 17, 2017

Re: [Pharo-dev] eventual crashes pharo vm

by henry

That is good news, that it is due to this code doing funniness than a VM issue. This code trying to bring asynchrony within a synchronous environment brings new issues. What do you think that right solution is to the issue of a call expected to be immediate, change out to go eventual until the arguments resolve? How can it be structured correctly on the stack without generic functions? I think with the double dispatch of an eventual but I have not spend much time in this particular area. Preventing the vm from crashing would be a good interim step but even here I am not sure how to go about crafting a solution. Thank you for investigating this. - HH On Wed, Aug 16, 2017 at 20:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Henry, Hi Marcus, > > On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: > >> Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers >> >> http://www.squeaksource.com/TurquoiseTesting.html >> >> - HH > > I took a look at this and I think you've found a bug in the mustBeBooleanMagic: code. What's happening is a mustBeBoolean in Integer>>* due to evaluating > 10 * 42 eventual > in RefsTest>>testFailureArithmeticPrimitivesWithPromiseArgument > > Since 42 eventual is a NearERef the SmallInteger>>* primitive fails and does ^super * anInteger (where anInteger is the NearERef). So that evaluates Integer>>* > > Integer>>* aNumber > "Refer to the comment in Number * " > aNumber isInteger ifTrue: > [^ self digitMultiply: aNumber > neg: self negative ~~ aNumber negative]. > ^ aNumber adaptToInteger: self andSend: #* > > aNumber, being a NearERef, answers a PromiseERef for the isInteger send, and this provokes a mustBeBoolean for the isInteger ifTrue: [... > > After the mustBeBooleanMagic: the stack looks wrong. The activation of Integer>>*, which is about to do > ^ aNumber adaptToInteger: self andSend: #* > does not have enough items on the stack. Instead of containing > a NearERef (for 42) > 10 > #* > it contains > a PromiseERef (for 42 eventual isInteger) > and the send of #adaptToInteger:andSend: ends up taking more form the stack than the VM can handle and it crashes. The bug appears to be with the use of sendNode irInstruction nextBytecodeOffsetAfterJump in Object>>mustBeBooleanMagic: since execution should resume at bytecode 55 below, but does so at bytecode 57 > > 41 <10> pushTemp: 0 > 42 <D0> send: isInteger > 43 <AC 09> jumpFalse: 54 > 45 <70> self > 46 <10> pushTemp: 0 > 47 <70> self > 48 <D1> send: negative > 49 <10> pushTemp: 0 > 50 <D1> send: negative > 51 <E2> send: ~~ > 52 <F3> send: digitMultiply:neg: > 53 <7C> returnTop > 54 <10> pushTemp: 0 > 55 <70> self > 56 <24> pushConstant: #* > 57 <F5> send: adaptToInteger:andSend: > 58 <7C> returnTop > > So the positioning of the context's pc must be before any argument marshaling for the next send, not simply the send itself. > > Put a breakpoint at the end of Object>>mustBeBooleanMagic: and add initlaPC and resumePC temporaries at the beginning and capture them via > initialPC := context pc. > at the beginning and then > context pc: (resumePC := sendNode irInstruction nextBytecodeOffsetAfterJump) > to see what I'm seeing. > > Phew. Glad it's not a VM bug :-) > > HTH > _,,,^..^,,,_ > best, Eliot

Aug. 17, 2017

Re: [Pharo-dev] eventual crashes pharo vm

by Eliot Miranda

Hi Henry, Hi Marcus, On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: > Hi all. I was testing with this eventual_test package and it blows up the > pharo 6.1 vm. I'd welcome pointers > > http://www.squeaksource.com/TurquoiseTesting.html > > - HH > I took a look at this and I think you've found a bug in the mustBeBooleanMagic: code. What's happening is a mustBeBoolean in Integer>>* due to evaluating 10 * 42 eventual in RefsTest>>testFailureArithmeticPrimitivesWithPromiseArgument Since 42 eventual is a NearERef the SmallInteger>>* primitive fails and does ^super * anInteger (where anInteger is the NearERef). So that evaluates Integer>>* Integer>>* aNumber "Refer to the comment in Number * " aNumber isInteger ifTrue: [^ self digitMultiply: aNumber neg: self negative ~~ aNumber negative]. ^ aNumber adaptToInteger: self andSend: #* aNumber, being a NearERef, answers a PromiseERef for the isInteger send, and this provokes a mustBeBoolean for the isInteger ifTrue: [... After the mustBeBooleanMagic: the stack looks wrong. The activation of Integer>>*, which is about to do ^ aNumber adaptToInteger: self andSend: #* does not have enough items on the stack. Instead of containing a NearERef (for 42) 10 #* it contains a PromiseERef (for 42 eventual isInteger) and the send of #adaptToInteger:andSend: ends up taking more form the stack than the VM can handle and it crashes. The bug appears to be with the use of sendNode irInstruction nextBytecodeOffsetAfterJump in Object>>mustBeBooleanMagic: since execution should resume at bytecode 55 below, but does so at bytecode 57 41 <10> pushTemp: 0 42 <D0> send: isInteger 43 <AC 09> jumpFalse: 54 45 <70> self 46 <10> pushTemp: 0 47 <70> self 48 <D1> send: negative 49 <10> pushTemp: 0 50 <D1> send: negative 51 <E2> send: ~~ 52 <F3> send: digitMultiply:neg: 53 <7C> returnTop 54 <10> pushTemp: 0 55 <70> self 56 <24> pushConstant: #* 57 <F5> send: adaptToInteger:andSend: 58 <7C> returnTop So the positioning of the context's pc must be before any argument marshaling for the next send, not simply the send itself. Put a breakpoint at the end of Object>>mustBeBooleanMagic: and add initlaPC and resumePC temporaries at the beginning and capture them via initialPC := context pc. at the beginning and then context pc: (resumePC := sendNode irInstruction nextBytecodeOffsetAfterJump) to see what I'm seeing. Phew. Glad it's not a VM bug :-) HTH _,,,^..^,,,_ best, Eliot

Aug. 17, 2017

Re: [Pharo-dev] @About posting here

by Frank-B

Eliot, I already wrote twice: This case was closed on my side. I made my points clear but it seems you haven't read the whole thread. *Only because you misquoted me at least twice*, I feel obliged to correct your false quotations: 1) > Why is free speech necessarily a national issue? I NEVER wrote anything like that! It just aint fair to fake statements that were never made! Unfortunately the suppression of free speech and even more so the self-censoring in peoples brains is in some countries, notably my home country in absence of a first amendment, far more advanced than in others - and in the US the "old system" is trying hard to achieve the same - look at all the fakes and lies around Putin bashing. But if writers here use the most primitive national cliches I find this extremely stupid and annoying - espcially for someone like me who has lived more than half of his life in several other countries. 2) You should really learn to read and quote exactly, instead of making so many false allegations, because I also clearly did *NOT* call the JS "community" idiots but very precisely the people who devloped this language and the primitive tools without wanting to learn from existing technologies like in Smalltalk. I wrote: > Why don't want these ignorant idiots who * > develop * > JavaScript and its primitive tools refuse to learn from Smalltalk? Yes, that is my opinion! /(Though gramatically not quite correct!)/ Because of many good reasons. Actually, nobody should know this better than Smalltalkers! The more I am pulled and forced into such useless discussions often bsed on faked statements the less mood I have to add parts of my projects in the future. This is partially also the case, because I often have very different technological opinions not only on documentation. And if two writers tell me here to start documenting a third person's code, I find this just a bad silly joke. Yes, I am a documenation fanatic and my very long exprience tells me that this is totally correct. Failing to document is amateurish in my view and never ever can any excuse justify this failure! I do not expect anybody to agree with me but I expect everbody to accepts other opinions including mine. This wasn't the case here. See what I wrote about Voltaire at 16. Aug. 14:23. > I hope you have productive discussions here. I must strongly doubt that this will be the case. And here is one proof why: I find it most unmasking and eye opening that *there was not a single comment to my long technical posting* of 16. Aug. 08:34. All reactions were bashing me for the opinions that I expressed and on my critics, which were mostly addressing third party subjects (or did anybody here write this supa dupa forum mailing list?). *This proofs: Far more people here are interested in enforcing a social consensus than they are in discussing technical proposals and innovations.* Would you call this a good basis for productive technical discussion? I wouln't! Regards Frank P.S. I suppose and do hope that you don't read your program code with the same low degree of precision as you quoted me! P.S.2: This was defintely my LAST response to any such off-topic postings whether fictious or true. -- View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 16, 2017

Is there some RSS parser updated around?

by Mariano Martinez Peck

Hi guys, All the RSS parsers I found are all quite outdated...does someone have an updated one? I want to parse RSS and then display it within Seaside (to render kind of company news). Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Aug. 16, 2017

Re: [Pharo-dev] @About posting here

by Eliot Miranda

Frank, On Wed, Aug 16, 2017 at 3:52 AM, Frank-B <frank.berger.software(a)web.de> wrote: > Phil, > > nice attempt to drill and silence me! My advise: They all failed! > How is Phil's list of the advantages of mailing lists from a phone user (advantages I depend on all the time) an attempt to silence you? > > If somebody can't cope with straight critics or unpopular opinions that > aint > my fault. > Phil cotradicting you is not an example of someone not coping with your opinions, unpopular or otherwise. Quite the opposite. It is an example of rational debate. Phil is introducing the benefits he sees from using mailing lists. He disagrees with you. To me it looks like you who can't cope with his disagreement. Instead of addressing his points you post an extremely subjective response. > > Frank > who never worried about being labeled and > from a country where free speech is still welcome Why is free speech necessarily a national issue? It is also an issue at smaller and larger scales. How is your free speech being impinged upon here? You haven't been blocked. Tudor gave a reasoned request for you to be more civil, which is not bad advice. I myself found your "javascript idiots" shocking, because I can think of no better way of antagonizing the JavaScript community, with which you may have to interact regularly to get help with your project, than writing the entire community off as idiotic. Maybe I misunderstood you. Anyway, I do hope that you can find discussion here more p[roductive and less antagonistic, both in your perceptions and your responses. And more importantly I hope you have productive discussions here. We all stand to benefit from each other if we can collaborate and assist, and that effort is in my experience always helped by clear and courteous communication, especially when opinions differ strongly. > -- > View this message in context: http://forum.world.st/Anybody- > using-Orca-Smalltalk-to-JavaScript-tp4960519p4961628.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > _,,,^..^,,,_ best, Eliot

Aug. 16, 2017

19609 FileReference>>base should be before last separator

by Alistair Grant

Hi All, I've just taken a look at issue 19609 FileReference>>base should be before last separator and wonder whether it is a correct interpretation of the original intentions. The original author of the issue, Michael, seems to feel that FileReferene>>base and FileReference>>basenameWithoutExtension are the same. My reading of the comments is that they perform a different function, i.e.: '/a/b/c.d.e' asFileReference base. "c" '/a/b/c.d.e' asFileReference basenameWithoutExtension. "c.d" are both the expected values, i.e.: - #base answers the name up to the first extensionDelimiter. - #basenameWithoutExtension answers the name without what is typically considered the file extension (the bit after the last extensionDelimiter). Not shown above, but: - #basename answers the entire filename, i.e. "c.d.e". Does anyone know the history of these methods? Cheers, Alistair

Aug. 16, 2017

Re: [Pharo-dev] FileSystem fix integration

by Alistair Grant

Hi Stef, On Wed, Aug 16, 2017 at 08:43:24PM +0200, Stephane Ducasse wrote: > May be you already see it but > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… > https://github.com/pharo-project/pharo/pull/137 > has a merge conflict I haven't looked at this at all. I'll try and take a look it at soon (my daughter's birthday party this weekend, so time is limited :-)). > I will integrate now > > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > https://github.com/pharo-project/pharo/pull/133 > > and after when esteban is back we will integrate > > https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… I'm looking forward to this one :-) Cheers, Alistair > On Wed, Aug 16, 2017 at 3:42 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > > > On Wed, Aug 16, 2017 at 12:16:52PM +0200, Stephane Ducasse wrote: > >> I'm integrating 20307 and I would like to really thank you for > >> - the bug entry description > >> - all the comments > >> - and tests in the PR. > >> > >> Tx!!! > > > > Thanks for your kind words. > > > > And for integrating the PR :-) > > > > > > I've re-submitted 20165 Support segment path printing. > > > > So the open list is: > > > > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing > > - https://github.com/pharo-project/pharo/pull/210 > > Note that this is a different PR from before, see the comments in > > the issue. > > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > > https://github.com/pharo-project/pharo/pull/133 > > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… > > https://github.com/pharo-project/pharo/pull/137 > > - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… > > This is the first step in fixing FileReference>>isSymlink and > > extending support for all file attributes returned by stat() and > > lstat(). > > The parent issue is: > > https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… > > > > > > Still to be closed (won't fix): > > > > - https://pharo.fogbugz.com/f/cases/18042 > > - https://github.com/pharo-project/pharo/pull/75 > > > > > > And waiting on FFI / kernel resolution: > > > > - https://pharo.fogbugz.com/f/cases/5723/ > > - https://github.com/pharo-project/pharo/pull/92 > > > > > > Cheers, > > Alistair > > > > >

Aug. 16, 2017

Issue that may break Epicea

by Stephane Ducasse

Hi martin https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile https://github.com/pharo-project/pharo/pull/133

Aug. 16, 2017