Timeline for What is the difference between Dynamic[x] and Dynamic[ h[x] ] for DynamicModule variables?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 13 at 19:14 | history | edited | Gustavo Delfino | CC BY-SA 4.0 |
Typo in source code. A close square bracket was missing.
|
| Jun 19, 2019 at 9:13 | comment | added | Kuba |
@FredSimons I agree with technical aspects. I have a different view on documentation though. WRI's point was to create a neat and simple Dynamic system which abstraction is described in documentation. They failed to implement in a way that is compatible with the documentation. I think they will prefer to adapt implementation rather than give more explanation because they seem to follow a 'user should not think too much' principle. That of course is also only my opinion.
|
|
| Jun 19, 2019 at 9:05 | comment | added | Fred Simons | @Kuba. The main problem that we experience is the lack of documentation. In your link you give a good explanation of the mainly undocumented way how updating with respect to a kernel variable works. However, when the Dynamic is in a DynamicModule, the updating is done fundamentally different from what you describe and completely undocumented. Hopefully, my description above is more or less correct. If it is, then the 'bugs' are consequences of the implementation of updating Dynamic in a DynamicModule. I am inclined to call that undesirable behaviour, despite it feels like a bug. | |
| Jun 19, 2019 at 7:59 | comment | added | Kuba | Btw, you may be interested in: mathematica.stackexchange.com/a/200571/5478 and linked topics. | |
| Jun 19, 2019 at 7:58 | comment | added | Kuba |
Sorry for the late reply. Of course +1. Otoh I don't agree with not considering it a bug. While you provide a good explanation based on internal workings, it is not what is 'sold' to the user. From the perspective of documentation of Dynamic that should not happen. Either documentation explains the process in details or we are free to call Dynamic abstraction a leaky one.
|
|
| May 1, 2019 at 16:51 | history | edited | Fred Simons | CC BY-SA 4.0 |
added 1225 characters in body
|
| Feb 3, 2017 at 7:45 | history | edited | Fred Simons | CC BY-SA 3.0 |
added 38 characters in body
|
| Feb 2, 2017 at 10:21 | history | edited | Fred Simons | CC BY-SA 3.0 |
added 11 characters in body
|
| Jan 31, 2017 at 20:29 | comment | added | Albert Retey |
Internal`GetTrackedSymbols is a very nice finding, it will be a great help when debugging more complicated cases, so +1 for that alone. As for the fixes: from a practical point of view it probably doesn't matter how exactly that is fixed, it should of course not be necessary at all. Internal`SetValueNoTrack -- if it works as indicated -- just gives us one more handle to try when things go wrong, so I think it is also a good finding. Unfortunately both are not documented, but I think it is worth a remark that the obviously were needed internally as well :-)
|
|
| Jan 31, 2017 at 19:41 | history | edited | Fred Simons | CC BY-SA 3.0 |
added 2161 characters in body
|
| Jan 31, 2017 at 19:25 | comment | added | Fred Simons |
Hi @Kuba. Indeed nice that we have a discussion again. I added an update with respect to your interesting remark on Dynamic["whatever", x]. You will see that I do not agree with you that is just coincidence. I still have to investigate why it does not work in the initialization option. I have some ideas, but I am not sure that I can test these ideas. If so, I will add it later.
|
|
| Jan 31, 2017 at 13:55 | comment | added | Kuba |
Hi, nice to see you, thanks for showing that functions. Though I don't think Internal`SetValueNoTrack[x, False] is a fix, as shown in my answer, whatever placed in Dynamic makes the FrontEnd more sensitive. So Dynamic["whatever";x] works too, it is just a coincidence. And if you run SetValueNoTrack in Initialization the problem still remains.
|
|
| Jan 31, 2017 at 13:43 | history | answered | Fred Simons | CC BY-SA 3.0 |