Closed ChasTheSpaz closed 8 years ago
After intense experimenting for a few days, I have concluded there may be memory as well as other issues in Threepenny, FireFox and Safari.:
I shall continue pounding away on this code until more information comes up...
I'm sorry that the sailing is not as smooth as you had probably hoped for. Concerning the individual issues:
I am pleasantly surprised you responded at all, as many developers of all kinds routinely ignore problems in their code after two or more years post-release. You seem to be one of the few who care.
I have doggedly continued to work on the code and went back to first principles of debugging practise via small code test cases. The upshot of all the work:
I was able to get things working by three means:
I was trying to use a simple canvas-related graphics package that did very little real work, but caused the greatest pain. I also included a javascript colour-picker that worked, but couldn't figure out how to connect the javascript colour-picker output data to the HTML5 data. Thus both canvas and colour-picker sources were summarily dropped.
I dug down into the HTML5 canvas tag and discovered it already had a relatively sophisticated colour-picker built into it, as well as image data fetch functions available from javascript. Ultimately I replaced the canvas and colour-picker tool sources to something called "literally canvas", and after getting over teething problems with that, finally got everything to go. "Literally Canvas" does NOT require jquery to work, so jquery was elided from the haskell source. JQuery was replaced by a version-pinned javascript reactive programming library that is required (the up-to-date version does not work) and customised to work with the "Literally Canvas" code. The reactive library had the "commented-out code" bug referred to earlier.
The only research question now is how to pass the current Canvas image data back to the haskell source that is attached to a button-pressed event. I am assuming for the time being that I can call javascript directly from the haskell code, as lightly mentioned in the Threepenny documentation.
As for the current issue #125 I would change/rename this bug to deal with the only outstanding issue to date that is closely related: the connection random drop-out problem. If I had the debugging tools, I would put a watch on the connection variable, then halt and check back on the stack when it changes. The bug should be reproducible - all I did was create an HTML /div id'd as "divMatches" which holds a single HTML /p (paragraph) which is then populated with 20 directory images, triggered by a button on the screen. Pressing the populate button a number of times will usually trigger the bug.
CSS-
img {
width: auto;
height: auto;
max-width: 64px;
max-height: 64px;
margin: 3px;
border: 1px;
border-style: dashed;
border-color: white;
}
#divMatches {
position: absolute;top:8px;
width: 360px;
height: 335px;
background: black;
}
Again, thanks for the interest. If I get the code working to my satisfaction, I will will happily add my project to your list of Threepenny projects if you so desire.
Using hand-coded script src includes of jquery-cookie.js, jquery.js (version 1.7.1) and sketch.js, the following code gets tagged by the Safari html inspector:
"Line 4097:18 $.cookie is not a function"
`/** Logging utilities ***** / Haskell.log = function () { if ($.cookie('Haskell.log.enabled') === "true") // ( ** THE OFFENDER ***) window.console.log.apply(window.console, arguments); } };
Haskell.log.enable = function (bool) { $.cookie('Haskell.log.enabled', bool.toString()); };`
Firefox reports different errors:
'Use of getPreventDefault() is deprecated. Use defaultPrevented instead.'
'Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help http://xhr.spec.whatwg.org/'
'TypeError: $(...).sketch is not a function' // it IS a function, but something ahead of the sketch file is having a problem