May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Jan Vrany

> > with the GT inspector, it has a very nice AST view: > > > The AST view of the GT Inspector is useless for serious work. > > > I've been spending the past weeks and months looking at ASTs, SSA and > CFGs of code and I allways need a twin view: node + source code (and > selecting one of those node select the relevant portion of the code). Agree, something like this would be even nicer... Jan

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Tudor Girba

It's already available :). [image: Inline image 1] Doru On Tue, May 19, 2015 at 10:18 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > > > > with the GT inspector, it has a very nice AST view: > > > > > > The AST view of the GT Inspector is useless for serious work. > > > > > > I've been spending the past weeks and months looking at ASTs, SSA and > > CFGs of code and I allways need a twin view: node + source code (and > > selecting one of those node select the relevant portion of the code). > > Agree, something like this would be even nicer... > > Jan > > > > -- www.tudorgirba.com "Every thing has its own flow"

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Andrei Chis

On Tue, May 19, 2015 at 10:02 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > > > 2015-05-19 7:49 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> On 13 May 2015, at 11:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> Thanks's Marcus. It is beautiful thing. >> >> Is parsing locate errors by "dot"s? I mean how it will parse "3+. 1+2"? >> It will be super cool if we have only "3+." as error but remains code as >> good one >> >> >> You can just look at >> >> OpalCompiler new >> source: 'method 3+. 1+2'; >> useFaultyForParsing: true; >> parse. >> > > Impressive ! > > >> >> with the GT inspector, it has a very nice AST view: >> > > The AST view of the GT Inspector is useless for serious work. > > I've been spending the past weeks and months looking at ASTs, SSA and CFGs > of code and I allways need a twin view: node + source code (and selecting > one of those node select the relevant portion of the code). > Switching to the 'Source code' view in the second pane gives you exactly that [image: Inline image 1] > > Thierry >

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Thierry Goubier

2015-05-19 7:49 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 13 May 2015, at 11:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Thanks's Marcus. It is beautiful thing. > > Is parsing locate errors by "dot"s? I mean how it will parse "3+. 1+2"? It > will be super cool if we have only "3+." as error but remains code as good > one > > > You can just look at > > OpalCompiler new > source: 'method 3+. 1+2'; > useFaultyForParsing: true; > parse. > Impressive ! > > with the GT inspector, it has a very nice AST view: > The AST view of the GT Inspector is useless for serious work. I've been spending the past weeks and months looking at ASTs, SSA and CFGs of code and I allways need a twin view: node + source code (and selecting one of those node select the relevant portion of the code). Thierry

May 19, 2015

Re: [Pharo-dev] [ANN] Garage 0.2 - GarageGlorp - GarageConnectionPool

by stepharo

guille Olivier worked on a pool system. FTL Faster Than Light Le 18/5/15 11:17, Guillermo Polito a Ã©crit : > > > El lun., 18 de may. de 2015 a la(s) 1:08 p. m., phil(a)highoctane.be > <mailto:phil@highoctane.be> <phil(a)highoctane.be > <mailto:phil@highoctane.be>> escribiÃ³: > > Ah, one thing with idle connections, it would be nice to have a > keepalive statement (like issued every x seconds to keep the > connection alive). > > > noted ^^ > > > Phil > â >

May 19, 2015

Re: [Pharo-dev] FreeType fonts and underline/strikethrough emphasis

by Nicolai Hess

2015-05-15 18:10 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > Thanks for the feedback, Sean. > Meanwhile, I think I found the reason. I think it got lost during the > merge of Display- and MultiDisplayScanner. I upload a fix, ready for review. > OK this is fixed now for Text and TextMorphs, but it still does not work for String/LabelMorphs. Anyone knows why we can set only bold and/or italic emphasis on a LogicalFont? StringMorph new contents:'hello';emphasis:1;openInHand. -> bold text StringMorph new contents:'hello';emphasis:8;openInHand. -> no change, it should be underlined This is different if the default font is a StrikeFont StringMorph new contents:'hello';emphasis:1;openInHand. -> bold text. StringMorph new contents:'hello';emphasis:8;openInHand. -> underlined. I found the place in LogicalFont, where other emphasis' are filtered out, but I don't understand why. nicolai > Nicolai > Am 15.05.2015 5:21 nachm. schrieb "Sean P. DeNigris" < > sean(a)clipperadams.com>: > >> Nicolai Hess wrote >> > I think this worked in pharo 1 and pharo 2. Now I have to find out why >> it >> > does not work anymore. >> >> Off the top of my head, I remember having a problem when the font I >> requested didn't exist. I would get a fallback font without any of the >> emphases I requested. HTH. >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/FreeType-fonts-and-underline-strikethrough-emphasis-t… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >>

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Marcus Denker

