March 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] New Version of Pillar on Windows

by stepharong

Hi mike I just checked - ./download.sh and it took the 50 stable version - make this created the html Now on windows you do not have make probably :) so you should $(OUTPUTDIRECTORY)/%.html: $(OUTPUTDIRECTORY)/%.html.json ./mustache --data=$< --template=${HTMLTEMPLATE} > $@ invoke ./mustache --data=output.html.json --template==yourhtmltemplate Tell me if this is working. > I am trying out the new version of Pillar (build 1940 or 1941) on > Windows on > Pharo 50770, following the Pillar tutorial in Enterprise Pharo book: > > I created the new file first.pillar containing: ! Hello World > > I ran: C:\Users\mldavis\Desktop\mldPillarWorking>Pharo.exe Pillar.image > pillar export --to=html first.pillar > > It created a file named: output.html.json containing: > {"content":"<section>\r\n<h1>1. Hello World</h1>\r\n</section>"} > > It was supposed to be an HTML document as shown in Enterprise Pharo para > 14.2 page 213 "5 Minutes Tutorial". > > Any suggestions what I missed or should do? > > mike > > > -- Using Opera's mail client: http://www.opera.com/mail/

March 9, 2017

Re: [Pharo-users] New Version of Pillar on Windows

by stepharong

Hi mike Was it working before? I will check on the HTML case (now) because I'm checked the mooc and the book. > I am trying out the new version of Pillar (build 1940 or 1941) on > Windows on > Pharo 50770, following the Pillar tutorial in Enterprise Pharo book: > I created the new file first.pillar containing: ! Hello World > > I ran: C:\Users\mldavis\Desktop\mldPillarWorking>Pharo.exe Pillar.image > pillar export --to=html first.pillar > > It created a file named: output.html.json containing: > {"content":"<section>\r\n<h1>1. Hello World</h1>\r\n</section>"} this is correct. It looks like the mustache phase is not applied. > > It was supposed to be an HTML document as shown in Enterprise Pharo para > 14.2 page 213 "5 Minutes Tutorial". > > Any suggestions what I missed or should do? Normally the makefile should invoke mustache to apply a template with as input such file > > mike > > > -- Using Opera's mail client: http://www.opera.com/mail/

March 9, 2017

Re: [Pharo-users] What is the craziest bug you ever face

by stepharong

we were talking during the workshop and on the simple things to help. - watch points with history of the value. - stop if the value of an instance variable is getting irregular i.e., = you get integer and suddenly inside you get a float! 1 1 1 1 2 3 4 2 2 1 1 12 2 3 32 1 1 1 1 22 1 1 1 1 1 1 1 2 33 1.2 2 3 3 4 4 - start to monitor (put alarm/breakpoints) newly created instances from a point I hope that soon we will have instance specific features of the Ressia debugger in Pharo debuger (stop the next time this object receive a message, stop the next tie this object changes any of its instance variables).

March 9, 2017

New Version of Pillar on Windows

by mldavis＠chaparralwest.com

I am trying out the new version of Pillar (build 1940 or 1941) on Windows on Pharo 50770, following the Pillar tutorial in Enterprise Pharo book: I created the new file first.pillar containing: ! Hello World I ran: C:\Users\mldavis\Desktop\mldPillarWorking>Pharo.exe Pillar.image pillar export --to=html first.pillar It created a file named: output.html.json containing: {"content":"<section>\r\n<h1>1. Hello World</h1>\r\n</section>"} It was supposed to be an HTML document as shown in Enterprise Pharo para 14.2 page 213 "5 Minutes Tutorial". Any suggestions what I missed or should do? mike

March 9, 2017

Re: [Pharo-users] What is the craziest bug you ever face

by stepharong

