On Son, 2013-01-20 at 11:42 -0500, Ivica Ico Bukvic wrote:
Most of my GOP-abstractions are broken in pd-l2ork, because I often fit the GUI objects exactly into the GOP area. However, in pd-l2ork those iemguis don't show up, because of two reasons:
- Compared the pd/pd-extended, the position of the iemguis is shifted by
2px to the right. This means they overlap the GOP area in pd-l2ork.
- In pd-l2ork, iemguis aren't shown in the parent canvas when they
perfectly fit into the GOP area. Only when there is a padding area of 3px width on the right side, they appear in the parent. Fitting iemguis perfectly into GOPs is not supported in pd-l2ork.
They fit perfectly fine. It is that the original iemgui are inconsistent in positioning iemgui objects. Try auto-patching in regular pd various iemgui objects one below the other and you'll see how off they are. In other words, the regular pd lies about its x and sometimes y coordinates. It is just that this has been the case forever in pd that you accepted it as a norm. Granted, I completely understand why you would not want to mess with this but if you did (I went through this a couple months ago retrofitting everything I ever made for pd-l2ork and it was no fun), you'd end up with something that will be a lot more transportable over the long run than something that essentially compensates for a bug.
Ok, I see what you mean. When I align a hslider to a GOP area positioned at the coordinates 20 20, the hslider has the coordinates 23 20. It is wrong in Pd and Pd-extended. However, I don't quite see the advantage of fixing this, as it breaks portability of patches.
I tried other stuff of mine and stumbled on some issues, though I didn't invest much into finding out what the causes are. One patch does not the connect to the server. It turned out, that the protocol test fails in pd-l2ork for some reason. When it loaded a certain abstraction, pd-l2ork startet to fully use the CPU and filling up the RAM until I killed the process (this is reproducible).
It would be great to see what this is so that I can trace it down.
If you want to have a look on your own, open chat.pd from netpd and click the 'unpatch' button. Here, on Ubuntu 12.04.1 with pd-l2ork from yesterday it immediately starts eating memory. You can download it from here: https://github.com/reduzent/netpd2/archive/master.zip
Symbolboxes' support for german umlaute is broken. When typing 'blä' into:
[symbol
| [print]an empty line is printed to the console window (not even the 'print:' prefix shows up). messageboxes and other object classes seem not affected by this. [symbol blä(-[print] works fine.
Can you send a patch so that this can be tested out?
Actually no, since it doesn't trigger the problem when I save the symbol containing non-ASCII characters in the patch. You really have to type them in order to trigger the issue.
To illustrate the problem, I typed 'äöü' to a symbol box and save the result with [textfile]. I did the same with a message box. The results are indeed different. Here the content of the files (in hex):
from symbol box: E4 F6 FC 3B 0A
from message box: C3 A4 C3 B6 C3 BC 3B 0A
Obviously, symbol box writes in latin1 encoding, while message box (and probably the rest of Pd-l2ork) writes in proper utf-8. BTW, my locale is set to LANG=en_US.UTF-8.
pd-l2ork certainly is in good shape, but calling it bug-free seems a bit sensationalistic.
Indeed, claiming that every single 3rd-party external works is ridiculous and that is not what I've been referring to. I've been referring to the core (and I don't consider internationalization core yet since it is still a moving target both on l2ork and other iterations).
I didn't mention any issues with internationalization. If you think that my problem with German umlaute has something to do with internationalization, we disagree. I would consider proper UTF-8 support a core feature.
IMHO, even claiming only the core to be bug-free is a bit bold. That said, doubting the bug-freeness of your work doesn't mean to make you or Pd-l2ork appear in a bad light at all.
Roman