> On 13 May 2015, at 11:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Thanks's Marcus. It is beautiful thing. > > Is parsing locate errors by "dot"s? I mean how it will parse "3+. 1+2"? It will be super cool if we have only "3+." as error but remains code as good one > You can just look at OpalCompiler new source: 'method 3+. 1+2'; useFaultyForParsing: true; parse. with the GT inspector, it has a very nice AST view:

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Marcus Denker

> On 19 May 2015, at 01:51, Ben Coman <btc(a)openInWorld.com> wrote: > > > On Wed, May 13, 2015 at 4:41 PM, Damien Pollet <damien.pollet(a)gmail.com <mailto:damien.pollet@gmail.com>> wrote: > On 13 May 2015 at 08:35, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > Only three methods are needed to allow generating executable methods from such an AST: the SyntaxErrorNotification > is raised at runtime instead of compile time. > > > What is the advantage of allowing syntax errors into the running system, when they can be trapped statically before that ? It seems to me the advantage of this change is that it allows compilation to complete rather than bombing out part way through. But just because compilation finishes, doesn't mean it needs to be committed into the runtime system. > Syntax errors shouldn't require immediate fixing during compilation per se, but there should be a way to deal with them "at compile time" âwhatever that means for us. > For instance, faulty methods could have a flashy icon in the browser; I think I'd even color the whole package-class-protocol-selector in red if either of them contain faulty methods. > > I guess it *should* mean that the faulty-compiled-method is not committed but stored in a temporary buffer similar to how editing source is effectively done in a temporary buffer. Indication of the fault would only be needed in the window that compiled the fault. > No, we once experimented with adding support to Nautilus for that. But the result is that it is very easy to loose code. And you never know what is âreally savedâ and what not. But in general: I know that this is one of those things that I will not be able to convince anyone that it is useful before it is doneâ¦ which is good: I like to explore directions that everyone else rejects immediately. Marcus

May 19, 2015

New CogVMs available

by Eliot Miranda

at http://www.mirandabanda.org/files/Cog/VM/VM.r3350/. CogVM binaries as per VMMaker.oscog-eem.1315/r3350 General: Make the bounds check in primitiveObject:perform:... more restrictive and fix bugs in the commentary. Make stack pages a reasonable size. My math was wrong and the size was half as big as intended. Extend the fastPrimTrace scheme to trace stack overflow, prim failure and prim retry to help debug the phantom stack frame bug in Cog Spur. Cogit: Fix old bug in ceMNUFromPICMNUMethod:receiver: that has been masked by cacheing of MNU method in MNU PIC entries. ceMNUFromPICMNUMethod:receiver: must set up lkupClass before calling handleMNU:... Revamp icache flushing in the Cogit for ARM. Move icache flush for generated methods/pics to the fillIn*Header: routines. Make sure the cache is flushed in generateCaptureCStackPointers:. Flush the entire PIC when extending it. Fix ARM-only regression in StackToRegisterMappingCogit's PIC aborts when the SimpleStackBasedCogit was fixed. Make ARM rotated 8bit constants actually be correct(er) ie 16r4000001 (SmallInteger 16r2000000) work. Spur: Fix ceActivateFailingPrimitiveMethod: to return properly after retrying a primitive after checkForAndFollowForwardedPrimitiveState. e.g. fixes | s | 1 to: 5 do: [:i| s := 'bar'. s becomeForward: 'bzzt' copy. 'foo' <= s] Fix bug in followForwardedFrameContents:stackPointer: so that arguments are actually followed. N.B. drives the above bug underground ;-). so that named constants (defines) are not elided. Make accessor depth calculation more accurate by not considering fetchInteger:ofObject: and arraySize: et al as object accessors. Newspeak: Remove landmine left from restructing implicit receiver and outer sends as clean sends. Slang: Do a more thorough job of transforming complex to:[by:]do: loops so that the limit expression is only evaluated once, not on each iteration of the loop. Make the read-before-written initializer safer, only initialzing simple types. Plugins: Regenerated because of changes in accessorDepth calculation, constant elimination, and read-before-use initialization. -- best, Eliot

May 19, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by Kasper Osterbye

Sergio Fedi wrote >> >> Case created: >> >> >> https://pharo.fogbugz.com/f/cases/15557/New-PackageManifests-should-be-clas… >> > > Case Resolved (Review needed) It is scary, but all pharo unittests succeed with either implementation :-( -- View this message in context: http://forum.world.st/Manifest-class-values-instance-or-class-side-tp482644… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 19, 2015