On Thu, 09 Mar 2017 20:53:48 +0100, Evan Donahue <emdonahu(a)gmail.com> wrote: > I actually have a whole class of bugs and elements of a very Pharo-y > solution. > > I do a lot of work in a logic programming framework. Being a logic > programming framework, it does not execute the code you write in a > start-to-finish manner, but executes a few lines here, then jumps around > and > executes a few lines there. As a result, if you are trying to trace the > evolution of a particular branch in the search tree, you can only follow > one > or two operations at a time in the debugger, then that branch gets put in > the queue and you may have to step through tens or hundreds of other > searches before you get back to it (if you can even recognize which > branch > you were following when it comes around again). This makes debugging > basically impossible in every other language this framework has been > ported > to, and the standard strategy is just to stare at the code. Pharo's > debugger > was already a step up, but it still wasn't nearly up to the task. did you think about adapting the debugger to your execution semantics? ... I read that you did it Excellent! > > I had been trying to get a particularly complex program to work for > several > days with no success, at which point I decided to investigate the > moldable > debugger framework. It took me several more days of going through the > debugger code in different versions and emailing with its developers to > get > something working, which just speaks to the state that framework and > documentation happened to be in at the time, but when I did get it > working I > found the bug in a few minutes. I essentially set up a visual depiction > of > the search tree where I could click on a branch and have the framework > run until that branch came up again to the front of the queue. This > meant I > could trace execution linearly by giving myself a way to get a handle on > the control flow via a visual interface. I have since changed my > framework and broken the debugger code, but I definitely intend to try to get that > rigged up again when the logic system is in a more polished form. > > Admittedly, many programs probably do not have the problem that their > control flow is so complex that a normal linear debugger is too > difficult to > understand, but on some level the ability to specify a debugging control > flow outside the execution of the program itself seems like a pretty > powerful idea, and something Pharo should be very well suited for with > its > interactivity/reflectivity. Maybe there would be more complex, > logic-based > programs if they weren't so hard to write! > > Evan > > > > -- > View this message in context: > http://forum.world.st/What-is-the-craziest-bug-you-ever-face-tp4937984p4938… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- Using Opera's mail client: http://www.opera.com/mail/

March 9, 2017

Re: [Pharo-users] What is the craziest bug you ever face

by stepharong

nice ideas! > > Stef, > > One of the things that I do all of the time when trying to debug > particularly difficult problems is to keep a "bug notebook". My "bug > notebook" is a text file where I record >information gleaned from an > inspector intermixed with comments, code and observations... > > I've attached an example from a couple of days ago (bug_notebook.txt). > The particular problem I am working on involves btree nodes being > improperly updated during index object updates. Each btree node is > basically a 2000+ element Array ... so >there is a lot of data to deal > with . > In the notebook, I extract the interesting entries from the btree node > and record the original set of values and then record the updated set of > values and in this particular case I >was able to "see" that after the > update I had 4 entries that were not properly deleted ... > In addition to recording the interesting chunks of large data > structures, I often end up with chunks of stacks from the debugger, > copies of a inspector panes in my "bug >notebooks" and chunks of code ... > > Over the last several weeks I have been tackling different sets of bugs > in this same area and I have been keeping a time-stamped log of the work > that I've done along the way >(analysis_notebook.txt) ... in this > notebook I've bee recording test results and branch/SHA information so > that I can easily reference different versions of methods as I work > >through fixing bugs and managing regressions ... There's a section in > the notebook where I've record performance information, so that when I > have finished work on this set of >bugs, I can evaluate how I've > impacted performance ... Finally at the very bottom of the notebook, > I've recorded a simple todo-list ... > The notebooks are on a shared disk so that I can access and update the > "bug notebook" when I am working from home on a mac or at work from a > linux box ... > I rely on the fact that I am working with text and not images ... since > I like to copy and paste as well as search for particular strings in the > data from the inspector ... in the >bug_notebook I searched for the > `victim` string in the text output from an inspector ... > > I have come to really depend upon bug notebooks when addressing > difficult bugs and I think that support for creating and maintaining bug > notebooks would be a valuable >addition the the debugging arsenal... > > Dale > > On 03/09/2017 10:50 AM, stepharong wrote: >> Thanks you all. >> >> The idea is that we want to see how we cn improve our debugging arsenal. >> So it is important that your scenario give use some hints.It is >> difficult to convey what we are really looking for :) >> >> >> >>> Hi guys >>> During the DSU workshop we were brainstorming about what are the most >>> difficult bugs we faced and what are the conceptual tools that would >>> have helped >>>you. >>> >>> Stef >> >> >> >> --Using Opera's mail client: http://www.opera.com/mail/ > -- Using Opera's mail client: http://www.opera.com/mail/

March 9, 2017

Re: [Pharo-users] What is the craziest bug you ever face

by Evan Donahue

I should add that users of the logic framework from non-smalltalk languages were very impressed by the potential. Evan -- View this message in context: http://forum.world.st/What-is-the-craziest-bug-you-ever-face-tp4937984p4938… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 9, 2017

Re: [Pharo-users] What is the craziest bug you ever face

by Evan Donahue

