- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Do we want AST-Debugger?

by Eliot Miranda

Hi Denis, > On May 25, 2016, at 3:12 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > Look at AST-Interpreter project which includes AST-Debugger http://smalltalkhub.com/#!/~Pharo/AST-Interpreter. Code is so simple comparing to "bytecode simulation" approach of current debugger. > AST debugger are independent from bytecode set. It just visit AST-nodes to simulate code execution. > > But current debugger simulates bytecode. It depends on current bytecode set. There are few kinds of BytecodeEncoders. To understand how current debugger is working you need to know many VM details. That's simply not true. In fact the amount known of the VM in both the bytecode debugger and the AST debugger is the same; both use VM primitives that aren't specified at the image level. Both the AST interpreter and the bytecode interpreter include the interpreter in Smalltalk in the image. Look at Context and InstructionStream to find the Smalktalk definitions of both the interpreter routines and the implementations of the bytecodes. > > So my question is why our debuggers are not based on AST interpreter? Why it is bad idea? (if it is bad). One area where you'll find the AST debugger worse is in performance. The bytecode debugger uses perform: to execute at full speed when possible (it does interpret when doing step into or through, but not when doing over). In fact this part of the system, because it has to catch no local returns and exceptions, is the most complex, but it's not because of VM details, it's because of the use of perform: to run code being debugged to run at full speed. Not to mention, if it isn't broke don't fix it. But seriously, the system is based on bytecode, and that bytecode is pretty straightforward and easy to learn. Why not put in the effort of learning it? Criticizing something in ignorance is not wise IMO. > Best regards, > Denis _,,,^..^,,,_ (phone)

June 5, 2016

Re: [Pharo-dev] moldable debugger challenge - iterator position

by Andrei Chis

Hi Ben, This seems like a nice idea. I think a first version of a debugger that does at least partially what you want is doable. Do you want to give it a try? I can create a basic skeleton of the debugger and then we can iterate. Cheers, Andrei On Sun, Jun 5, 2016 at 2:15 PM, Ben Coman <btc(a)openinworld.com> wrote: > A bit of a pie in the sky idea, but.... > I am currently tracing through code like this... > > XMLDOMVisitor >> visitDocument: theDocument > theDocument nodes do: [ :each | each accept: self ] > > and its hard to get a feel for where "each" is in theDocument. I > wonder if it would even be possible for the debugger to have a tab > that showed a list of "theDocument nodes" with a cursor positioned at > "each" ? Maybe the #do: iterator is automatically identified, or > maybe you'd need a pragma to define the tab, specifying the list > contents and which variable is the cursor. When the program crashes > on an item, you could selected an item a few earlier and choose to > break on that data value. > > So I guess all of it would be tough, but anyway thought I'd share that > flash of an idea. > cheers -ben > >

June 5, 2016

Re: [Pharo-dev] Do we want AST-Debugger?

by Andrei Chis

Hi Denis, No idea why the current debugger is not based on the AST interpreter or if there are any plans to move it. However, I think it will help to make the ASTDebugger compatible with the current debugger from Pharo. >From what I see the code from ASTDebugger is indeed very simple. One option could be to create a subclass of DebugSession that overrides those methods that control the execution. If this goes easy then we could just reuse both the Spec and the Glamour UIs. Do you want to give it a try or sync more on this? Cheers, Andrei On Wed, May 25, 2016 at 12:12 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > Look at AST-Interpreter project which includes AST-Debugger > http://smalltalkhub.com/#!/~Pharo/AST-Interpreter. Code is so simple > comparing to "bytecode simulation" approach of current debugger. > AST debugger are independent from bytecode set. It just visit AST-nodes to > simulate code execution. > > But current debugger simulates bytecode. It depends on current bytecode > set. There are few kinds of BytecodeEncoders. To understand how current > debugger is working you need to know many VM details. > > So my question is why our debuggers are not based on AST interpreter? Why > it is bad idea? (if it is bad). > > > Best regards, > Denis >

June 5, 2016

Re: [Pharo-dev] Playground and text evaluation printing result default.

by Tudor Girba

Hi Stef, The quotes appear only when you add the result in the playground. The typical use case for this is to keep track of several results. In this situation you do not want to modify the code to not affect the highlighting and this is why it gets in a comment. If you want to copy the content without quotes, you can do: Cmd+p -> popup Cmd+c -> selects the current line and copies the text Esc Cmd+v Perhaps we can add another keybinding like Shift+Enter for adding the text without quotes. Cheers, Doru > On Jun 5, 2016, at 10:20 PM, stepharo <stepharo(a)free.fr> wrote: > > Hi > > I would like to know if there is a setting to remove the "" when printing the result of an expression. > > I know that playground has been thought to help me, but today I watched myself removing the comments > > code so often that I would like to get a setting because such wrapping of results is really boring for me. > > I'm spending my time removing them and I start to wonder why they are any useful. > > I would help me to write fast tests for example in the debugger. > > Stef > > > -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

