www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pyd: Wrapping too many functions in a class gives a compiler error

reply "Simen Haugen" <simen norstat.no> writes:
I cannot wrap all the functions in my class without getting the compile 
error:
Error: identifier _D3pyd9func_wrap1172__T22app (...) is too long by x 
characters.

And its several thousand characters too long...

Definition:
module pynsd;

import pyd.pyd,
    nsd;


extern (C) void PydMain() {
 // Functions

 module_init();

 // Classes
 wrap_class!(
  NSDError
  , Init!(void function(char[]))
 );

 wrap_class!(
  Respondent
  , Init!(void function(char[]))
  , Def!(Respondent.getValue)
  , Def!(Respondent.setValue)
 );

 wrap_class!(
  SurveyObject
  , Def!(SurveyObject.ascLength)
  , Property!(SurveyObject.ascStart)
  , Property!(SurveyObject.ascStop)
  , Property!(SurveyObject.caption)
  , Property!(SurveyObject.id)
 );

 wrap_class!(
  ListItem
  , Init!(void function(char[], char[]))
  , Def!(ListItem.isThis)
  , Property!(ListItem.altid)
 );

 wrap_class!(
  Question
  , Def!(Question.isList)
  , Def!(Question.asList)
  , Def!(Question.isOpen)
  , Def!(Question.asOpen)
  , Def!(Question.asQuestion)
 );

 wrap_class!(
  OpenQuestion
  , Init!(void function(char[], char[]))
 );

 wrap_class!(
  ListQuestion
  , Init!(void function(char[], char[]))
  , Def!(ListQuestion.numItems)
  , Def!(ListQuestion.getItem)
  , Def!(ListQuestion.exclusive)
  , Property!(ListQuestion.items)
 );


 wrap_class!(
  NSD
  , Init!(void function(char[], char[]))
  , Def!(NSD.filter, "filter", Respondent[] function(char[]))
  , Def!(NSD.filter, "filterResps", Respondent[] function(char[], 
Respondent[]))
  , Def!(NSD.countOf, "countOf", double function(char[]))
  , Def!(NSD.countOf, "countOfResps", double function(char[], Respondent[]))
  , Def!(NSD.getQuestion)
  , Def!(NSD.getQuestionIds)
  , Def!(NSD.getRespondent)
  , Def!(NSD.numQuestions)
  , Def!(NSD.respondents)
  , Def!(NSD.writeasc)
  , Def!(NSD.writensd)
  , Def!(NSD.writesps)
  , Def!(NSD.writecsv)
  , Def!(NSD.clear)
  , Property!(NSD.questions)
 );
}

Full output:

running build
running build_ext
building 'nsd' extension
sources:  ['nsd.d', 'text.d', 'stack.d', 'parser.d', 'script.d', 
'BaseParser.d',
 'IParser.d', 'types.d', 'pynsd.d', 'python.d', 'class_wrap.d', 
'ctor_wrap.d', '
def.d', 'dg_convert.d', 'exception.d', 'func_wrap.d', 'lib_abstract.d', 
'make_ob
ject.d', 'make_wrapper.d', 'op_wrap.d', 'pyd.d', 'pydobject.d', 
'struct_wrap.d',
 'pydmain.d', 'Default.d', 'Demangle.d', 'Nameof.d', 'Util.d', 
'python_dll_windo
ws_boilerplate.d']
c:\d\dmd\bin\dmd.exe -c -version=Python_2_4_Or_Later -version=Python_Unicode_UCS
2 -debug -IC:\Python24\lib\site-packages\celerid\infrastructure\python\2.4 -IC:\
Python24\lib\site-packages\celerid\infrastructure -ofbuild\temp.win32-2.4\Releas
e\project\nsd.obj nsd.d
c:\d\dmd\bin\dmd.exe -c -version=Python_2_4_Or_Later -version=Python_Unicode_UCS
2 -debug -IC:\Python24\lib\site-packages\celerid\infrastructure\python\2.4 -IC:\
Python24\lib\site-packages\celerid\infrastructure -ofbuild\temp.win32-2.4\Releas
e\project\util\text.obj util\text.d
c:\d\dmd\bin\dmd.exe -c -version=Python_2_4_Or_Later -version=Python_Unicode_UCS
2 -debug -IC:\Python24\lib\site-packages\celerid\infrastructure\python\2.4 -IC:\
Python24\lib\site-packages\celerid\infrastructure -ofbuild\temp.win32-2.4\Releas
e\project\util\stack.obj util\stack.d
c:\d\dmd\bin\dmd.exe -c -version=Python_2_4_Or_Later -version=Python_Unicode_UCS
2 -debug -IC:\Python24\lib\site-packages\celerid\infrastructure\python\2.4 -IC:\
Python24\lib\site-packages\celerid\infrastructure -ofbuild\temp.win32-2.4\Releas
e\project\parser.obj parser.d
c:\d\dmd\bin\dmd.exe -c -version=Python_2_4_Or_Later -version=Python_Unicode_UCS
2 -debug -IC:\Python24\lib\site-packages\celerid\infrastructure\python\2.4 -IC:\
Python24\lib\site-packages\celerid\infrastructure -ofbuild\temp.win32-2.4\Releas
e\project\script.obj script.d
c:\d\dmd\bin\dmd.exe -c -version=Python_2_4_Or_Later -version=Python_Unicode_UCS
2 -debug -IC:\Python24\lib\site-packages\celerid\infrastructure\python\2.4 -IC:\
Python24\lib\site-packages\celerid\infrastructure -ofbuild\temp.win32-2.4\Releas
e\outside\BaseParser.obj c:\d\dmd\ddl\trunk\enki\BaseParser.d
c:\d\dmd\bin\dmd.exe -c -version=Python_2_4_Or_Later -version=Python_Unicode_UCS
2 -debug -IC:\Python24\lib\site-packages\celerid\infrastructure\python\2.4 -IC:\
Python24\lib\site-packages\celerid\infrastructure -ofbuild\temp.win32-2.4\Releas
e\outside\IParser.obj c:\d\dmd\ddl\trunk\enki\IParser.d
c:\d\dmd\bin\dmd.exe -c -version=Python_2_4_Or_Later -version=Python_Unicode_UCS
2 -debug -IC:\Python24\lib\site-packages\celerid\infrastructure\python\2.4 -IC:\
Python24\lib\site-packages\celerid\infrastructure -ofbuild\temp.win32-2.4\Releas
e\outside\types.obj c:\d\dmd\ddl\trunk\enki\types.d
c:\d\dmd\bin\dmd.exe -c -version=Python_2_4_Or_Later -version=Python_Unicode_UCS
2 -debug -IC:\Python24\lib\site-packages\celerid\infrastructure\python\2.4 -IC:\
Python24\lib\site-packages\celerid\infrastructure -ofbuild\temp.win32-2.4\Releas
e\project\pynsd.obj pynsd.d
wrap_class: NSDError
class wrapper : T {
    mixin OverloadShim;
    alias Params[0] __pyd_p0;
    alias __pyd_p0.ctors __pyd_c0;
    this(ParameterTypeTuple!(__pyd_c0[0]) t) {
        super(t);
    }
    static if (is(typeof(new T))) {
        this() { super(); }
    }

}

wrap_class: Respondent
class wrapper : T {
    mixin OverloadShim;
    alias Params[0] __pyd_p0;
    alias __pyd_p0.ctors __pyd_c0;
    this(ParameterTypeTuple!(__pyd_c0[0]) t) {
        super(t);
    }
    static if (is(typeof(new T))) {
        this() { super(); }
    }
    alias Params[1] __pyd_p1;
    ReturnType!(__pyd_p1.func_t) 
getValue(ParameterTypeTuple!(__pyd_p1.func_t) t
) {
        return __pyd_get_overload!("getValue", 
__pyd_p1.func_t).func("getValue",
 t);
    }
    alias Params[2] __pyd_p2;
    ReturnType!(__pyd_p2.func_t) 
setValue(ParameterTypeTuple!(__pyd_p2.func_t) t
) {
        return __pyd_get_overload!("setValue", 
__pyd_p2.func_t).func("setValue",
 t);
    }

}

class.def: getValue
class.def: setValue
wrap_class: SurveyObject
class wrapper : T {
    mixin OverloadShim;
    alias Params[0] __pyd_p0;
    ReturnType!(__pyd_p0.func_t) 
ascLength(ParameterTypeTuple!(__pyd_p0.func_t)
t) {
        return __pyd_get_overload!("ascLength", 
__pyd_p0.func_t).func("ascLength
", t);
    }
    alias Params[1] __pyd_p1;
    ReturnType!(__pyd_p1.get_t) ascStart() {
        return __pyd_get_overload!("ascStart", 
__pyd_p1.get_t).func("ascStart");

    }
    ReturnType!(__pyd_p1.set_t) ascStart(ParameterTypeTuple!(__pyd_p1.set_t) 
t)
{
        return __pyd_get_overload!("ascStart", 
__pyd_p1.set_t).func("ascStart",
t);
    }
    alias Params[2] __pyd_p2;
    ReturnType!(__pyd_p2.get_t) ascStop() {
        return __pyd_get_overload!("ascStop", 
__pyd_p2.get_t).func("ascStop");
    }
    ReturnType!(__pyd_p2.set_t) ascStop(ParameterTypeTuple!(__pyd_p2.set_t) 
t) {

        return __pyd_get_overload!("ascStop", 
__pyd_p2.set_t).func("ascStop", t)
;
    }
    alias Params[3] __pyd_p3;
    ReturnType!(__pyd_p3.get_t) caption() {
        return __pyd_get_overload!("caption", 
__pyd_p3.get_t).func("caption");
    }
    ReturnType!(__pyd_p3.set_t) caption(ParameterTypeTuple!(__pyd_p3.set_t) 
t) {

        return __pyd_get_overload!("caption", 
__pyd_p3.set_t).func("caption", t)
;
    }
    alias Params[4] __pyd_p4;
    ReturnType!(__pyd_p4.get_t) id() {
        return __pyd_get_overload!("id", __pyd_p4.get_t).func("id");
    }
    ReturnType!(__pyd_p4.set_t) id(ParameterTypeTuple!(__pyd_p4.set_t) t) {
        return __pyd_get_overload!("id", __pyd_p4.set_t).func("id", t);
    }

}

class.def: ascLength
class.prop: ascStart
class.prop: ascStop
class.prop: caption
class.prop: id
wrap_class: ListItem
class wrapper : T {
    mixin OverloadShim;
    alias Params[0] __pyd_p0;
    alias __pyd_p0.ctors __pyd_c0;
    this(ParameterTypeTuple!(__pyd_c0[0]) t) {
        super(t);
    }
    static if (is(typeof(new T))) {
        this() { super(); }
    }
    alias Params[1] __pyd_p1;
    ReturnType!(__pyd_p1.func_t) isThis(ParameterTypeTuple!(__pyd_p1.func_t) 
t)
{
        return __pyd_get_overload!("isThis", __pyd_p1.func_t).func("isThis", 
t);

    }
    alias Params[2] __pyd_p2;
    ReturnType!(__pyd_p2.get_t) altid() {
        return __pyd_get_overload!("altid", __pyd_p2.get_t).func("altid");
    }
    ReturnType!(__pyd_p2.set_t) altid(ParameterTypeTuple!(__pyd_p2.set_t) t) 
{
        return __pyd_get_overload!("altid", __pyd_p2.set_t).func("altid", 
t);
    }

}

class.def: isThis
class.prop: altid
wrap_class: Question
class wrapper : T {
    mixin OverloadShim;
    alias Params[0] __pyd_p0;
    ReturnType!(__pyd_p0.func_t) isList(ParameterTypeTuple!(__pyd_p0.func_t) 
t)
{
        return __pyd_get_overload!("isList", __pyd_p0.func_t).func("isList", 
t);

    }
    alias Params[1] __pyd_p1;
    ReturnType!(__pyd_p1.func_t) asList(ParameterTypeTuple!(__pyd_p1.func_t) 
t)
{
        return __pyd_get_overload!("asList", __pyd_p1.func_t).func("asList", 
t);

    }
    alias Params[2] __pyd_p2;
    ReturnType!(__pyd_p2.func_t) isOpen(ParameterTypeTuple!(__pyd_p2.func_t) 
t)
{
        return __pyd_get_overload!("isOpen", __pyd_p2.func_t).func("isOpen", 
t);

    }
    alias Params[3] __pyd_p3;
    ReturnType!(__pyd_p3.func_t) asOpen(ParameterTypeTuple!(__pyd_p3.func_t) 
t)
{
        return __pyd_get_overload!("asOpen", __pyd_p3.func_t).func("asOpen", 
t);

    }
    alias Params[4] __pyd_p4;
    ReturnType!(__pyd_p4.func_t) 
asQuestion(ParameterTypeTuple!(__pyd_p4.func_t)
 t) {
        return __pyd_get_overload!("asQuestion", 
__pyd_p4.func_t).func("asQuesti
on", t);
    }

}

class.def: isList
class.def: asList
class.def: isOpen
class.def: asOpen
class.def: asQuestion
wrap_class: OpenQuestion
class wrapper : T {
    mixin OverloadShim;
    alias Params[0] __pyd_p0;
    alias __pyd_p0.ctors __pyd_c0;
    this(ParameterTypeTuple!(__pyd_c0[0]) t) {
        super(t);
    }
    static if (is(typeof(new T))) {
        this() { super(); }
    }

}

wrap_class: ListQuestion
class wrapper : T {
    mixin OverloadShim;
    alias Params[0] __pyd_p0;
    alias __pyd_p0.ctors __pyd_c0;
    this(ParameterTypeTuple!(__pyd_c0[0]) t) {
        super(t);
    }
    static if (is(typeof(new T))) {
        this() { super(); }
    }
    alias Params[1] __pyd_p1;
    ReturnType!(__pyd_p1.func_t) 
numItems(ParameterTypeTuple!(__pyd_p1.func_t) t
) {
        return __pyd_get_overload!("numItems", 
__pyd_p1.func_t).func("numItems",
 t);
    }
    alias Params[2] __pyd_p2;
    ReturnType!(__pyd_p2.func_t) 
getItem(ParameterTypeTuple!(__pyd_p2.func_t) t)
 {
        return __pyd_get_overload!("getItem", 
__pyd_p2.func_t).func("getItem", t
);
    }
    alias Params[3] __pyd_p3;
    ReturnType!(__pyd_p3.func_t) 
exclusive(ParameterTypeTuple!(__pyd_p3.func_t)
t) {
        return __pyd_get_overload!("exclusive", 
__pyd_p3.func_t).func("exclusive
", t);
    }
    alias Params[4] __pyd_p4;
    ReturnType!(__pyd_p4.get_t) items() {
        return __pyd_get_overload!("items", __pyd_p4.get_t).func("items");
    }
    ReturnType!(__pyd_p4.set_t) items(ParameterTypeTuple!(__pyd_p4.set_t) t) 
{
        return __pyd_get_overload!("items", __pyd_p4.set_t).func("items", 
t);
    }

}

class.def: numItems
class.def: getItem
class.def: exclusive
class.prop: items
wrap_class: NSD
class wrapper : T {
    mixin OverloadShim;
    alias Params[0] __pyd_p0;
    alias __pyd_p0.ctors __pyd_c0;
    this(ParameterTypeTuple!(__pyd_c0[0]) t) {
        super(t);
    }
    static if (is(typeof(new T))) {
        this() { super(); }
    }
    alias Params[1] __pyd_p1;
    ReturnType!(__pyd_p1.func_t) filter(ParameterTypeTuple!(__pyd_p1.func_t) 
t)
{
        return __pyd_get_overload!("filter", __pyd_p1.func_t).func("filter", 
t);

    }
    alias Params[2] __pyd_p2;
    ReturnType!(__pyd_p2.func_t) filter(ParameterTypeTuple!(__pyd_p2.func_t) 
t)
{
        return __pyd_get_overload!("filter", 
__pyd_p2.func_t).func("filterResps"
, t);
    }
    alias Params[3] __pyd_p3;
    ReturnType!(__pyd_p3.func_t) 
countOf(ParameterTypeTuple!(__pyd_p3.func_t) t)
 {
        return __pyd_get_overload!("countOf", 
__pyd_p3.func_t).func("countOf", t
);
    }
    alias Params[4] __pyd_p4;
    ReturnType!(__pyd_p4.func_t) 
countOf(ParameterTypeTuple!(__pyd_p4.func_t) t)
 {
        return __pyd_get_overload!("countOf", 
__pyd_p4.func_t).func("countOfResp
s", t);
    }
    alias Params[5] __pyd_p5;
    ReturnType!(__pyd_p5.func_t) 
getQuestion(ParameterTypeTuple!(__pyd_p5.func_t
) t) {
        return __pyd_get_overload!("getQuestion", 
__pyd_p5.func_t).func("getQues
tion", t);
    }
    alias Params[6] __pyd_p6;
    ReturnType!(__pyd_p6.func_t) 
getQuestionIds(ParameterTypeTuple!(__pyd_p6.fun
c_t) t) {
        return __pyd_get_overload!("getQuestionIds", 
__pyd_p6.func_t).func("getQ
uestionIds", t);
    }
    alias Params[7] __pyd_p7;
    ReturnType!(__pyd_p7.func_t) 
getRespondent(ParameterTypeTuple!(__pyd_p7.func
_t) t) {
        return __pyd_get_overload!("getRespondent", 
__pyd_p7.func_t).func("getRe
spondent", t);
    }
    alias Params[8] __pyd_p8;
    ReturnType!(__pyd_p8.func_t) 
numQuestions(ParameterTypeTuple!(__pyd_p8.func_
t) t) {
        return __pyd_get_overload!("numQuestions", 
__pyd_p8.func_t).func("numQue
stions", t);
    }
    alias Params[9] __pyd_p9;
    ReturnType!(__pyd_p9.func_t) 
respondents(ParameterTypeTuple!(__pyd_p9.func_t
) t) {
        return __pyd_get_overload!("respondents", 
__pyd_p9.func_t).func("respond
ents", t);
    }
    alias Params[10] __pyd_p10;
    ReturnType!(__pyd_p10.func_t) 
writeasc(ParameterTypeTuple!(__pyd_p10.func_t)
 t) {
        return __pyd_get_overload!("writeasc", 
__pyd_p10.func_t).func("writeasc"
, t);
    }
    alias Params[11] __pyd_p11;
    ReturnType!(__pyd_p11.func_t) 
writensd(ParameterTypeTuple!(__pyd_p11.func_t)
 t) {
        return __pyd_get_overload!("writensd", 
__pyd_p11.func_t).func("writensd"
, t);
    }
    alias Params[12] __pyd_p12;
    ReturnType!(__pyd_p12.func_t) 
writesps(ParameterTypeTuple!(__pyd_p12.func_t)
 t) {
        return __pyd_get_overload!("writesps", 
__pyd_p12.func_t).func("writesps"
, t);
    }
    alias Params[13] __pyd_p13;
    ReturnType!(__pyd_p13.func_t) 
writecsv(ParameterTypeTuple!(__pyd_p13.func_t)
 t) {
        return __pyd_get_overload!("writecsv", 
__pyd_p13.func_t).func("writecsv"
, t);
    }
    alias Params[14] __pyd_p14;
    ReturnType!(__pyd_p14.func_t) 
clear(ParameterTypeTuple!(__pyd_p14.func_t) t)
 {
        return __pyd_get_overload!("clear", __pyd_p14.func_t).func("clear", 
t);
    }
    alias Params[15] __pyd_p15;
    ReturnType!(__pyd_p15.get_t) questions() {
        return __pyd_get_overload!("questions", 
__pyd_p15.get_t).func("questions
");
    }
    ReturnType!(__pyd_p15.set_t) 
questions(ParameterTypeTuple!(__pyd_p15.set_t)
t) {
        return __pyd_get_overload!("questions", 
__pyd_p15.set_t).func("questions
", t);
    }

}

class.def: filter
class.def: filterResps
class.def: countOf
class.def: countOfResps
class.def: getQuestion
class.def: getQuestionIds
class.def: getRespondent
class.def: numQuestions
class.def: respondents
class.def: writeasc
class.def: writensd
class.def: writesps
class.def: writecsv
class.def: clear
class.prop: questions
Error: identifier 
_D3pyd12make_wrapper2257__T12make_wrapperTC3nsd3NSDTS3pyd10cla
ss_wrap18__T4InitTPFAaAaZvZ4InitTS3pyd10class_wrap120__T3DefS40_D3nsd3NSD6filter
MFAaZAC3nsd10RespondentVAaa6_66696c746572VAaa6_66696c746572TPFAaZAC3nsd10Respond
entVk1VAaa0_Z3DefTS3pyd10class_wrap149__T3DefS40_D3nsd3NSD6filterMFAaZAC3nsd10Re
spondentVAaa6_66696c746572VAaa11_66696c7465725265737073TPFAaAC3nsd10RespondentZA
C3nsd10RespondentVk1VAaa0_Z3DefTS3pyd10class_wrap91__T3DefS24_D3nsd3NSD7countOfM
FAaZdVAaa7_636f756e744f66VAaa7_636f756e744f66TPFAaZdVk1VAaa0_Z3DefTS3pyd10class_
wrap120__T3DefS24_D3nsd3NSD7countOfMFAaZdVAaa7_636f756e744f66VAaa12_636f756e744f
665265737073TPFAaAC3nsd10RespondentZdVk1VAaa0_Z3DefTS3pyd10class_wrap140__T3DefS
42_D3nsd3NSD11getQuestionMFAaZC3nsd8QuestionVAaa11_6765745175657374696f6eVAaa11_
6765745175657374696f6eTPFAaZC3nsd8QuestionVk1VAaa0_Z3DefTS3pyd10class_wrap129__T
3DefS32_D3nsd3NSD14getQuestionIdsMFZAAaVAaa14_6765745175657374696f6e496473VAaa14
_6765745175657374696f6e496473TPFZAAaVk0VAaa0_Z3DefTS3pyd10class_wrap154__T3DefS4
6_D3nsd3NSD13getRespondentMFkZC3nsd10RespondentVAaa13_676574526573706f6e64656e74
VAaa13_676574526573706f6e64656e74TPFkZC3nsd10RespondentVk1VAaa0_Z3DefTS3pyd10cla
ss_wrap115__T3DefS28_D3nsd3NSD12numQuestionsMFZkVAaa12_6e756d5175657374696f6e73V
Aaa12_6e756d5175657374696f6e73TPFZkVk0VAaa0_Z3DefTS3pyd10class_wrap144__T3DefS44
_D3nsd3NSD11respondentsMFZAC3nsd10RespondentVAaa11_726573706f6e64656e7473VAaa11_
726573706f6e64656e7473TPFZAC3nsd10RespondentVk0VAaa0_Z3DefTS3pyd10class_wrap132_
_T3DefS43_D3nsd3NSD8writeascMFAaAC3nsd10RespondentZvVAaa8_7772697465617363VAaa8_
7772697465617363TPFAaAC3nsd10RespondentZvVk1VAaa0_Z3DefTS3pyd10class_wrap96__T3D
efS25_D3nsd3NSD8writensdMFAaZvVAaa8_77726974656e7364VAaa8_77726974656e7364TPFAaZ
vVk1VAaa0_Z3DefTS3pyd10class_wrap136__T3DefS45_D3nsd3NSD8writespsMFAaAaAC3nsd10R
espondentZvVAaa8_7772697465737073VAaa8_7772697465737073TPFAaAaAC3nsd10Respondent
ZvVk2VAaa0_Z3DefTS3pyd10class_wrap96__T3DefS25_D3nsd3NSD8writecsvMFAaZvVAaa8_777
2697465637376VAaa8_7772697465637376TPFAaZvVk1VAaa0_Z3DefTS3pyd10class_wrap77__T3
DefS20_D3nsd3NSD5clearMFZvVAaa5_636c656172VAaa5_636c656172TPFZvVk0VAaa0_Z3DefTS3
pyd10class_wrap111__T8PropertyS38_D3nsd3NSD9questionsMFZAC3nsd8QuestionVAaa9_717
5657374696f6e73VAaa9_7175657374696f6e73Vb0VAaa0_Z8PropertyZ7wrapper5_ctorMFAaAaZ
C3pyd12make_wrapper2257__T12make_wrapperTC3nsd3NSDTS3pyd10class_wrap18__T4InitTP
FAaAaZvZ4InitTS3pyd10class_wrap120__T3DefS40_D3nsd3NSD6filterMFAaZAC3nsd10Respon
dentVAaa6_66696c746572VAaa6_66696c746572TPFAaZAC3nsd10RespondentVk1VAaa0_Z3DefTS
3pyd10class_wrap149__T3DefS40_D3nsd3NSD6filterMFAaZAC3nsd10RespondentVAaa6_66696
c746572VAaa11_66696c7465725265737073TPFAaAC3nsd10RespondentZAC3nsd10RespondentVk
1VAaa0_Z3DefTS3pyd10class_wrap91__T3DefS24_D3nsd3NSD7countOfMFAaZdVAaa7_636f756e
744f66VAaa7_636f756e744f66TPFAaZdVk1VAaa0_Z3DefTS3pyd10class_wrap120__T3DefS24_D
3nsd3NSD7countOfMFAaZdVAaa7_636f756e744f66VAaa12_636f756e744f665265737073TPFAaAC
3nsd10RespondentZdVk1VAaa0_Z3DefTS3pyd10class_wrap140__T3DefS42_D3nsd3NSD11getQu
estionMFAaZC3nsd8QuestionVAaa11_6765745175657374696f6eVAaa11_6765745175657374696
f6eTPFAaZC3nsd8QuestionVk1VAaa0_Z3DefTS3pyd10class_wrap129__T3DefS32_D3nsd3NSD14
getQuestionIdsMFZAAaVAaa14_6765745175657374696f6e496473VAaa14_676574517565737469
6f6e496473TPFZAAaVk0VAaa0_Z3DefTS3pyd10class_wrap154__T3DefS46_D3nsd3NSD13getRes
pondentMFkZC3nsd10RespondentVAaa13_676574526573706f6e64656e74VAaa13_676574526573
706f6e64656e74TPFkZC3nsd10RespondentVk1VAaa0_Z3DefTS3pyd10class_wrap115__T3DefS2
8_D3nsd3NSD12numQuestionsMFZkVAaa12_6e756d5175657374696f6e73VAaa12_6e756d5175657
374696f6e73TPFZkVk0VAaa0_Z3DefTS3pyd10class_wrap144__T3DefS44_D3nsd3NSD11respond
entsMFZAC3nsd10RespondentVAaa11_726573706f6e64656e7473VAaa11_726573706f6e64656e7
473TPFZAC3nsd10RespondentVk0VAaa0_Z3DefTS3pyd10class_wrap132__T3DefS43_D3nsd3NSD
8writeascMFAaAC3nsd10RespondentZvVAaa8_7772697465617363VAaa8_7772697465617363TPF
AaAC3nsd10RespondentZvVk1VAaa0_Z3DefTS3pyd10class_wrap96__T3DefS25_D3nsd3NSD8wri
tensdMFAaZvVAaa8_77726974656e7364VAaa8_77726974656e7364TPFAaZvVk1VAaa0_Z3DefTS3p
yd10class_wrap136__T3DefS45_D3nsd3NSD8writespsMFAaAaAC3nsd10RespondentZvVAaa8_77
72697465737073VAaa8_7772697465737073TPFAaAaAC3nsd10RespondentZvVk2VAaa0_Z3DefTS3
pyd10class_wrap96__T3DefS25_D3nsd3NSD8writecsvMFAaZvVAaa8_7772697465637376VAaa8_
7772697465637376TPFAaZvVk1VAaa0_Z3DefTS3pyd10class_wrap77__T3DefS20_D3nsd3NSD5cl
earMFZvVAaa5_636c656172VAaa5_636c656172TPFZvVk0VAaa0_Z3DefTS3pyd10class_wrap111_
_T8PropertyS38_D3nsd3NSD9questionsMFZAC3nsd8QuestionVAaa9_7175657374696f6e73VAaa
9_7175657374696f6e73Vb0VAaa0_Z8PropertyZ7wrapper is too long by 3690 
characters
Error: identifier 
_D3pyd12make_wrapper2257__T12make_wrapperTC3nsd3NSDTS3pyd10cla
ss_wrap18__T4InitTPFAaAaZvZ4InitTS3pyd10class_wrap120__T3DefS40_D3nsd3NSD6filter
MFAaZAC3nsd10RespondentVAaa6_66696c746572VAaa6_66696c746572TPFAaZAC3nsd10Respond
entVk1VAaa0_Z3DefTS3pyd10class_wrap149__T3DefS40_D3nsd3NSD6filterMFAaZAC3nsd10Re
spondentVAaa6_66696c746572VAaa11_66696c7465725265737073TPFAaAC3nsd10RespondentZA
C3nsd10RespondentVk1VAaa0_Z3DefTS3pyd10class_wrap91__T3DefS24_D3nsd3NSD7countOfM
FAaZdVAaa7_636f756e744f66VAaa7_636f756e744f66TPFAaZdVk1VAaa0_Z3DefTS3pyd10class_
wrap120__T3DefS24_D3nsd3NSD7countOfMFAaZdVAaa7_636f756e744f66VAaa12_636f756e744f
665265737073TPFAaAC3nsd10RespondentZdVk1VAaa0_Z3DefTS3pyd10class_wrap140__T3DefS
42_D3nsd3NSD11getQuestionMFAaZC3nsd8QuestionVAaa11_6765745175657374696f6eVAaa11_
6765745175657374696f6eTPFAaZC3nsd8QuestionVk1VAaa0_Z3DefTS3pyd10class_wrap129__T
3DefS32_D3nsd3NSD14getQuestionIdsMFZAAaVAaa14_6765745175657374696f6e496473VAaa14
_6765745175657374696f6e496473TPFZAAaVk0VAaa0_Z3DefTS3pyd10class_wrap154__T3DefS4
6_D3nsd3NSD13getRespondentMFkZC3nsd10RespondentVAaa13_676574526573706f6e64656e74
VAaa13_676574526573706f6e64656e74TPFkZC3nsd10RespondentVk1VAaa0_Z3DefTS3pyd10cla
ss_wrap115__T3DefS28_D3nsd3NSD12numQuestionsMFZkVAaa12_6e756d5175657374696f6e73V
Aaa12_6e756d5175657374696f6e73TPFZkVk0VAaa0_Z3DefTS3pyd10class_wrap144__T3DefS44
_D3nsd3NSD11respondentsMFZAC3nsd10RespondentVAaa11_726573706f6e64656e7473VAaa11_
726573706f6e64656e7473TPFZAC3nsd10RespondentVk0VAaa0_Z3DefTS3pyd10class_wrap132_
_T3DefS43_D3nsd3NSD8writeascMFAaAC3nsd10RespondentZvVAaa8_7772697465617363VAaa8_
7772697465617363TPFAaAC3nsd10RespondentZvVk1VAaa0_Z3DefTS3pyd10class_wrap96__T3D
efS25_D3nsd3NSD8writensdMFAaZvVAaa8_77726974656e7364VAaa8_77726974656e7364TPFAaZ
vVk1VAaa0_Z3DefTS3pyd10class_wrap136__T3DefS45_D3nsd3NSD8writespsMFAaAaAC3nsd10R
espondentZvVAaa8_7772697465737073VAaa8_7772697465737073TPFAaAaAC3nsd10Respondent
ZvVk2VAaa0_Z3DefTS3pyd10class_wrap96__T3DefS25_D3nsd3NSD8writecsvMFAaZvVAaa8_777
2697465637376VAaa8_7772697465637376TPFAaZvVk1VAaa0_Z3DefTS3pyd10class_wrap77__T3
DefS20_D3nsd3NSD5clearMFZvVAaa5_636c656172VAaa5_636c656172TPFZvVk0VAaa0_Z3DefTS3
pyd10class_wrap111__T8PropertyS38_D3nsd3NSD9questionsMFZAC3nsd8QuestionVAaa9_717
5657374696f6e73VAaa9_7175657374696f6e73Vb0VAaa0_Z8PropertyZ7wrapper5_ctorMFZC3py
d12make_wrapper2257__T12make_wrapperTC3nsd3NSDTS3pyd10class_wrap18__T4InitTPFAaA
aZvZ4InitTS3pyd10class_wrap120__T3DefS40_D3nsd3NSD6filterMFAaZAC3nsd10Respondent
VAaa6_66696c746572VAaa6_66696c746572TPFAaZAC3nsd10RespondentVk1VAaa0_Z3DefTS3pyd
10class_wrap149__T3DefS40_D3nsd3NSD6filterMFAaZAC3nsd10RespondentVAaa6_66696c746
572VAaa11_66696c7465725265737073TPFAaAC3nsd10RespondentZAC3nsd10RespondentVk1VAa
a0_Z3DefTS3pyd10class_wrap91__T3DefS24_D3nsd3NSD7countOfMFAaZdVAaa7_636f756e744f
66VAaa7_636f756e744f66TPFAaZdVk1VAaa0_Z3DefTS3pyd10class_wrap120__T3DefS24_D3nsd
3NSD7countOfMFAaZdVAaa7_636f756e744f66VAaa12_636f756e744f665265737073TPFAaAC3nsd
10RespondentZdVk1VAaa0_Z3DefTS3pyd10class_wrap140__T3DefS42_D3nsd3NSD11getQuesti
onMFAaZC3nsd8QuestionVAaa11_6765745175657374696f6eVAaa11_6765745175657374696f6eT
PFAaZC3nsd8QuestionVk1VAaa0_Z3DefTS3pyd10class_wrap129__T3DefS32_D3nsd3NSD14getQ
uestionIdsMFZAAaVAaa14_6765745175657374696f6e496473VAaa14_6765745175657374696f6e
496473TPFZAAaVk0VAaa0_Z3DefTS3pyd10class_wrap154__T3DefS46_D3nsd3NSD13getRespond
entMFkZC3nsd10RespondentVAaa13_676574526573706f6e64656e74VAaa13_676574526573706f
6e64656e74TPFkZC3nsd10RespondentVk1VAaa0_Z3DefTS3pyd10class_wrap115__T3DefS28_D3
nsd3NSD12numQuestionsMFZkVAaa12_6e756d5175657374696f6e73VAaa12_6e756d51756573746
96f6e73TPFZkVk0VAaa0_Z3DefTS3pyd10class_wrap144__T3DefS44_D3nsd3NSD11respondents
MFZAC3nsd10RespondentVAaa11_726573706f6e64656e7473VAaa11_726573706f6e64656e7473T
PFZAC3nsd10RespondentVk0VAaa0_Z3DefTS3pyd10class_wrap132__T3DefS43_D3nsd3NSD8wri
teascMFAaAC3nsd10RespondentZvVAaa8_7772697465617363VAaa8_7772697465617363TPFAaAC
3nsd10RespondentZvVk1VAaa0_Z3DefTS3pyd10class_wrap96__T3DefS25_D3nsd3NSD8writens
dMFAaZvVAaa8_77726974656e7364VAaa8_77726974656e7364TPFAaZvVk1VAaa0_Z3DefTS3pyd10
class_wrap136__T3DefS45_D3nsd3NSD8writespsMFAaAaAC3nsd10RespondentZvVAaa8_777269
7465737073VAaa8_7772697465737073TPFAaAaAC3nsd10RespondentZvVk2VAaa0_Z3DefTS3pyd1
0class_wrap96__T3DefS25_D3nsd3NSD8writecsvMFAaZvVAaa8_7772697465637376VAaa8_7772
697465637376TPFAaZvVk1VAaa0_Z3DefTS3pyd10class_wrap77__T3DefS20_D3nsd3NSD5clearM
FZvVAaa5_636c656172VAaa5_636c656172TPFZvVk0VAaa0_Z3DefTS3pyd10class_wrap111__T8P
ropertyS38_D3nsd3NSD9questionsMFZAC3nsd8QuestionVAaa9_7175657374696f6e73VAaa9_71
75657374696f6e73Vb0VAaa0_Z8PropertyZ7wrapper is too long by 3686 characters
error: command 'c:\d\dmd\bin\dmd.exe' failed with exit status 1 
Jul 06 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Simen Haugen wrote:
 I cannot wrap all the functions in my class without getting the compile 
 error:
 Error: identifier _D3pyd9func_wrap1172__T22app (...) is too long by x 
 characters.
 
 And its several thousand characters too long...
 

  wrap_class!(
   NSD
   , Init!(void function(char[], char[]))
   , Def!(NSD.filter, "filter", Respondent[] function(char[]))
   , Def!(NSD.filter, "filterResps", Respondent[] function(char[], 
 Respondent[]))
   , Def!(NSD.countOf, "countOf", double function(char[]))
   , Def!(NSD.countOf, "countOfResps", double function(char[], Respondent[]))
   , Def!(NSD.getQuestion)
   , Def!(NSD.getQuestionIds)
   , Def!(NSD.getRespondent)
   , Def!(NSD.numQuestions)
   , Def!(NSD.respondents)
   , Def!(NSD.writeasc)
   , Def!(NSD.writensd)
   , Def!(NSD.writesps)
   , Def!(NSD.writecsv)
   , Def!(NSD.clear)
   , Property!(NSD.questions)
  );
 }

Curses. This is one of those things I knew would be a problem, but always just put off doing something about. wrap_class is, of course, a template. It looks something like this: void wrap_class(T, Params...)(); The problem with templates is that every template instantiated results in a mangled identifier being created in the object file. Identifiers have a maximum length, so when a big long one is created like this, it runs headlong into that maximum length. That variadic Params parameter is the perfect place to run into it, since each of the things you pass to it are fairly long in themselves. I always knew this would be an issue, but I never tried explicitly testing for the maximum length. Pyd's API wasn't always like this. It used to look like this: wrapped_class!(Foo) f; f.def!(Foo.bar); f.def!(Foo.baz); finalize_class(f); This neatly side-steps any problems with maxiumum symbol lengths. However, by having all of the arguments in a tuple like the current API does, they are all available at compile-time, meaning I can use them to generate a subclass of T, and do some very fancy stuff with polymorphism. Barring any changes to the language (such as macros or the compile-time reflection mechanisms I outlined in an earlier post), I basically one option for fixing this, which is to bring back the old API. This is not an attractive option, since then Pyd would basically have two APIs side-by-side. (If I ditch the current API, I lose the polymorphism stuff.) This means that, when wrapping a big class, you'll either be able to have all of its methods, or the fancy polymorphism stuff, but not both. This annoys me, deeply. In a perfect world, I'd have both of the following: * Templates which do not generate symbols, if those symbols aren't actually needed. (Or some way for the user to specify a template's symbol is not needed.) * The compile-time reflection stuff I've been talking about. With that, you'd just need to say: wrap_class!(Foo); (Although cases such as overloaded functions would still have to be covered somehow.) That said, I will be looking into whether I can shorten those symbol names. I'm going to be banging my head against this for the next few days, I can tell. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jul 06 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Kirk McDonald wrote:
 That said, I will be looking into whether I can shorten those symbol 
 names. I'm going to be banging my head against this for the next few 
 days, I can tell.

This should only be a problem under Windows, which uses OMF which has a length limit. ELF under Linux has no limit.
Jul 06 2007
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Walter Bright schrieb am 2007-07-06:
 Kirk McDonald wrote:
 That said, I will be looking into whether I can shorten those symbol 
 names. I'm going to be banging my head against this for the next few 
 days, I can tell.

This should only be a problem under Windows, which uses OMF which has a length limit. ELF under Linux has no limit.

Isn't there any way to sidestep the issue - e.g. something like the long file names on DOS partitions? Thomas -----BEGIN PGP SIGNATURE----- iQIVAwUBRpZfA7ZlboUnBhRKAQqFWQ//bcb24jmLs9PsCCA8maQRrbc2agGJmcAU 2u8+16479WYMy7iBQC/zd8B6OH0VUS8veCA6QXYk7h+iintLEI1hICClwVw2eEXy UyXxc+zbTQQhvbS+r/8tmwTyYNqHZMcYV5LPYLVstRR5rP8FHG7bdOmj4/kdCa6u 13OWwffXI22pV3Yy0CWWpckDE8OfErC6DyokLmXFzcwOaWQdNZB0+Bm0SgiKK2Aq 2V0FEZTStSmjzTEaL69nh63td13kX//2EX68PVRGrXbKj+MF8FRV7tAVp9tRVGRF zoUZGQXvrOf/tl18tf1Ws1NysXC2cPPnOw/GM+ijwhTIW/6fpMF51UUnAEZPufO0 q3FjXLR/nGWW6oseBalr1GoZogBudu+3uzjHZgYTYo+qIlvqFhZgQ+wZOAjGh+uc YpM/xjNts8XZrTvGyoLqJyhrRDGj92Z5uhSeAfrs/YdKNiUtXM4VGPke+ZmOJNrF JMwEUSZtP5AlxOl1DkMfTgB53jexsmCPNzyv34jcJbMDzrci947Hv0RQ4hxwEB0G i+H7mSM9UMch0r8gDf+idTAoC81rm9wH0CKsmN7TBCLj7StX8cq8HYPATAWUIM6Y cTcSXYJWrr613QxZ4/pYbVqF52halGn7mH9A/cWVGzEABWZZua8uwBDdlKWME79b 3XRUmpCYKso= =cOOE -----END PGP SIGNATURE-----
Jul 12 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to Thomas,

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA512
 
 Walter Bright schrieb am 2007-07-06:
 
 Kirk McDonald wrote:
 
 That said, I will be looking into whether I can shorten those symbol
 names. I'm going to be banging my head against this for the next few
 days, I can tell.
 

a length limit. ELF under Linux has no limit.

long file names on DOS partitions? Thomas

how about the PGP SIGNATURE of the name (or MD5, or whatever)
 -----BEGIN PGP SIGNATURE-----
 iQIVAwUBRpZfA7ZlboUnBhRKAQqFWQ//bcb24jmLs9PsCCA8maQRrbc2agGJmcAU
 2u8+16479WYMy7iBQC/zd8B6OH0VUS8veCA6QXYk7h+iintLEI1hICClwVw2eEXy
 UyXxc+zbTQQhvbS+r/8tmwTyYNqHZMcYV5LPYLVstRR5rP8FHG7bdOmj4/kdCa6u
 13OWwffXI22pV3Yy0CWWpckDE8OfErC6DyokLmXFzcwOaWQdNZB0+Bm0SgiKK2Aq
 2V0FEZTStSmjzTEaL69nh63td13kX//2EX68PVRGrXbKj+MF8FRV7tAVp9tRVGRF
 zoUZGQXvrOf/tl18tf1Ws1NysXC2cPPnOw/GM+ijwhTIW/6fpMF51UUnAEZPufO0
 q3FjXLR/nGWW6oseBalr1GoZogBudu+3uzjHZgYTYo+qIlvqFhZgQ+wZOAjGh+uc
 YpM/xjNts8XZrTvGyoLqJyhrRDGj92Z5uhSeAfrs/YdKNiUtXM4VGPke+ZmOJNrF
 JMwEUSZtP5AlxOl1DkMfTgB53jexsmCPNzyv34jcJbMDzrci947Hv0RQ4hxwEB0G
 i+H7mSM9UMch0r8gDf+idTAoC81rm9wH0CKsmN7TBCLj7StX8cq8HYPATAWUIM6Y
 cTcSXYJWrr613QxZ4/pYbVqF52halGn7mH9A/cWVGzEABWZZua8uwBDdlKWME79b
 3XRUmpCYKso=
 =cOOE


Jul 12 2007
prev sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Thomas Kuehne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA512
 
 Walter Bright schrieb am 2007-07-06:
 Kirk McDonald wrote:
 That said, I will be looking into whether I can shorten those symbol 
 names. I'm going to be banging my head against this for the next few 
 days, I can tell.

length limit. ELF under Linux has no limit.

Isn't there any way to sidestep the issue - e.g. something like the long file names on DOS partitions?

While I don't claim to speak for Walter, I have hacked around with OMF enough to answer this one. In general, the problem cannot be fixed given OMF's design and limitations. You'd have to extend OMF in some fashion, along with the linker, or abandon OMF in favor of a better object file format. The problem is that the overly long template symbols are needed to allow the linker to do it's job: expunge redundant symbol definitions while locating the correct match for a dependency. As the properties of a template instance is defined by its arguments, you really can't separate the two. Combined, you get both run-time and link-time behaviors that depend heavily on the naming spec staying right where it is. Change the spec, and you allow for false matches that can really screw things up. My $0.02 on a possible solution: Compression *might* be of some help here, like some kind of huffman coding that really crunches the symbol name down (D could probably get away with something resembling "UTF-4"). But it will only increase the maximum symbol length by a theoretical amount, so you'd still have problems, just with deeper nestings of templates than before. Plus, any tweaks made to the compression behavior (including bugfixes) will result in a change to the naming spec (bad). CTFE and mixins seem to be a decent workaround, but I know they're not always feasible. I've had some success in the past blending them with templates, in order to keep symbol sizes within limits. Push comes to shove, you can always go full-on ELF and use the GNU tool chain on Windows and not change a single line of code (barring win32 stuff of course). -- - EricAnderton at yahoo
Jul 12 2007
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Pragma,

 The problem is that the overly long template symbols are needed to
 allow the linker to do it's job: expunge redundant symbol definitions
 while locating the correct match for a dependency.  As the properties
 of a template instance is defined by its arguments, you really can't
 separate the two.  Combined, you get both run-time and link-time
 behaviors that depend heavily on the naming spec staying right where
 it is.  Change the spec, and you allow for false matches that can
 really screw things up.

What is the chance of a hash coalition if all (and only) over length symbols are named by a hash code that is as long as /will/ fit? Alternately (and this will only work with single run compilation or with external meta data) name everything with GUIDs. Unless I am mistaken, really the only thing that is needed is that some unique name is assigned to each instance in a way that will let other stuff find the same name from the same input.
Jul 12 2007
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
BCS wrote:
 Reply to Pragma,
 
 The problem is that the overly long template symbols are needed to
 allow the linker to do it's job: expunge redundant symbol definitions
 while locating the correct match for a dependency.  As the properties
 of a template instance is defined by its arguments, you really can't
 separate the two.  Combined, you get both run-time and link-time
 behaviors that depend heavily on the naming spec staying right where
 it is.  Change the spec, and you allow for false matches that can
 really screw things up.

What is the chance of a hash coalition if all (and only) over length symbols are named by a hash code that is as long as /will/ fit? Alternately (and this will only work with single run compilation or with external meta data) name everything with GUIDs. Unless I am mistaken, really the only thing that is needed is that some unique name is assigned to each instance in a way that will let other stuff find the same name from the same input.

This sounds about right. However, I predict it would be useful if the unique name were generated in some way which is reversible, or at least partly reversible. (As opposed to an MD5 hash; we hardly need this to be secure, after all. Not that MD5 is all that secure, these days...) It may aid the debugging of obscure linker errors. Either way, this sounds like a magic bullet for these problems with Pyd, and any other library which abuses tuples as egregiously as it does. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jul 12 2007
parent BCS <ao pathlink.com> writes:
Reply to Kirk,

 BCS wrote:
 
 Reply to Pragma,
 
 The problem is that the overly long template symbols are needed to
 allow the linker to do it's job: expunge redundant symbol
 definitions while locating the correct match for a dependency.  As
 the properties of a template instance is defined by its arguments,
 you really can't separate the two.  Combined, you get both run-time
 and link-time behaviors that depend heavily on the naming spec
 staying right where it is.  Change the spec, and you allow for false
 matches that can really screw things up.
 

symbols are named by a hash code that is as long as /will/ fit? Alternately (and this will only work with single run compilation or with external meta data) name everything with GUIDs. Unless I am mistaken, really the only thing that is needed is that some unique name is assigned to each instance in a way that will let other stuff find the same name from the same input.

unique name were generated in some way which is reversible, or at least partly reversible. (As opposed to an MD5 hash; we hardly need this to be secure, after all. Not that MD5 is all that secure, these days...) It may aid the debugging of obscure linker errors. Either way, this sounds like a magic bullet for these problems with Pyd, and any other library which abuses tuples as egregiously as it does.

It's not totaly automatic but you could have DMD dump a *.smap file that lists the used name followed by the real name for anyything that gets trucated. ... LOts_Of_GoBBILyyy_Gouc_Th4t_Is_M463_FrOm ==>> This_Long_Symbol_Name_That_Dosnt_Actual_Fit_But_Can_Actually_Be_Read_And_Understood ...
Jul 12 2007
prev sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
BCS wrote:
 Reply to Pragma,
 
 The problem is that the overly long template symbols are needed to
 allow the linker to do it's job: expunge redundant symbol definitions
 while locating the correct match for a dependency.  As the properties
 of a template instance is defined by its arguments, you really can't
 separate the two.  Combined, you get both run-time and link-time
 behaviors that depend heavily on the naming spec staying right where
 it is.  Change the spec, and you allow for false matches that can
 really screw things up.

What is the chance of a hash coalition if all (and only) over length symbols are named by a hash code that is as long as /will/ fit? Alternately (and this will only work with single run compilation or with external meta data) name everything with GUIDs. Unless I am mistaken, really the only thing that is needed is that some unique name is assigned to each instance in a way that will let other stuff find the same name from the same input.

Yep, that's the gist of it. The problem you run into with hash codes (and GUIDs generated from a given source) is that they're not unique, so collisions are possible, even if they're incredibly unlikely; linking against a library could theoretically fail *without any recourse* if you have such a collision. Also, they need to be reversible, such that a given hash will resolve to exactly one D signature. -- - EricAnderton at yahoo
Jul 13 2007
parent reply Steve Teale <steve.teale britseyeview.com> writes:
Pragma Wrote:

 BCS wrote:
 Reply to Pragma,
 
 The problem is that the overly long template symbols are needed to
 allow the linker to do it's job: expunge redundant symbol definitions
 while locating the correct match for a dependency.  As the properties
 of a template instance is defined by its arguments, you really can't
 separate the two.  Combined, you get both run-time and link-time
 behaviors that depend heavily on the naming spec staying right where
 it is.  Change the spec, and you allow for false matches that can
 really screw things up.

What is the chance of a hash coalition if all (and only) over length symbols are named by a hash code that is as long as /will/ fit? Alternately (and this will only work with single run compilation or with external meta data) name everything with GUIDs. Unless I am mistaken, really the only thing that is needed is that some unique name is assigned to each instance in a way that will let other stuff find the same name from the same input.

Yep, that's the gist of it. The problem you run into with hash codes (and GUIDs generated from a given source) is that they're not unique, so collisions are possible, even if they're incredibly unlikely; linking against a library could theoretically fail *without any recourse* if you have such a collision. Also, they need to be reversible, such that a given hash will resolve to exactly one D signature. -- - EricAnderton at yahoo

Off topic, but I emailed you about DDL, DSP etc - did you get it?
Jul 13 2007
parent Pragma <ericanderton yahoo.removeme.com> writes:
Steve Teale wrote:
 Pragma Wrote:
 
 BCS wrote:
 Reply to Pragma,

 The problem is that the overly long template symbols are needed to
 allow the linker to do it's job: expunge redundant symbol definitions
 while locating the correct match for a dependency.  As the properties
 of a template instance is defined by its arguments, you really can't
 separate the two.  Combined, you get both run-time and link-time
 behaviors that depend heavily on the naming spec staying right where
 it is.  Change the spec, and you allow for false matches that can
 really screw things up.

symbols are named by a hash code that is as long as /will/ fit? Alternately (and this will only work with single run compilation or with external meta data) name everything with GUIDs. Unless I am mistaken, really the only thing that is needed is that some unique name is assigned to each instance in a way that will let other stuff find the same name from the same input.

The problem you run into with hash codes (and GUIDs generated from a given source) is that they're not unique, so collisions are possible, even if they're incredibly unlikely; linking against a library could theoretically fail *without any recourse* if you have such a collision. Also, they need to be reversible, such that a given hash will resolve to exactly one D signature. -- - EricAnderton at yahoo

Off topic, but I emailed you about DDL, DSP etc - did you get it?

Yes as a matter of fact I did, but only just now. As some other folks around here can tell you, I sometimes get a little behind on my mail queue. :) -- - EricAnderton at yahoo
Jul 13 2007
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Pragma wrote:
 Compression *might* be of some help here, like some kind of huffman 
 coding that really crunches the symbol name down (D could probably get 
 away with something resembling "UTF-4").

Compression is already being used. The Pyd stuff is exceeding even that. The main difficulty with hashing is that the names cannot be demangled.
Jul 12 2007
prev sibling parent reply BCS <BCS pathlink.com> writes:
Kirk McDonald wrote:
 Simen Haugen wrote:
 
 I cannot wrap all the functions in my class without getting the 
 compile error:
 Error: identifier _D3pyd9func_wrap1172__T22app (...) is too long by x 
 characters.

 And its several thousand characters too long...

  wrap_class!(
   NSD
   , Init!(void function(char[], char[]))
   , Def!(NSD.filter, "filter", Respondent[] function(char[]))
   , Def!(NSD.filter, "filterResps", Respondent[] function(char[], 
 Respondent[]))
   , Def!(NSD.countOf, "countOf", double function(char[]))
   , Def!(NSD.countOf, "countOfResps", double function(char[], 
 Respondent[]))
   , Def!(NSD.getQuestion)
   , Def!(NSD.getQuestionIds)
   , Def!(NSD.getRespondent)
   , Def!(NSD.numQuestions)
   , Def!(NSD.respondents)
   , Def!(NSD.writeasc)
   , Def!(NSD.writensd)
   , Def!(NSD.writesps)
   , Def!(NSD.writecsv)
   , Def!(NSD.clear)
   , Property!(NSD.questions)
  );
 }

[snip] Curses. This is one of those things I knew would be a problem, but always just put off doing something about. wrap_class is, of course, a template. It looks something like this: void wrap_class(T, Params...)(); The problem with templates is that every template instantiated results in a mangled identifier being created in the object file. Identifiers have a maximum length, so when a big long one is created like this, it runs headlong into that maximum length. That variadic Params parameter is the perfect place to run into it, since each of the things you pass to it are fairly long in themselves. I always knew this would be an issue, but I never tried explicitly testing for the maximum length. Pyd's API wasn't always like this. It used to look like this: wrapped_class!(Foo) f; f.def!(Foo.bar); f.def!(Foo.baz); finalize_class(f); This neatly side-steps any problems with maxiumum symbol lengths. However, by having all of the arguments in a tuple like the current API does, they are all available at compile-time, meaning I can use them to generate a subclass of T, and do some very fancy stuff with polymorphism. Barring any changes to the language (such as macros or the compile-time reflection mechanisms I outlined in an earlier post), I basically one option for fixing this, which is to bring back the old API. This is not an attractive option, since then Pyd would basically have two APIs side-by-side. (If I ditch the current API, I lose the polymorphism stuff.) This means that, when wrapping a big class, you'll either be able to have all of its methods, or the fancy polymorphism stuff, but not both. This annoys me, deeply. In a perfect world, I'd have both of the following: * Templates which do not generate symbols, if those symbols aren't actually needed. (Or some way for the user to specify a template's symbol is not needed.) * The compile-time reflection stuff I've been talking about. With that, you'd just need to say: wrap_class!(Foo); (Although cases such as overloaded functions would still have to be covered somehow.) That said, I will be looking into whether I can shorten those symbol names. I'm going to be banging my head against this for the next few days, I can tell.

it seems that a mixed in template ( mixin foo!(lots.of.stuff) ) only generates symbols for the stuff on the inside. These however have access to the stuff in the outer templates args list. My dparse.d template uses this to side step the symbol length issue with long strings as arguments. p.s. I haven't actually tested this in detail so I may be looking at something else and be totally wrong.
Jul 06 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
BCS wrote:
 it seems that a mixed in template ( mixin foo!(lots.of.stuff) ) only 
 generates symbols for the stuff on the inside. These however have access 
 to the stuff in the outer templates args list. My dparse.d template uses 
 this to side step the symbol length issue with long strings as arguments.
 
 p.s. I haven't actually tested this in detail so I may be looking at 
 something else and be totally wrong.

Now /that/ is a useful piece of information. If that big ol' tuple is never actually used to instantiate a template, things don't blow up. With a bit of refactoring, I've convinced the following to work: // note the leading underscore mixin _wrap_class!( Foo, Def!(Foo.bar), // etc ) F; extern(C) void PydMain() { module_init(); F.func(); // calls wrap_class } I'll be committing these changes to svn as soon as I verify that my changes didn't break other things horribly. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jul 06 2007
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Kirk McDonald" <kirklin.mcdonald gmail.com> wrote in message 
news:f6meq5$2jm0$1 digitalmars.com...
 Now /that/ is a useful piece of information. If that big ol' tuple is 
 never actually used to instantiate a template, things don't blow up.

 With a bit of refactoring, I've convinced the following to work:

 // note the leading underscore
 mixin _wrap_class!(
     Foo,
     Def!(Foo.bar),
     // etc
 ) F;

 extern(C) void PydMain() {
     module_init();
     F.func(); // calls wrap_class
 }

Very interesting. We had this conversation just the other day, didn't we? ;) Glad that there's a (seemingly) simple solution.
Jul 06 2007
prev sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Kirk McDonald wrote:
 I'll be committing these changes to svn as soon as I verify that my 
 changes didn't break other things horribly.
 

Revision 118 adds a series of changes which can dramatically shorten the length of template instance identifiers. The problem is far from solved, but these changes might help. To get the full effect of these changes, you may have to move around the class wrapping code a little. I haven't documented this semi-new API yet, but consult the testdll example. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jul 10 2007
parent reply "Simen Haugen" <simen norstat.no> writes:
To use it, you create a mixin of _wrap_class outside of the main function, 
and initialize it after module_init() as before?
Thats what I tried, but then I get a message about "identifier PyObject not 
defined" in make_wrapper.d line 91.

I only tried this on my large class, the other are still using 
wrap_class!(...)


"Kirk McDonald" <kirklin.mcdonald gmail.com> wrote in message 
news:f70m16$1cek$1 digitalmars.com...
 Kirk McDonald wrote:
 I'll be committing these changes to svn as soon as I verify that my 
 changes didn't break other things horribly.

Revision 118 adds a series of changes which can dramatically shorten the length of template instance identifiers. The problem is far from solved, but these changes might help. To get the full effect of these changes, you may have to move around the class wrapping code a little. I haven't documented this semi-new API yet, but consult the testdll example. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org

Jul 12 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Simen Haugen wrote:
 To use it, you create a mixin of _wrap_class outside of the main function, 
 and initialize it after module_init() as before?
 Thats what I tried, but then I get a message about "identifier PyObject not 
 defined" in make_wrapper.d line 91.
 
 I only tried this on my large class, the other are still using 
 wrap_class!(...)
 

Bah, the devil is in the details... For now, add import python; to the top of your module. That should fix it for now. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jul 12 2007
parent reply "Simen Haugen" <simen norstat.no> writes:
I'm now trying rev 118 and dmd 1.018.

If I use the ordinary wrap_class I get the "identifier too long" error.

If I use mixin _wrap_class!(...) outside of PydMain, I get an error when 
wrapping the first class.
The error is different based on what class I try to wrap first. With this 
class:
class NSDError : Error {
    this() {
        super("UNKNOWN");
    }

    this(char[] msg) {
        super(msg);
    }
}

I get:
pynsd.d(40): Error: wrap_class!(NSDError,Init!(void(*)(char[] filename)) ) 
has no effect

Notice that it has char[] filename here, but char[] msg in the class


"Kirk McDonald" <kirklin.mcdonald gmail.com> wrote in message 
news:f75i9t$jt3$1 digitalmars.com...
 Simen Haugen wrote:
 To use it, you create a mixin of _wrap_class outside of the main 
 function, and initialize it after module_init() as before?
 Thats what I tried, but then I get a message about "identifier PyObject 
 not defined" in make_wrapper.d line 91.

 I only tried this on my large class, the other are still using 
 wrap_class!(...)

Bah, the devil is in the details... For now, add import python; to the top of your module. That should fix it for now. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org

Jul 13 2007
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Simen Haugen wrote:
 I'm now trying rev 118 and dmd 1.018.
 
 If I use the ordinary wrap_class I get the "identifier too long" error.
 
 If I use mixin _wrap_class!(...) outside of PydMain, I get an error when 
 wrapping the first class.
 The error is different based on what class I try to wrap first. With this 
 class:
 class NSDError : Error {
     this() {
         super("UNKNOWN");
     }
 
     this(char[] msg) {
         super(msg);
     }
 }
 
 I get:
 pynsd.d(40): Error: wrap_class!(NSDError,Init!(void(*)(char[] filename)) ) 
 has no effect
 

Can you post your code? (Or, better, a minimum test case?) It should look something like: mixin _wrap_class!( Foo, Init!(void function(char[])) ) A; // <-- some identifier extern(C) void PydMain() { module_init(); A.wrap_class(); // <-- that identifier } I have no idea where "filename" came from. :-) -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jul 13 2007