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

Re: [Pharo-project] Fwd: break point

by Marcus Denker

On Aug 17, 2010, at 9:37 PM, Eliot Miranda wrote: > At least in Squeak 4.1. one can see the fact its break-pointed in the debugger because the method in the debugger is decompiled. Of course it's far from nice anyway... showing the break context, no breakpoint visibly shown in the debugger... I honestly don't remember what was changed. And why the debugger would show decompied code? All this mapping source-offset to bytecode offset is horribly complex in the debugger... > > We should add a nice UI for it *and* soon we can do oh so much better much easier :-) > > Tell me more, tell me more, was it love at first sight?? What are you cooking up? > The first step will be un-spectacular... but I just realized that it should quite simple to add real breakpoints with the Opal Compiler framework using bytesurgen or even RB-AST transformations. In the current Debugger, that is. e.g. using bytecode level manipulations: Debugger knows the bytecode-offsets of selected code, the bytecode representation bytesurgen works on knows these offsets too (either when decompiled from bc or after code-gen). So one can easily extend Bytesurgeon to do something like "add bytecode described by the following smalltalk code (which is a probe) before the bytecodes that encode the source offsets X". Of course we need to take care with source-bc mapping for the debugger... So what I really want to do is to get rid of bytecode completely as a user-visible artefact. The Persephone/ Reflectivity stuff has shown that this simplifies everything *a lot*. Helvetia is the other example. Lukas has a Debugger that directly works on RB AST trees. With stepping and all. And the RB tree can be annotated. And we can put meaning on these annotations (see Reflectivity) in the sense of "before executing the node, execute this block" But looking into that is the step after. One step at a time... first finishing the Opal Compiler. Then Bytesurgeon, then ByteSurgeon using a Helvetia DSL... What Opal will bring is: Parser to RB-AST (from Helvetia, scannerless, composable, great). Or optionally RBParser (faster). Then a Semantic checker that does all the ugly closure analysis in a far less ugly way (maintainable, understandable for people non-Eliot...) while *not destroying the AST* . A Backend that allows for a very simple code-gen visitor. And there is a evaluating visitor for the AST as another nice tool for the tool-chest. Then a back-end that allows bytecode-level manipulation to be done relatively high-level (aka bytsurgeon). We will see... one step at a time. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 17, 2010

Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?

by Adrian Lienhard

I heard about that problem too... In Squeak 3.9 I can interrupt [[true] whileTrue] fork, but not in Pharo. Has anybody an idea why this doesn't work anymore? Adrian On Aug 17, 2010, at 16:27 , Henrik Johansen wrote: > > On Aug 17, 2010, at 3:38 20PM, TimM wrote: > >> Henrik Johansen wrote: >> >>> Is this code run in a separate process? >>> UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles. >>> Whether that is desired behaviour or not, is up for discussion :) >> >> I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed. >> >> Tim > There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc. > > Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop. > > Try the following from a workspace to illustrate: > > "Interruptable with Cmd-dot" > [true ] whileTrue. > > "Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)" > [[true ] whileTrue] forkAt: Processor activePriority - 1 "Code run from a workspace will run in the UI process, so active priority will be the UI process priority" > > "Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles" > [[true] whileTrue] fork "Fork forks of the process at same priority as active process" > > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2010

Re: [Pharo-project] Load OB in Pharo 1.2

by Henrik Sperre Johansen

On 17.08.2010 21:14, StÃ©phane Ducasse wrote: > On Aug 17, 2010, at 8:28 PM, Lukas Renggli wrote: > >> Removing them is cool, but there should be a grace period where they >> are deprecated. > But how? We could let the subclass empty in this case (is it what you mean) but > when we are doing refactoring like changing iv it may not work. > We could not really let the classes in the system. > > I have the impression that having branch at the tool level is something that we cannot avoid. You can do the same as for CrLFFileStream, keep the empty class, but reroute any instantiations to super which now contains its functionality. Like Lukas said, deprecate Pluggable*Plus class >> basicNew in 1.2. Then remove them in 1.3. Cheers, Henry

Aug. 17, 2010

Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?

by Henrik Sperre Johansen

On 17.08.2010 21:04, StÃ©phane Ducasse wrote: > thanks for reporting that. > do you have a case that we could reproduce or have an image people could access? > > Stef > > On Aug 17, 2010, at 8:30 PM, Panu Suominen wrote: > >> I think I have the same problem. It does not actually jam the image >> right away but makes it really slow which renders it unusable. After a >> while memory runs out and it crashes. Have not seen this many times >> thou. It would help if there was a key sequence which would suspend >> other than UI process. >> >> -- >> Panu >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project See my examples, the last one reproduces it. Cheers, Henry

Aug. 17, 2010

Re: [Pharo-project] ODBC extension