June 5, 2016

Playground and text evaluation printing result default.

by stepharo

Hi I would like to know if there is a setting to remove the "" when printing the result of an expression. I know that playground has been thought to help me, but today I watched myself removing the comments code so often that I would like to get a setting because such wrapping of results is really boring for me. I'm spending my time removing them and I start to wonder why they are any useful. I would help me to write fast tests for example in the debugger. Stef

June 5, 2016

Re: [Pharo-dev] got some bugs in Pharo 50

by Nicolai Hess

2016-06-04 20:41 GMT+02:00 stepharo <stepharo(a)free.fr>: > Just to report (I did not have the time to check in 60a) but I got red > square of death with komitter. > > I also got > > NECTypedModel>>initializeSelectorsFor: aClass > |excludedClasses| > selectors reset. > excludedClasses := (expanded ifTrue: [#()] ifFalse: [Object > withAllSuperclasses]). > selectors addAll: ((aClass allSelectorsWithout: excludedClasses) > > collect: [:each | NECSelectorEntry contents: each > type: #selector]) > > > > DNU on allSelectorsWithout: > > > with such code > > > mostCommonlyUsedSelectors > "self mostCommonlyUsedSelectors" > > | result | > result := Bag new. > environment cla > > ^ cursor here > > do: [ :each | result addAll: each selectors]. > ^ result sortedCounts > > > Stef > Can not reproduce the NEC- bug. What 5.0 image did you use, the release version? In what class did you try to add the method mostCommonlyUsedSelectors? nicolai

June 5, 2016

Re: [Pharo-dev] Another look at the [First Impression Count] in Pharo 5

by Ben Coman

On Sun, Jun 5, 2016 at 4:28 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Documentation always help :) > > What information will be helpful ? > I understand now your intend: you want to encourage people to discover > the Spot settings and how to write your own search plugin, so you expose > the source code plugin in the settings browser description. > It does not strike me, and I find your web page more helpful. But again, > only my perception. > > Now, try to imagine the worst case scenario by playing the role of a > student learning Pharo with MOOC. What information will be helpful for > your given a few facts? > > - you already discover Spot, and find the tools pretty cool. > - you learn about the Setting browser, there you discover you can toggle > Spot's option. What will be useful for you to understand what does the > plugings. Then, do you first want to know what does the plugin or how to > write your own? > > May be in the settings browser, GT Spotter Extensions category, Oh! Not seen that before. That is interesting! > you can write a bit more about writing spotter plugin, Sounds like a good place for such info. Or a button or link to bring up a help topic. > then in each plugin entry > write a human readable sentence explaining what does the plugin. And a bit of executable code to launch a demo of the GUI effect. > After all, from the Settings browser, each entry is just one shortcut > [alt]-b away. There is such a large number of extensions, its easy to be overwhelmed. Perhaps the could be another level, and/or display so some common/easy to follow ones at the top of the list of settings. cheers -ben > > > One remark, why is there both: > Trait>>#spotterSuperClassMethodsFor: > and > Class>>#spotterSuperClassMethodsFor: > > > The Trait one seems uneffective. > > Hilaire > > > Le 05/06/2016 08:17, Tudor Girba a Ã©crit : >> make it easier for a newcomer to comprehend? >> >> To get the conversation started, I put together a description of what they mean here: >> http://www.humane-assessment.com/blog/discovering-and-managing-spotter-exte… >> >> What do you think? Does this clarify the problem for you? If yes, what information would be useful to have in the image to better communicate the intent? > > -- > Dr. Geo > http://drgeo.eu > >

June 5, 2016

moldable debugger challenge - iterator position

by Ben Coman

A bit of a pie in the sky idea, but.... I am currently tracing through code like this... XMLDOMVisitor >> visitDocument: theDocument theDocument nodes do: [ :each | each accept: self ] and its hard to get a feel for where "each" is in theDocument. I wonder if it would even be possible for the debugger to have a tab that showed a list of "theDocument nodes" with a cursor positioned at "each" ? Maybe the #do: iterator is automatically identified, or maybe you'd need a pragma to define the tab, specifying the list contents and which variable is the cursor. When the program crashes on an item, you could selected an item a few earlier and choose to break on that data value. So I guess all of it would be tough, but anyway thought I'd share that flash of an idea. cheers -ben

June 5, 2016

Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5

by Henrik Nergaard

I like this approach, but it has a fatal flaw. If one is debugging file access, then as the debugger causes the source of methods to be fetched as the debugger displays them, so the file pointer in the read-only file the access of which one is trying to debug will change under one's feet, and the results will be completely wrong. Ah yes, and trying to do something like: SourceFiles readStreamAtFileIndex: 2 atPosition: 42 ifPresent: [ :stream | Halt now ] ifAbsent: [ ] Crashes the image. Here is another approach using a SharedQueue which caches any created read only copies up to a limit (5?). So for normal usage the queue will only hold 1 entry, but if there is concurrent work reading source files it might hold more so one do not have to always create a read only copy, if the first one is in use. readStreamAtFileIndex: index atPosition: position ifPresent: presentBlock ifAbsent: absentBlock | stream rofa result | rofa := queue nextOrNil. rofa ifNil: [ [ rofa := files collect: [ :f | f readOnlyCopy ] ] on: FileDoesNotExistException do: [ ^ absentBlock value ] ]. stream := rofa at: index. position > stream size ifTrue: [ ^ absentBlock value ]. stream position: position. result := presentBlock value: stream. queue size < 5 ifTrue: [ queue nextPut: rofa ] ifFalse: [ rofa do: [ :each | each close ] ]. ^ result Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Eliot Miranda Sent: Sunday, May 22, 2016 5:27 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Cc: squeak-dev(a)lists.squeakfoundation.org Subject: Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5 Hi Henrik, cc'ing squeak-dev cuz this is relevant to both communities (if and until Pharo takes the unwise decision to double the size of the image by keeping sources in the image). On May 22, 2016, at 5:01 AM, Henrik Nergaard <henrik.nergaard(a)uia.no<mailto:henrik.nergaard@uia.no>> wrote: There is a method in SourceFileArray #localProcessReadStreamAtFileIndex:atPosition:ifPresent:ifAbsent: which uses a ProccessLocalVariable called ProccessAndSessionLocalSourcesFileArray (see #localProcessReadOnlyCopy). Changing the last line in #readStreamAt:ifPresent:ifAbsent: to use this local process one makes the time to run this snippet: [ 1 systemNavigation browseMethodsWithSourceString: 'Morph' matchCase: false ] timeProfile >From ~ 10 seconds to ~ 3 seconds (Windows). However I cannot see that the file handles created by this processLocalVariable to ever be closed, so I suspect those are leaked? In that case there might be the need to implement some âclean upâ mechanism for ProccessLocalVariables before they are changed/nilled when a process changes. Another approach could be to not use a ProccessLocalVariabe at all, but extend the SourceFilesArray class to also hold one read only handle for each of its files, and use these in readStreamAtFileIndex:::â¦ . I guess that it is also necessary then to have semaphore protecting the two last lines such that setting the position in the stream and reading from it cannot be changed by other threads. I like this approach, but it has a fatal flaw. If one is debugging file access, then as the debugger causes the source of methods to be fetched as the debugger displays them, so the file pointer in the read-only file the access of which one is trying to debug will change under one's feet, and the results will be completely wrong. An approach which uses a special copy for the debugger doesn't work; one can't debug access to that file for the same reason. An approach that /should/ work is for the debugger to install its own copy around file-access. This should be recursive. So around every file access in the debugger there would need to be something like SourceFiles substituteFreshReadOnlyCopiesDuring: [...file access...] which would remember the current read-only files, evaluate the block using ensure: and have the ensure: block reinstall the previous file. Does this make sense? readStreamAtFileIndex: index atPosition: position ifPresent: presentBlock ifAbsent: absentBlock | stream result| stream := self readOnlyFileAt: index. stream ifNil: [ ^ absentBlock value ]. "sources file not available" position > stream size ifTrue: [ ^ absentBlock value ]. readSema critical: [ stream position: position. result := presentBlock value: stream ]. ^ result Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess Sent: Thursday, May 19, 2016 9:31 AM To: Pharo Development List <pharo-dev(a)lists.pharo.org<mailto:pharo-dev@lists.pharo.org>> Subject: Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5 Squeak caches the opened readonly file(handle). It does not have to reopen the file on every call for reading (readonly). 2016-05-18 19:12 GMT+02:00 stepharo <stepharo(a)free.fr<mailto:stepharo@free.fr>>: I am wondering why does the search 'method source with it' take so long in Pharo 5? On my PC, When I select the text 'menu' and search for all 'method source with it', in Squeak 5 it takes 3 seconds. In Pharo 5 it takes 21 seconds.

June 5, 2016

Re: [Pharo-dev] STON toJsonString produces broken JSON

by Sven Van Caekenberghe

Peter, > On 05 Jun 2016, at 13:10, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > shouldn't this throw an error instead of producing a broken JSON? > > STON toJsonString: ({'a' -> 'b'}) > ["a":"b"] > > (also STON toJsonString: ('a' -> 'b') => "a":"b") > > Clearly I forgot to cast it to dictionary, but shouldn't it throw up? > > Thanks, > Peter Yes, when working in JSON compatibility mode, it would better throw an error. The reason for this behaviour is because STON knows the concept of an association as a separate, primitive object. That was a cool contribution done later on. In normal use, you don't see this. I'll have a look. Sven

June 5, 2016