I actually have a whole class of bugs and elements of a very Pharo-y solution. I do a lot of work in a logic programming framework. Being a logic programming framework, it does not execute the code you write in a start-to-finish manner, but executes a few lines here, then jumps around and executes a few lines there. As a result, if you are trying to trace the evolution of a particular branch in the search tree, you can only follow one or two operations at a time in the debugger, then that branch gets put in the queue and you may have to step through tens or hundreds of other searches before you get back to it (if you can even recognize which branch you were following when it comes around again). This makes debugging basically impossible in every other language this framework has been ported to, and the standard strategy is just to stare at the code. Pharo's debugger was already a step up, but it still wasn't nearly up to the task. I had been trying to get a particularly complex program to work for several days with no success, at which point I decided to investigate the moldable debugger framework. It took me several more days of going through the debugger code in different versions and emailing with its developers to get something working, which just speaks to the state that framework and documentation happened to be in at the time, but when I did get it working I found the bug in a few minutes. I essentially set up a visual depiction of the search tree where I could click on a branch and have the framework run until that branch came up again to the front of the queue. This meant I could trace execution linearly by giving myself a way to get a handle on the control flow via a visual interface. I have since changed my framework and broken the debugger code, but I definitely intend to try to get that rigged up again when the logic system is in a more polished form. Admittedly, many programs probably do not have the problem that their control flow is so complex that a normal linear debugger is too difficult to understand, but on some level the ability to specify a debugging control flow outside the execution of the program itself seems like a pretty powerful idea, and something Pharo should be very well suited for with its interactivity/reflectivity. Maybe there would be more complex, logic-based programs if they weren't so hard to write! Evan -- View this message in context: http://forum.world.st/What-is-the-craziest-bug-you-ever-face-tp4937984p4938… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 9, 2017

Re: [Pharo-users] What is the craziest bug you ever face

by Dale Henrichs

Stef, One of the things that I do all of the time when trying to debug particularly difficult problems is to keep a "bug notebook". My "bug notebook" is a text file where I record information gleaned from an inspector intermixed with comments, code and observations... I've attached an example from a couple of days ago (bug_notebook.txt). The particular problem I am working on involves btree nodes being improperly updated during index object updates. Each btree node is basically a 2000+ element Array ... so there is a lot of data to deal with . In the notebook, I extract the interesting entries from the btree node and record the original set of values and then record the updated set of values and in this particular case I was able to "see" that after the update I had 4 entries that were not properly deleted ... In addition to recording the interesting chunks of large data structures, I often end up with chunks of stacks from the debugger, copies of a inspector panes in my "bug notebooks" and chunks of code ... Over the last several weeks I have been tackling different sets of bugs in this same area and I have been keeping a time-stamped log of the work that I've done along the way (analysis_notebook.txt) ... in this notebook I've bee recording test results and branch/SHA information so that I can easily reference different versions of methods as I work through fixing bugs and managing regressions ... There's a section in the notebook where I've record performance information, so that when I have finished work on this set of bugs, I can evaluate how I've impacted performance ... Finally at the very bottom of the notebook, I've recorded a simple todo-list ... The notebooks are on a shared disk so that I can access and update the "bug notebook" when I am working from home on a mac or at work from a linux box ... I rely on the fact that I am working with text and not images ... since I like to copy and paste as well as search for particular strings in the data from the inspector ... in the bug_notebook I searched for the `victim` string in the text output from an inspector ... I have come to really depend upon bug notebooks when addressing difficult bugs and I think that support for creating and maintaining bug notebooks would be a valuable addition the the debugging arsenal... Dale On 03/09/2017 10:50 AM, stepharong wrote: > Thanks you all. > > The idea is that we want to see how we cn improve our debugging arsenal. > So it is important that your scenario give use some hints. > It is difficult to convey what we are really looking for :) > > > > Hi guys > > During the DSU workshop we were brainstorming about what are the > most difficult bugs we faced and what are the conceptual tools > that would have helped you. > > Stef > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/

March 9, 2017

Re: [Pharo-users] [Pharo-dev] What is the craziest bug you ever face

by Holger Freyther

> On 9 Mar 2017, at 12:36, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi guys > > During the DSU workshop we were brainstorming about what are the most difficult bugs we faced and what are the conceptual tools that would have helped you. Tracking down a problem where a header file was like this struct touch_screen_event { #ifdef SOME_FLAG ... other fields #endif int x; int y; int pressure; }; The touchscreen library was compile with -DSOME_FLAG but the code using that library didn't have the flag set. This means the code using the touchscreen events read x/y from the wrong offset in memory. The example work of the touchscreen library worked while the real user didn't. It would have helped to embed struct sizes and offsets into the shared library to find differences at link time. --- Keyboard handling in kdrive (an Xserver for embedded/mobile usage): After plugging/unplugging USB into the device, the keyboard started to generate wrong keycodes. In Linux (depending on your keyboard mode) every key event is represented as a byte(?). This worked for a long time but then keyboards started to have more keys. So a special key value is used to indicate that a multi byte sequence will follow. As it turns out plugging/unplugging generated a multi-byte keyboard event... Not sure what would have helped? :)

March 9, 2017