by Schwab,Wilhelm K

Not that smart yet :) I figured I'd start here and suggestions like your would arise. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Tuesday, August 17, 2010 3:55 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] ODBC extension Why not comitting it in ODBC repository also? On Tue, Aug 17, 2010 at 9:52 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: I have a small group of packages that might be of interest to people porting code from Dolphin. By far the least controversial of these packages is a small addition to the ODBC packages. I have included a few things (e.g. #sqlCleanup) that I added to my Dolphin images and either needed or simply wanted in Pharo. Use them or ignore them as you see fit. Of perhaps general interest are methods to access schema information: #tables and #columnsForTable:owner:. The package is in the inbox: http://squeaksource.com/PharoInbox/DolphinCompatibility-ODBC-BillSchwab.2.m… Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2010

Re: [Pharo-project] ODBC extension

by Mariano Martinez Peck

Why not comitting it in ODBC repository also? On Tue, Aug 17, 2010 at 9:52 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I have a small group of packages that might be of interest to people > porting code from Dolphin. By far the least controversial of these packages > is a small addition to the ODBC packages. I have included a few things > (e.g. #sqlCleanup) that I added to my Dolphin images and either needed or > simply wanted in Pharo. Use them or ignore them as you see fit. > > Of perhaps general interest are methods to access schema information: > #tables and #columnsForTable:owner:. The package is in the inbox: > > > http://squeaksource.com/PharoInbox/DolphinCompatibility-ODBC-BillSchwab.2.m… > > Bill > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 17, 2010

Re: [Pharo-project] Fwd: break point

by Mariano Martinez Peck

On Tue, Aug 17, 2010 at 9:49 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > Yes... > > > > I was guilty of harvesting that for 3.7 or 3.6... (Squeak that is). > > nobody is guilty (we are not in religious stuff). > > > > > In the Old Browser, you have an entry "toggle break on entry". What this > > does is that it compiles a new version of the method (it uses a bit a > strange > > way of doing that using the old AST...). This version has a self break at > the beginning, > > yet points to the old source so you don't see it. > > > > Now the BreakPointmanager can remove all BreakPoints, all for a class and > things like > > that easily. it knows if there is one. CompiledMethod has #hasBreakpoint. > Setting breakpoints > > does not invalidate code (as opposed to self halt). > > > > So there is everything to make a nice UI for it... > > > > The model is a bit limited. Only break on entry, no probes and so on. But > it works. > > The limitations are mostly because everything else is hard to do with the > bad > > model we have in the current system of doing structural reflection below > method > > granularity... > > > > We should add a nice UI for it *and* soon we can do oh so much better > much easier :-) > > > May be lukas can get inspired and provide some break points support for OB > :) > For CodeHolder may be somebody else wants to have a look. > > But promise me that after putting a breakpoint I won't see my package as dirty ;) > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 17, 2010

[Pharo-project] ODBC extension

by Schwab,Wilhelm K

I have a small group of packages that might be of interest to people porting code from Dolphin. By far the least controversial of these packages is a small addition to the ODBC packages. I have included a few things (e.g. #sqlCleanup) that I added to my Dolphin images and either needed or simply wanted in Pharo. Use them or ignore them as you see fit. Of perhaps general interest are methods to access schema information: #tables and #columnsForTable:owner:. The package is in the inbox: http://squeaksource.com/PharoInbox/DolphinCompatibility-ODBC-BillSchwab.2.m… Bill

Aug. 17, 2010

Re: [Pharo-project] Fwd: break point

by StÃ©phane Ducasse

> Yes... > > I was guilty of harvesting that for 3.7 or 3.6... (Squeak that is). nobody is guilty (we are not in religious stuff). > > In the Old Browser, you have an entry "toggle break on entry". What this > does is that it compiles a new version of the method (it uses a bit a strange > way of doing that using the old AST...). This version has a self break at the beginning, > yet points to the old source so you don't see it. > > Now the BreakPointmanager can remove all BreakPoints, all for a class and things like > that easily. it knows if there is one. CompiledMethod has #hasBreakpoint. Setting breakpoints > does not invalidate code (as opposed to self halt). > > So there is everything to make a nice UI for it... > > The model is a bit limited. Only break on entry, no probes and so on. But it works. > The limitations are mostly because everything else is hard to do with the bad > model we have in the current system of doing structural reflection below method > granularity... > > We should add a nice UI for it *and* soon we can do oh so much better much easier :-) May be lukas can get inspired and provide some break points support for OB :) For CodeHolder may be somebody else wants to have a look. Stef

Aug. 17, 2010

[Pharo-project] why TextMorph and PluggableTextMorph are not

by StÃ©phane Ducasse

well in the same hierarchy? I like because I'm so naive about how the world could be :) Stef

Aug. 17, 2010