Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using experimental pharo breakpoint on subclasses of WAHTMLCanvas does not work #829

Closed
GoogleCodeExporter opened this issue Mar 25, 2015 · 5 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. set a breakpoint (right click on method) on e.g. tableData
2. create a table with WAComponent using tableData.
3. you will have as much <br> tags in the document as you have created tableData

What is the expected output? What do you see instead?
Application should stop
html break writes <br> into the document

What version of the product are you using? On what operating system?
3.1 MacOS

Please provide any additional information below.

Original issue reported on code.google.com by max.bar...@googlemail.com on 10 Sep 2014 at 5:40

@GoogleCodeExporter
Copy link
Author

Have you debugged this? Is this a Seaside or Pharo bug?

Original comment by philippe...@gmail.com on 11 Sep 2014 at 5:18

  • Added labels: Platform-Pharo
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

I haven't debugged it yet because it seems to be obvious:
The Pharo breakpoint is nothing more than 'self break' -> see 
Object(*Tools-Browser)>>break. WATagCanvas overrides this and WAHTMLCanvas is 
implementing it with ^ self brush: WABreakTag new

So regarding the code the result is expected. Its just not expected regarding 
usage of breakpoint.

There are two possible ways of getting rid of the issue:
- Pharo changes the breakpoint method from self break to self breakpoint (e.g.)
- Seaside changes the WATagCanvas>>break method from break to lineBreak for 
example.

I am not deep enough into Pharo and Seaside to decide which is the better 
solution.

Original comment by max.bar...@googlemail.com on 11 Sep 2014 at 7:58

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

So, everyone who defines a message #break will have broken code.
imho, Pharo should use another name, preferably prefixed with and underscore 
(convention often used for system-used methods), e.g. #_break

I think this should be reported on the Pharo issue tracker

Original comment by jo...@yesplan.be on 11 Sep 2014 at 8:05

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

I send a mail to the pharo-dev mailinglist to ask for their opinion on the 
method name.

Original comment by jo...@yesplan.be on 13 Sep 2014 at 8:54

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Marcus pointed out on the mailinglist that this has been removed from Pharo 4:

"#break has been removed from Pharo4 as we will move to use Refelectivity 
meta-links
for breakpoints (meta annotation on the AST level, not source visible)."

Since this is an experimental feature and that it is removed from the next 
version, I propose to not fix this.
Please reply if you do not agree.

Original comment by jo...@yesplan.be on 14 Sep 2014 at 12:55

  • Changed state: WontFix
  • Added labels: ****
  • Removed labels: ****

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant