digitalmars.D - Pyd: Wrapping too many functions in a class gives a compiler error
- Simen Haugen (635/635) Jul 06 2007 I cannot wrap all the functions in my class without getting the compile
- Kirk McDonald (49/77) Jul 06 2007 [snip]
- Walter Bright (3/6) Jul 06 2007 This should only be a problem under Windows, which uses OMF which has a
- Thomas Kuehne (21/27) Jul 12 2007 -----BEGIN PGP SIGNED MESSAGE-----
- BCS (2/35) Jul 12 2007
- Pragma (20/34) Jul 12 2007 While I don't claim to speak for Walter, I have hacked around with OMF e...
- BCS (8/16) Jul 12 2007 What is the chance of a hash coalition if all (and only) over length sym...
- Kirk McDonald (13/35) Jul 12 2007 This sounds about right. However, I predict it would be useful if the
- BCS (6/39) Jul 12 2007 It's not totaly automatic but you could have DMD dump a *.smap file that...
- Pragma (8/28) Jul 13 2007 Yep, that's the gist of it.
- Steve Teale (2/34) Jul 13 2007 Off topic, but I emailed you about DDL, DSP etc - did you get it?
- Pragma (5/40) Jul 13 2007 Yes as a matter of fact I did, but only just now. As some other folks a...
- Walter Bright (3/6) Jul 12 2007 Compression is already being used. The Pyd stuff is exceeding even that.
- BCS (7/100) Jul 06 2007 it seems that a mixed in template ( mixin foo!(lots.of.stuff) ) only
- Kirk McDonald (21/28) Jul 06 2007 Now /that/ is a useful piece of information. If that big ol' tuple is
- Jarrett Billingsley (4/17) Jul 06 2007 Very interesting. We had this conversation just the other day, didn't w...
- Kirk McDonald (11/14) Jul 10 2007 Revision 118 adds a series of changes which can dramatically shorten the...
- Simen Haugen (8/22) Jul 12 2007 To use it, you create a mixin of _wrap_class outside of the main functio...
- Kirk McDonald (9/17) Jul 12 2007 Bah, the devil is in the details... For now, add
- Simen Haugen (20/37) Jul 13 2007 I'm now trying rev 118 and dmd 1.018.
- Kirk McDonald (17/39) Jul 13 2007 Can you post your code? (Or, better, a minimum test case?) It should
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
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...[snip]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. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jul 06 2007
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Walter Bright schrieb am 2007-07-06:Kirk McDonald wrote: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-----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 12 2007
Reply to Thomas,-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Walter Bright schrieb am 2007-07-06:how about the PGP SIGNATURE of the name (or MD5, or whatever)Kirk McDonald wrote:Isn't there any way to sidestep the issue - e.g. something like the long file names on DOS partitions? ThomasThat 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.-----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
Thomas Kuehne wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Walter Bright schrieb am 2007-07-06: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 yahooKirk McDonald wrote:Isn't there any way to sidestep the issue - e.g. something like the long file names on DOS partitions?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 12 2007
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
BCS wrote:Reply to Pragma,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.orgThe 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
Reply to Kirk,BCS wrote: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 ...Reply to Pragma,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.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
BCS wrote:Reply to Pragma,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 yahooThe 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 13 2007
Pragma Wrote:BCS wrote:Off topic, but I emailed you about DDL, DSP etc - did you get it?Reply to Pragma,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 yahooThe 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 13 2007
Steve Teale wrote:Pragma Wrote: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 yahooBCS wrote:Off topic, but I emailed you about DDL, DSP etc - did you get it?Reply to Pragma,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 yahooThe 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 13 2007
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
Kirk McDonald wrote:Simen Haugen 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.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...[snip]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.
Jul 06 2007
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
"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
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
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
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
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
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 effectCan 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