[PD] error on canvas while writing in object : tcl error: wrong # args: should be "pdtk_canvas_sendkey name state key iso shift"

[Jonathan Wilkes]

On 01/12/2014 07:19 PM, Dan Wilcox wrote:
> It's not possible to overload the function? aka 1 that takes 5 args 
> and another that takes 7? From what I can tell, the usual style within 
> the pd core has been to add new args to the end so that backwards 
> compatibility isn't sacrificed. Then again, I don't know the details 
> in this case ...

Well, if Pd-l2ork is sending 7 args to a canvas method "key", then it's 
surely using A_GIMME which allows an arbitrary number of arguments for 
the canvas "key" method.  But even if the tcl proc that gave the error 
took variable args in both ico and matju's code there'd likely still be 
a problem: two developers making independent changes to the same part of 
Pd.  The problem would just be pushed further down the line.  (That's a 
good reason for using type-checked args, btw.)

>
> With libpd, so far, we've avoid trying to make any large, incompatible 
> changes to the core. Mainly, at least IMO, because we do not want to 
> end up diverging to the point to where we'll never be able to get said 
> changes upstream. At this point, I'd love to sit down with a bunch of 
> you and work out a proposed roadmap to separating gui & pd core so 
> that libpd could become the standard core between flavors. I haven't 
> delved into the core enough to know if that is a foolish idea, but it 
> really seems like a great idea to standardize some of the 
> functionality ...

There are two issues:
1) making libpd the standard core across flavors
2) separating gui from audio/message system

#1 is fairly easy in theory.  It just means declaring by fiat that libpd 
wants to be the standard core between flavors.  In practice-- at least 
initially-- it's not too difficult either.  Just take features that you 
think should be standard and work them into libpd.  Something non-gui 
related and uncontroversial like "$@" or [initbang] would be a good 
candidate.

However, "reference implementation" will undoubtedly broaden the scope 
of libpd.  For example-- it'd be extremely useful to everyone who uses 
the Pd GUI environment to have refcounted symbols, in order to build a 
decent, robust string manipulation library that doesn't require some new 
type or syntax to learn.  If one just magically appeared tomorrow it 
would immensely broaden the scope of what your average Pd user could do 
in the language.  However for libpd specifically, this would matter very 
little since the language the libpd user is binding to certainly has a 
decent, robust string manipulation library already.  That's just one 
example.  There are likely many other areas that are orthogonal to 
embedding Pd in another language but important to the general 
development of Pd.

#2 is hard.  Where would you start and how would you proceed?

-Jonathan

>
> On Jan 12, 2014, at 5:55 PM, pd-list-request at iem.at 
> <mailto:pd-list-request at iem.at> wrote:
>
>> *From:*Jonathan Wilkes <jancsika at yahoo.com <mailto:jancsika at yahoo.com>>
>> *Subject:**Re: [PD] error on canvas while writing in object : tcl 
>> error: wrong # args: should be "pdtk_canvas_sendkey name state key 
>> iso shift"*
>> *Date:*January 12, 2014 at 5:54:49 PM EST
>> *To:*pd-list at iem.at <mailto:pd-list at iem.at>
>>
>>
>> On 01/12/2014 10:55 AM, Ivica Ico Bukvic wrote:
>>> Hi,
>>>
>>> This is because pd-l2ork has recently introduced a way of filtering 
>>> autorepeat keys so that [key], [keyup], and [keyname] objects only 
>>> report real key presses (as they should) while other forms of key 
>>> input (e.g. writing into an object box) still obey the autorepeat. 
>>> This had to be done in a way that breaks pdtk_canvas_send_key by 
>>> adding an additional variable and hence library like gridflow that 
>>> hasn't kept up with pd-l2ork's updates is no longer functioning as 
>>> it should. Adapting this to pd-l2ork should not take much of an 
>>> effort--it is just a question of time and who will do it.
>>
>> But notice the error tells the user that the proc expects five args, 
>> and not seven args like your revision of pdtk_canvas_sendkey.  This 
>> is because matju told Gridflow to steal the pdtk_canvas_sendkey proc 
>> and renamed it to pdtk_canvas_sendqui (which is pretty funny in 
>> itself), and then it sends tcl a brand new pdtk_canvas_sendkey proc 
>> with 5 args and code that presumably has to do with unicode support.  
>> I say that because you can find it in the Gridflow source file named 
>> "unicorn.cxx" (which is also funny in itself).
>>
>> So if you can figure out what it's doing, you can try to merging it 
>> into Pd-l2ork or at least make it compatible with it.  But there are 
>> probably several other places where matju drilled into Pd's walls 
>> from the outside, and they probably conflict with Pd-l2ork's 
>> renovations.  (Probably the widgetbehavior struct and comment struct 
>> conflict.)
>>
>> -Jonathan
>
> --------
> Dan Wilcox
> @danomatika
> danomatika.com <http://danomatika.com>
> robotcowboy.com <http://robotcowboy.com>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140113/4abf7125/attachment.htm>