wxlua-users — wxLua list for users and developers

[wxlua-users] wx2lua & Unicode was Re: Problem in using Turkish in wxLua scripts

[John L. <jla...@gm...>]

T24gMTIvNi8wNiwgSm9obiBMYWJlbnNraSA8amxhYmVuc2tpQGdtYWlsLmNvbT4gd3JvdGU6Cj4g
T24gMTIvNi8wNiwgSGFra2kgRG9ndXNhbiA8ZG9ndXNhbmhAdHIubmV0PiB3cm90ZToKPiA+IEpv
aG4gTGFiZW5za2kgd3JvdGU6Cj4gPiA+IE9uIDEyLzUvMDYsIEhha2tpIERvZ3VzYW4gPGRvZ3Vz
YW5oQHRyLm5ldD4gd3JvdGU6Cj4gPiA+PiAoTWluZ3csIHd4THVhIGN2cywgd3gyLjcuMi93eDIu
OCBBTlNJIGFuZCBVbmljb2RlLCBXaW5YUCBUdXJraXNoKQo+ID4gPj4KPiA+ID4+IEkgY2FuJ3Qg
dXNlIFR1cmtpc2ggY2hhcnMgKGllLiDw/P5p9uf9INDc3t3Wx90pIGluIGxhYmVsLCB0aXRsZSwg
ZXRjLgo+ID4gPj4KPiA+ID4+IElmIEkgY2hhbmdlIHRoZSBmb2xsb3dpbmcgZnVuY3Rpb25zIHRv
IG9sZCBpbXBsZW1lbnRhdGlvbiwgaXQgd29ya3M6Cj4gPiA+PiBsdWEyd3gsIHd4Mmx1YS4KPiA+
ID4KPiA+ID4gUGxlYXNlIHNlZSB0aGlzIG1lc3NhZ2UKPiA+ID4gUmU6IFtXeGx1YS11c2Vyc10g
d3hTdHJpbmcsIFVuaWNvZGUgcHJvYmxlbSAuLi4uIChGaXhlZCwpIFN0ZXZlIEtpZXUKPiA+ID4g
aHR0cDovL3d3dy5tYWlsLWFyY2hpdmUuY29tL3d4bHVhLXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdl
Lm5ldC9pbmRleC5odG1sIzAwNjkyCj4gPiA+Cj4gPiA+IC8vIENvbnZlcnQgYSA4LWJpdCBMdWEg
U3RyaW5nIGludG8gd3hTdHJpbmcKPiA+ID4gaW5saW5lIFdYRExMSU1QRVhQX1dYTFVBIHd4U3Ry
aW5nIGx1YTJ3eChjb25zdCBjaGFyKiBsdWFzdHIpCj4gPiA+IHsKPiA+ID4gICAgIGlmIChsdWFz
dHIgPT0gTlVMTCkgcmV0dXJuIHd4RW1wdHlTdHJpbmc7IC8vIGNoZWNrIGZvciBOVUxMCj4gPiA+
Cj4gPiA+ICNpZiB3eFVTRV9VTklDT0RFCj4gPiA+ICAgICByZXR1cm4gd3hTdHJpbmcobHVhc3Ry
LCB3eENvbnZVVEY4KTsKPiA+ID4gI2Vsc2UKPiA+ID4gICAgIHJldHVybiB3eFN0cmluZyh3eENv
bnZVVEY4LmNNQjJXQyhsdWFzdHIpLCAqd3hDb252Q3VycmVudCk7Cj4gPiA+ICNlbmRpZiAvLyB3
eFVTRV9VTklDT0RFCj4gPiA+Cj4gPiA+ICAgLy9yZXR1cm4gd3hDb252ZXJ0TUIyV1gobHVhc3Ry
KTsgLy8gb2xkIHdheSB0aGF0IG1vc3RseSB3b3Jrcwo+ID4gPiB9Cj4gPiA+Cj4gPiA+IC8vIENv
bnZlcnQgYSB3eFN0cmluZyB0byA4LWJpdCBMdWEgU3RyaW5nCj4gPiA+IGlubGluZSBjb25zdCBX
WERMTElNUEVYUF9XWExVQSB3eENoYXJCdWZmZXIgd3gybHVhKGNvbnN0IHd4U3RyaW5nJiB3eHN0
cikKPiA+ID4gewo+ID4gPiAgICAgLy93eENoYXJCdWZmZXIgYnVmZmVyKHd4Q29udmVydFdYMk1C
KHd4c3RyLmNfc3RyKCkpKTsgLy8gb2xkIHdheQo+ID4gPiB0aGF0IG1vc3RseSB3b3Jrcwo+ID4g
PiAgICAgd3hDaGFyQnVmZmVyCj4gPiA+IGJ1ZmZlcih3eENvbnZVVEY4LmNXQzJNQih3eHN0ci53
Y19zdHIoKnd4Q29udkN1cnJlbnQpKSk7IC8vIHNraWV1Cj4gPiA+ICAgICByZXR1cm4gYnVmZmVy
Owo+ID4gPiB9Cj4gPiA+Cj4gPiA+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PQo+ID4gPgo+ID4KPiA+IElmIEknbSBub3QgbWlzdGFrZW4gc3RjIHVzZXMgVVRDMiBpbnRlcm5h
bGx5LiBTbyB1c2luZyBzdGMncyBjb252ZXJzaW9uCj4gPiBmdW5jdGlvbnMgbWF5IG5vdCBoZWxw
IGhlcmUuIEluc3RlYWQsIEkgdGVzdGVkIHVzaW5nIEZsYW1lUm9iaW4ncwo+ID4gKHd3dy5mbGFt
ZXJvYmluLm9yZykgZnVuY3Rpb25zIGZyb20gU3RyaW5nVXRpbHMuaDsKPiA+IHN0ZDo6c3RyaW5n
IHd4MnN0ZChjb25zdCB3eFN0cmluZyYgaW5wdXQsIHd4TUJDb252KiBjb252PXd4Q29udkN1cnJl
bnQpOwo+ID4gd3hTdHJpbmcgc3RkMnd4KGNvbnN0IHN0ZDo6c3RyaW5nJiBpbnB1dCwgd3hNQkNv
bnYqIGNvbnY9d3hDb252Q3VycmVudCk7Cj4KPiBIdW1tLCBpbnRlcmVzdGluZy4uLiBzZWUgYmVs
b3cuCj4KPiA+IENoYW5nZWQgbHVhMnd4LCB3eDJsdWEgYW5kIHd4THVhQ2hhckJ1ZmZlcidzIGN0
b3IgYXMgZm9sbG93czoKPiA+Cj4gPiBpbmxpbmUgV1hETExJTVBFWFBfV1hMVUEgd3hTdHJpbmcg
bHVhMnd4KGNvbnN0IGNoYXIqIGx1YXN0cikKPiA+IHsKPiA+ICAgICAgaWYgKGx1YXN0ciA9PSBO
VUxMKSByZXR1cm4gd3hFbXB0eVN0cmluZzsgLy8gY2hlY2sgZm9yIE5VTEwKPiA+ICAgICAgcmV0
dXJuIHd4U3RyaW5nKGx1YXN0ciwgKnd4Q29udkN1cnJlbnQpOwo+ID4gfQo+Cj4gVGhlIG9sZCB3
YXkgb2YgZG9pbmcgdGhlIGNvbnZlcnNpb24gZGlkIGl0IHRoaXMgd2F5Lgo+Cj4gLy9yZXR1cm4g
d3hDb252ZXJ0TUIyV1gobHVhc3RyKTsgLy8gb2xkIHdheSB0aGF0IG1vc3RseSB3b3Jrcwo+ICNk
ZWZpbmUgd3hDb252ZXJ0TUIyV1gocykgICB3eENvbnZDdXJyZW50LT5jTUIyV1gocykKPgo+IFRo
aXMgaXMgdGhlIGNvZGUgZm9yIHRoZSB3eFN0cmluZyBmdW5jdGlvbiB3aGljaCBkb2VzIHRoZSBz
YW1lIGFzIHd4Q29udmVydE1CMldYCj4gd3hTdHJpbmc6Ond4U3RyaW5nKGNvbnN0IGNoYXIgKnBz
eiwgY29uc3Qgd3hNQkNvbnYmIGNvbnYsIHNpemVfdCBuTGVuZ3RoKQo+IHsKPiAuLi4KPiAgICAg
ICB3eFdDaGFyQnVmZmVyIHdidWYgPSBjb252LmNNQjJXQyhwc3osIG5MZW5ndGgsICZuTGVuV2lk
ZSk7Cj4KPiA9PT09PT09PT09PT09PT09PT0KPiBJIHNlZSB0aGF0IHdlIGhhdmUgMyBkaWZmZXJl
bnQgd2F5cyB0byBjb252ZXJ0IHRoZSBzdHJpbmdzLiBXaGljaCB3YXkKPiBpcyAicmlnaHQiIGZv
ciBhbGwgY2FzZXMuCj4KPiAxKSBkb2Vzbid0IHdvcmsgZm9yIHNvbWUgdW5rbm93biBjYXNlcwo+
ICAgICB3eENvbnZlcnRNQjJXWCA9PSB3eENvbnZDdXJyZW50LT5jTUIyV1gocykgPT0KPiB3eENv
bnZDdXJyZW50LT5jTUIyV0MKPgo+IDIpIERvZXNuJ3Qgd29yayBmb3IgVHVya2lzaCAoYW5kIHVu
ZG91YnRlZGx5IG90aGVycykKPiAjaWYgd3hVU0VfVU5JQ09ERQo+ICAgICByZXR1cm4gd3hTdHJp
bmcobHVhc3RyLCB3eENvbnZVVEY4KTsKPiAjZWxzZQo+ICAgICByZXR1cm4gd3hTdHJpbmcod3hD
b252VVRGOC5jTUIyV0MobHVhc3RyKSwgKnd4Q29udkN1cnJlbnQpOwo+ICNlbmRpZiAvLyB3eFVT
RV9VTklDT0RFCj4KPiAzKSBuZXc/IHdvcmtzPwo+ICAgICB3eFN0cmluZyhsdWFzdHIsICp3eENv
bnZDdXJyZW50KTsgPT0KPiAgICAgd3hXQ2hhckJ1ZmZlciB3YnVmID0gY29udi5jTUIyV0MocHN6
LCBuTGVuZ3RoLCAmbkxlbldpZGUpOwo+Cj4KPiBUaGUgZGlmZmVyZW5jZXMgSSBzZWUgaXMgdGhh
dAoKT29wcywgbWVzc2FnZSBnb3Qgc2VudCB3aGVuIEkgcHJlc3NlZCBzb21lIGtleXMgYnkgYWNj
aWRlbnQuCgpTbyAjMSA9PSAjMyBhbmQgIzIgdXNlcyB3eENvbnZVVEY4IGluc3RlYWQgb2Ygd3hD
b252Q3VycmVudC4KCkkga25vdyB0aGF0IHd4VVNFX1VOSUNPREUgdXNlcyB3Y2hhcl90Cnd4Q29u
dkN1cnJlbnQgPT0gICZ3eENvbnZMaWJjT2JqID09CiAgICAjaWZkZWYgX19XSU5ET1dTX18KICAg
ICAgICBzdGF0aWMgd3hNQkNvbnZfd2luMzIgd3hDb252TGliY09iajsKICAgICNlbGlmIGRlZmlu
ZWQoX19XWE1BQ19fKSAmJiAhZGVmaW5lZChfX01BQ0hfXykKICAgICAgICBzdGF0aWMgd3hNQkNv
bnZfbWFjIHd4Q29udkxpYmNPYmogOwogICAgI2Vsc2UKICAgICAgICBzdGF0aWMgd3hNQkNvbnZM
aWJjIHd4Q29udkxpYmNPYmo7CiAgICAjZW5kaWYKCkkgdGhpbmsgd2UgbmVlZCB0byBoYXZlIGFu
c3dlcnMgdG8gdGhlc2UgcXVlc3Rpb25zLgoKSG93IGRvIHlvdSBrbm93IGlmIHlvdSdyZSB1c2lu
ZyBVVEY4PwpIb3cgZG8geW91IHNldCB3eFdpZGdldHMgdG8gdXNlIG9yIG5vdCB1c2UgVVRGOCBp
ZiB5b3Ugd2FudCB0bz8KSWYgeW91IGdldCB0ZXh0IGZyb20gdGhlIGNsaXBib2FyZCwgY2FuIGl0
IGJlIGluIFVURjg/CgphbmQgZmluYWxseSwgaXMgd3hDb252Q3VycmVudCBzdXBwb3NlZCB0byBo
YW5kbGUgVVRGOCBhcyBpcz8KCkkgcGVyc29uYWxseSBkb24ndCBoYXZlIGFueSBpZGVhIGFuZCB3
b3VsZCBuYWl2ZWx5IHRoaW5rIHRoYXQKd3hDb252Q3VycmVudCBpbnN0ZWFkIG9mIHd4Q29udlVU
RjggaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLgo=

Re: [wxlua-users] Problem in using Turkish in wxLua scripts

[John L. <jla...@gm...>]

T24gMTIvNi8wNiwgSGFra2kgRG9ndXNhbiA8ZG9ndXNhbmhAdHIubmV0PiB3cm90ZToKPiBKb2hu
IExhYmVuc2tpIHdyb3RlOgo+ID4gT24gMTIvNS8wNiwgSGFra2kgRG9ndXNhbiA8ZG9ndXNhbmhA
dHIubmV0PiB3cm90ZToKPiA+PiAoTWluZ3csIHd4THVhIGN2cywgd3gyLjcuMi93eDIuOCBBTlNJ
IGFuZCBVbmljb2RlLCBXaW5YUCBUdXJraXNoKQo+ID4+Cj4gPj4gSSBjYW4ndCB1c2UgVHVya2lz
aCBjaGFycyAoaWUuIPD8/mn25/0g0Nze3dbH3SkgaW4gbGFiZWwsIHRpdGxlLCBldGMuCj4gPj4K
PiA+PiBJZiBJIGNoYW5nZSB0aGUgZm9sbG93aW5nIGZ1bmN0aW9ucyB0byBvbGQgaW1wbGVtZW50
YXRpb24sIGl0IHdvcmtzOgo+ID4+IGx1YTJ3eCwgd3gybHVhLgo+ID4KPiA+IFBsZWFzZSBzZWUg
dGhpcyBtZXNzYWdlCj4gPiBSZTogW1d4bHVhLXVzZXJzXSB3eFN0cmluZywgVW5pY29kZSBwcm9i
bGVtIC4uLi4gKEZpeGVkLCkgU3RldmUgS2lldQo+ID4gaHR0cDovL3d3dy5tYWlsLWFyY2hpdmUu
Y29tL3d4bHVhLXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldC9pbmRleC5odG1sIzAwNjkyCj4g
Pgo+ID4gLy8gQ29udmVydCBhIDgtYml0IEx1YSBTdHJpbmcgaW50byB3eFN0cmluZwo+ID4gaW5s
aW5lIFdYRExMSU1QRVhQX1dYTFVBIHd4U3RyaW5nIGx1YTJ3eChjb25zdCBjaGFyKiBsdWFzdHIp
Cj4gPiB7Cj4gPiAgICAgaWYgKGx1YXN0ciA9PSBOVUxMKSByZXR1cm4gd3hFbXB0eVN0cmluZzsg
Ly8gY2hlY2sgZm9yIE5VTEwKPiA+Cj4gPiAjaWYgd3hVU0VfVU5JQ09ERQo+ID4gICAgIHJldHVy
biB3eFN0cmluZyhsdWFzdHIsIHd4Q29udlVURjgpOwo+ID4gI2Vsc2UKPiA+ICAgICByZXR1cm4g
d3hTdHJpbmcod3hDb252VVRGOC5jTUIyV0MobHVhc3RyKSwgKnd4Q29udkN1cnJlbnQpOwo+ID4g
I2VuZGlmIC8vIHd4VVNFX1VOSUNPREUKPiA+Cj4gPiAgIC8vcmV0dXJuIHd4Q29udmVydE1CMldY
KGx1YXN0cik7IC8vIG9sZCB3YXkgdGhhdCBtb3N0bHkgd29ya3MKPiA+IH0KPiA+Cj4gPiAvLyBD
b252ZXJ0IGEgd3hTdHJpbmcgdG8gOC1iaXQgTHVhIFN0cmluZwo+ID4gaW5saW5lIGNvbnN0IFdY
RExMSU1QRVhQX1dYTFVBIHd4Q2hhckJ1ZmZlciB3eDJsdWEoY29uc3Qgd3hTdHJpbmcmIHd4c3Ry
KQo+ID4gewo+ID4gICAgIC8vd3hDaGFyQnVmZmVyIGJ1ZmZlcih3eENvbnZlcnRXWDJNQih3eHN0
ci5jX3N0cigpKSk7IC8vIG9sZCB3YXkKPiA+IHRoYXQgbW9zdGx5IHdvcmtzCj4gPiAgICAgd3hD
aGFyQnVmZmVyCj4gPiBidWZmZXIod3hDb252VVRGOC5jV0MyTUIod3hzdHIud2Nfc3RyKCp3eENv
bnZDdXJyZW50KSkpOyAvLyBza2lldQo+ID4gICAgIHJldHVybiBidWZmZXI7Cj4gPiB9Cj4gPgo+
ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4gPgo+Cj4gSWYgSSdtIG5v
dCBtaXN0YWtlbiBzdGMgdXNlcyBVVEMyIGludGVybmFsbHkuIFNvIHVzaW5nIHN0YydzIGNvbnZl
cnNpb24KPiBmdW5jdGlvbnMgbWF5IG5vdCBoZWxwIGhlcmUuIEluc3RlYWQsIEkgdGVzdGVkIHVz
aW5nIEZsYW1lUm9iaW4ncwo+ICh3d3cuZmxhbWVyb2Jpbi5vcmcpIGZ1bmN0aW9ucyBmcm9tIFN0
cmluZ1V0aWxzLmg7Cj4gc3RkOjpzdHJpbmcgd3gyc3RkKGNvbnN0IHd4U3RyaW5nJiBpbnB1dCwg
d3hNQkNvbnYqIGNvbnY9d3hDb252Q3VycmVudCk7Cj4gd3hTdHJpbmcgc3RkMnd4KGNvbnN0IHN0
ZDo6c3RyaW5nJiBpbnB1dCwgd3hNQkNvbnYqIGNvbnY9d3hDb252Q3VycmVudCk7CgpIdW1tLCBp
bnRlcmVzdGluZy4uLiBzZWUgYmVsb3cuCgo+IENoYW5nZWQgbHVhMnd4LCB3eDJsdWEgYW5kIHd4
THVhQ2hhckJ1ZmZlcidzIGN0b3IgYXMgZm9sbG93czoKPgo+IGlubGluZSBXWERMTElNUEVYUF9X
WExVQSB3eFN0cmluZyBsdWEyd3goY29uc3QgY2hhciogbHVhc3RyKQo+IHsKPiAgICAgIGlmIChs
dWFzdHIgPT0gTlVMTCkgcmV0dXJuIHd4RW1wdHlTdHJpbmc7IC8vIGNoZWNrIGZvciBOVUxMCj4g
ICAgICByZXR1cm4gd3hTdHJpbmcobHVhc3RyLCAqd3hDb252Q3VycmVudCk7Cj4gfQoKVGhlIG9s
ZCB3YXkgb2YgZG9pbmcgdGhlIGNvbnZlcnNpb24gZGlkIGl0IHRoaXMgd2F5LgoKLy9yZXR1cm4g
d3hDb252ZXJ0TUIyV1gobHVhc3RyKTsgLy8gb2xkIHdheSB0aGF0IG1vc3RseSB3b3JrcwojZGVm
aW5lIHd4Q29udmVydE1CMldYKHMpICAgd3hDb252Q3VycmVudC0+Y01CMldYKHMpCgpUaGlzIGlz
IHRoZSBjb2RlIGZvciB0aGUgd3hTdHJpbmcgZnVuY3Rpb24gd2hpY2ggZG9lcyB0aGUgc2FtZSBh
cyB3eENvbnZlcnRNQjJXWAp3eFN0cmluZzo6d3hTdHJpbmcoY29uc3QgY2hhciAqcHN6LCBjb25z
dCB3eE1CQ29udiYgY29udiwgc2l6ZV90IG5MZW5ndGgpCnsKLi4uCiAgICAgIHd4V0NoYXJCdWZm
ZXIgd2J1ZiA9IGNvbnYuY01CMldDKHBzeiwgbkxlbmd0aCwgJm5MZW5XaWRlKTsKCj09PT09PT09
PT09PT09PT09PQpJIHNlZSB0aGF0IHdlIGhhdmUgMyBkaWZmZXJlbnQgd2F5cyB0byBjb252ZXJ0
IHRoZSBzdHJpbmdzLiBXaGljaCB3YXkKaXMgInJpZ2h0IiBmb3IgYWxsIGNhc2VzLgoKMSkgZG9l
c24ndCB3b3JrIGZvciBzb21lIHVua25vd24gY2FzZXMKICAgIHd4Q29udmVydE1CMldYID09IHd4
Q29udkN1cnJlbnQtPmNNQjJXWChzKSA9PQp3eENvbnZDdXJyZW50LT5jTUIyV0MKCjIpIERvZXNu
J3Qgd29yayBmb3IgVHVya2lzaCAoYW5kIHVuZG91YnRlZGx5IG90aGVycykKI2lmIHd4VVNFX1VO
SUNPREUKICAgIHJldHVybiB3eFN0cmluZyhsdWFzdHIsIHd4Q29udlVURjgpOwojZWxzZQogICAg
cmV0dXJuIHd4U3RyaW5nKHd4Q29udlVURjguY01CMldDKGx1YXN0ciksICp3eENvbnZDdXJyZW50
KTsKI2VuZGlmIC8vIHd4VVNFX1VOSUNPREUKCjMpIG5ldz8gd29ya3M/CiAgICB3eFN0cmluZyhs
dWFzdHIsICp3eENvbnZDdXJyZW50KTsgPT0KICAgIHd4V0NoYXJCdWZmZXIgd2J1ZiA9IGNvbnYu
Y01CMldDKHBzeiwgbkxlbmd0aCwgJm5MZW5XaWRlKTsKCgpUaGUgZGlmZmVyZW5jZXMgSSBzZWUg
aXMgdGhhdAoKCgo+IGlubGluZSBjb25zdCBXWERMTElNUEVYUF9XWExVQSB3eENoYXJCdWZmZXIg
d3gybHVhKGNvbnN0IHd4U3RyaW5nJiB3eHN0cikKPiB7Cj4gICAgICB3eENoYXJCdWZmZXIgYnVm
ZmVyKHd4c3RyLm1iX3N0cigqd3hDb252Q3VycmVudCkpOwo+ICAgICAgcmV0dXJuIGJ1ZmZlcjsK
PiB9Cj4KPiB3eEx1YUNoYXJCdWZmZXIoY29uc3Qgd3hTdHJpbmcgJnd4c3RyKSA6IG1fYnVmZmVy
KChjb25zdCBjaGFyICopTlVMTCkKPiB7Cj4gICAgICBtX2J1ZmZlciA9IHd4Q2hhckJ1ZmZlcih3
eHN0ci5tYl9zdHIoKnd4Q29udkN1cnJlbnQpKTsKPiB9Cj4KPgo+IEkgdGVzdGVkIHdpdGggd3hV
U0VfVU5JQ09ERT0xIGFuZCA9MCBjb25maWd1cmF0aW9ucy4KPgo+IEkgY2FuIHVzZSBUdXJraXNo
IGNoYXJhY3RlcnMgbm93Lgo+Cj4gKE1pbmd3LCB3eEx1YSBjdnMsIHd4Mi44IEFTQ0lJIGFuZCBV
bmljb2RlLCBXaW5YUCBUdXJraXNoKQo+Cj4KPiBwcy4gVGhhbmsgeW91IGZvciB3b3JraW5nIGhh
cmQgb24gd3hMdWEhCj4KPgo+IC0tCj4gUmVnYXJkcywKPiBIYWtraSBEb2d1c2FuCj4KPiAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCj4gVGFrZSBTdXJ2ZXlzLiBFYXJuIENhc2guIEluZmx1ZW5jZSB0aGUgRnV0
dXJlIG9mIElUCj4gSm9pbiBTb3VyY2VGb3JnZS5uZXQncyBUZWNoc2F5IHBhbmVsIGFuZCB5b3Un
bGwgZ2V0IHRoZSBjaGFuY2UgdG8gc2hhcmUgeW91cgo+IG9waW5pb25zIG9uIElUICYgYnVzaW5l
c3MgdG9waWNzIHRocm91Z2ggYnJpZWYgc3VydmV5cyAtIGFuZCBlYXJuIGNhc2gKPiBodHRwOi8v
d3d3LnRlY2hzYXkuY29tL2RlZmF1bHQucGhwP3BhZ2U9am9pbi5waHAmcD1zb3VyY2Vmb3JnZSZD
SUQ9REVWREVWCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KPiB3eGx1YS11c2VycyBtYWlsaW5nIGxpc3QKPiB3eGx1YS11c2Vyc0BsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQKPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby93
eGx1YS11c2Vycwo+Cg==

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

[John L. <jla...@gm...>]

ps. Yes there is something that would be nice to have in the build files.

It looks like the object files for VC for the mod_wxlua (for example)
go into wxLua/modules/build/msw/msvc6prjd/mod_wxlua for all of these
builds
>From modules_mod_wxlua.dsp

!ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Monolithic"
!ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Multilib"
!ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Monolithic"
!ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Multilib"

I think it's ok for for monolithic and multilib, but the dll ones have
to go somewhere else since if you use batch build in VC to build both
Debug and DLL Debug it starts getting all sorts of errors/warnings
about wrong function signatures after the first lib is compiled since
I assume that it's using the same object files for both, but the
WXEXPORT is different.

I hope that is easy to do, thanks
     John Labenski



On 12/6/06, John Labenski <jla...@gm...> wrote:
> On 12/6/06, Francesco Montorsi <f18...@ya...> wrote:
> > John Labenski ha scritto:
> > > I have rewritten the coroutine code so that we do not have to replace
> > > luaE_newthread and luaE_freethread by pushing the wxLuaStateRefData
> > > into the registry table.
> > good work!
> >
> > >
> > > Hopefully this will make using wxLua as a lua module using require
> > > much easier... of course the build files have to sorted out.
> > I'll reorganize the bakefiles tonight ;)
> >
> > With bakefile 0.2.1 we are very very near to have all functionalities we
> > need in the "official" bakefile. In fact, the only thing which makes us
> > depend on a patched bakefile currently is that we want to:
> >
> >   1) use wxPresets and all logic they contain
> >   2) have WX_DEBUG=0/1 and WX_UNICODE replaced by BUILD=debug/release
> > and UNICODE option names
> >
> > if we remove "feature" #2 then we can use bakefile 0.2.1
> > if we don't, hopefully Vaclav will apply my patch for bakefile 0.2.2
> > (I'm pinging him about that patch since a long time now).
>
> Hopefully, soon. :)
>
> Is the bakefile on the wxLua website the same one you're using
> (htdocs/bakefile/frm-bakefile.tar.gz). I haven't tried it yet, since
> this would be the first time I'd need it. If not could you update it
> if it's not too much trouble?
>
> > Is there any other build problem which I should solve this evening ?
>
> I don't think so. I dunno what you want to do about naming the lua.exe
> and lua.dll. Do we put wx in it somewhere since some linux
> distributions have lua packages and we don't want to overwrite it for
> "make install" even though it's identical?
>
> Thanks,
>     John Labenski
>

Re: [wxlua-users] How to compile wxLua as module for -original- lua?

[John L. <jla...@gm...>]

On 12/6/06, Hakki Dogusan <dog...@tr...> wrote:
> John Labenski wrote:
> > On 12/5/06, Hakki Dogusan <dog...@tr...> wrote:
> >> (Mingw, wxLua cvs, wx2.7.2/wx2.8 ANSI and Unicode, WinXP Turkish)
>
> Indeed now LUA5.1.DLL == WXLUA_MSW28U_LUA.DLL
>
> I assume new makefiles won't generate WXLUA_MSW28U_LUA.DLL?
>
> ps. I built a wxLua module with Code::Blocks. I used wx as
> static lib. It seems work. It is ~3Mb (upx'ed) single dll,
> only depends to lua5.1.dll. If you interested I can put it
> somewhere.

Great! If you have a place for me to get them I'll upload them to the
wxLua site into the downloads dir.

By the way, how do you use Code::Blocks with wxLua? I tried to use
Code::Blocks a while back and found that it generated a bunch of build
files for me. I asked on their forum how to get it to not do that, but
didn't get a response. Is there a way to merely use CB as an editor
and not have it generate or touch any files other than it's project
file? It seemed like a very nice editor, but it made me nervous that
it was generating things that might overwrite what I already had.

Thanks,
    John Labenski

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

[John L. <jla...@gm...>]

On 12/6/06, Francesco Montorsi <f18...@ya...> wrote:
> John Labenski ha scritto:
> > I have rewritten the coroutine code so that we do not have to replace
> > luaE_newthread and luaE_freethread by pushing the wxLuaStateRefData
> > into the registry table.
> good work!
>
> >
> > Hopefully this will make using wxLua as a lua module using require
> > much easier... of course the build files have to sorted out.
> I'll reorganize the bakefiles tonight ;)
>
> With bakefile 0.2.1 we are very very near to have all functionalities we
> need in the "official" bakefile. In fact, the only thing which makes us
> depend on a patched bakefile currently is that we want to:
>
>   1) use wxPresets and all logic they contain
>   2) have WX_DEBUG=0/1 and WX_UNICODE replaced by BUILD=debug/release
> and UNICODE option names
>
> if we remove "feature" #2 then we can use bakefile 0.2.1
> if we don't, hopefully Vaclav will apply my patch for bakefile 0.2.2
> (I'm pinging him about that patch since a long time now).

Hopefully, soon. :)

Is the bakefile on the wxLua website the same one you're using
(htdocs/bakefile/frm-bakefile.tar.gz). I haven't tried it yet, since
this would be the first time I'd need it. If not could you update it
if it's not too much trouble?

> Is there any other build problem which I should solve this evening ?

I don't think so. I dunno what you want to do about naming the lua.exe
and lua.dll. Do we put wx in it somewhere since some linux
distributions have lua packages and we don't want to overwrite it for
"make install" even though it's identical?

Thanks,
    John Labenski

Re: [wxlua-users] How to compile wxLua as module for -original- lua?

[Hakki D. <dog...@tr...>]

Hi,

John Labenski wrote:
> On 12/5/06, Hakki Dogusan <dog...@tr...> wrote:
>> (Mingw, wxLua cvs, wx2.7.2/wx2.8 ANSI and Unicode, WinXP Turkish)
>>
>> I want a wx.dll usable with standart lua.
>> Is it possible with supplied makefiles?
>>
>> ps.
>> If I compile wxLua with the following options;
>> SHARED = 1, WX_SHARED = 1,USE_LUAMODULE = 1
>>
>> It gives a wx.dll depending on
>> LUA5.1.DLL
>> WXLUA_MSW28U_WXBIND.DLL
>> WXLUA_MSW28U_WXLUA.DLL
>>
>> But WXLUA_MSW28U_WXBIND.DLL also depends on
>> WXLUA_MSW28U_LUA.DLL (which already has lua library in it)
> 
> Since the modified lua that wxLua was using is a little bit of a
> headache for the above reason, I've rewritten the coroutine handling
> code to work with the original lua.
> 
> So... to solve your problem we have to rebuild the build files. I hope
> I can get the bakefile we use to work tomorrow.
> 
> In the meantime, if you get an update from CVS or the latest snapshot,
> hacking it should be pretty easy since there shouldn't be any
> difference between
> WXLUA_MSW28U_LUA.DLL
> LUA5.1.DLL
> 
> I'll let you know after the rebuild.
> 
> Regards,
>     John Labenski
> 

Thanks.

Indeed now LUA5.1.DLL == WXLUA_MSW28U_LUA.DLL

I assume new makefiles won't generate WXLUA_MSW28U_LUA.DLL?

ps. I built a wxLua module with Code::Blocks. I used wx as
static lib. It seems work. It is ~3Mb (upx'ed) single dll,
only depends to lua5.1.dll. If you interested I can put it
somewhere.


--
Regards,
Hakki Dogusan

Re: [wxlua-users] Problem in using Turkish in wxLua scripts

[Hakki D. <dog...@tr...>]

Hi,

John Labenski wrote:
> On 12/5/06, Hakki Dogusan <dog...@tr...> wrote:
>> (Mingw, wxLua cvs, wx2.7.2/wx2.8 ANSI and Unicode, WinXP Turkish)
>>
>> I can't use Turkish chars (ie. ğüşiöçı ĞÜŞİÖÇİ) in label, title, etc.
>>
>> If I change the following functions to old implementation, it works:
>> lua2wx, wx2lua.
> 
> The characters you sent above work in the title of a wxFrame in wxLua
> compiled in Linux, unicode w/ gcc. So it's a problem in MSW. I also
> checked with some other chars on this page.
> http://www.columbia.edu/kermit/utf8.html
> 
> The code I think you're talking about is below. Things were changed to
> fix unicode strings in MSWindows.
> 
> Please see this message
> Re: [Wxlua-users] wxString, Unicode problem .... (Fixed,) Steve Kieu
> http://www.mail-archive.com/wxl...@li.../index.html#00692
> 
> 
> // Convert a 8-bit Lua String into wxString
> inline WXDLLIMPEXP_WXLUA wxString lua2wx(const char* luastr)
> {
>     if (luastr == NULL) return wxEmptyString; // check for NULL
> 
> #if wxUSE_UNICODE
>     return wxString(luastr, wxConvUTF8);
> #else
>     return wxString(wxConvUTF8.cMB2WC(luastr), *wxConvCurrent);
> #endif // wxUSE_UNICODE
> 
>   //return wxConvertMB2WX(luastr); // old way that mostly works
> }
> 
> // Convert a wxString to 8-bit Lua String
> inline const WXDLLIMPEXP_WXLUA wxCharBuffer wx2lua(const wxString& wxstr)
> {
>     //wxCharBuffer buffer(wxConvertWX2MB(wxstr.c_str())); // old way
> that mostly works
>     wxCharBuffer
> buffer(wxConvUTF8.cWC2MB(wxstr.wc_str(*wxConvCurrent))); // skieu
>     return buffer;
> }
> 
> 
> ====================================
> 
> I have asked about conversions on wx-users a long time ago and didn't
> get a concrete answer as to the single best way to do it. The old way
> is copied from the functions wx2stc and stc2wx that were used in the
> wxStyledTextCtrl, however more recent versions use the string
> conversion funcions that are part of Scintilla, see
> wxWidgets/contrib/src/stc/scintilla/src/UniConversion.cxx.
> 
> Could you try to replace the code in wx2lua and lua2wx with wx2stc and
> stc2wx. You'll have to #include "wx/stc/stc.h". Please let us know if
> it works.
> 
> 
> Hopefully Steve Kieu will read this and chime in since he seems pretty
> familiar with unicode strings.
> 
> Regards,
>     John Labenski

(Sorry for not joining to unicode discussions; I don't know it well.
I'm following wxLua since the beginning, but only recently I decide
to write a program with it.)


If I'm not mistaken stc uses UTC2 internally. So using stc's conversion
functions may not help here. Instead, I tested using FlameRobin's
(www.flamerobin.org) functions from StringUtils.h;
std::string wx2std(const wxString& input, wxMBConv* conv=wxConvCurrent);
wxString std2wx(const std::string& input, wxMBConv* conv=wxConvCurrent);


Changed lua2wx, wx2lua and wxLuaCharBuffer's ctor as follows:

inline WXDLLIMPEXP_WXLUA wxString lua2wx(const char* luastr)
{
     if (luastr == NULL) return wxEmptyString; // check for NULL
     return wxString(luastr, *wxConvCurrent);
}

inline const WXDLLIMPEXP_WXLUA wxCharBuffer wx2lua(const wxString& wxstr)
{
     wxCharBuffer buffer(wxstr.mb_str(*wxConvCurrent));
     return buffer;
}

wxLuaCharBuffer(const wxString &wxstr) : m_buffer((const char *)NULL)
{
     m_buffer = wxCharBuffer(wxstr.mb_str(*wxConvCurrent));
}


I tested with wxUSE_UNICODE=1 and =0 configurations.

I can use Turkish characters now.

(Mingw, wxLua cvs, wx2.8 ASCII and Unicode, WinXP Turkish)


ps. Thank you for working hard on wxLua!


--
Regards,
Hakki Dogusan

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
> I have rewritten the coroutine code so that we do not have to replace
> luaE_newthread and luaE_freethread by pushing the wxLuaStateRefData
> into the registry table.
good work!

> 
> Hopefully this will make using wxLua as a lua module using require
> much easier... of course the build files have to sorted out.
I'll reorganize the bakefiles tonight ;)

With bakefile 0.2.1 we are very very near to have all functionalities we 
need in the "official" bakefile. In fact, the only thing which makes us 
depend on a patched bakefile currently is that we want to:

  1) use wxPresets and all logic they contain
  2) have WX_DEBUG=0/1 and WX_UNICODE replaced by BUILD=debug/release 
and UNICODE option names

if we remove "feature" #2 then we can use bakefile 0.2.1
if we don't, hopefully Vaclav will apply my patch for bakefile 0.2.2 
(I'm pinging him about that patch since a long time now).

Is there any other build problem which I should solve this evening ?

Francesco

[wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

[John L. <jla...@gm...>]

I have rewritten the coroutine code so that we do not have to replace
luaE_newthread and luaE_freethread by pushing the wxLuaStateRefData
into the registry table.

Hopefully this will make using wxLua as a lua module using require
much easier... of course the build files have to sorted out.

Regards,
    John Labenski

Re: [wxlua-users] How to compile wxLua as module for -original- lua?

[John L. <jla...@gm...>]

On 12/5/06, Hakki Dogusan <dog...@tr...> wrote:
> (Mingw, wxLua cvs, wx2.7.2/wx2.8 ANSI and Unicode, WinXP Turkish)
>
> I want a wx.dll usable with standart lua.
> Is it possible with supplied makefiles?
>
> ps.
> If I compile wxLua with the following options;
> SHARED = 1, WX_SHARED = 1,USE_LUAMODULE = 1
>
> It gives a wx.dll depending on
> LUA5.1.DLL
> WXLUA_MSW28U_WXBIND.DLL
> WXLUA_MSW28U_WXLUA.DLL
>
> But WXLUA_MSW28U_WXBIND.DLL also depends on
> WXLUA_MSW28U_LUA.DLL (which already has lua library in it)

Since the modified lua that wxLua was using is a little bit of a
headache for the above reason, I've rewritten the coroutine handling
code to work with the original lua.

So... to solve your problem we have to rebuild the build files. I hope
I can get the bakefile we use to work tomorrow.

In the meantime, if you get an update from CVS or the latest snapshot,
hacking it should be pretty easy since there shouldn't be any
difference between
WXLUA_MSW28U_LUA.DLL
LUA5.1.DLL

I'll let you know after the rebuild.

Regards,
    John Labenski

Re: [wxlua-users] Problem in using Turkish in wxLua scripts

[John L. <jla...@gm...>]

T24gMTIvNS8wNiwgSGFra2kgRG9ndXNhbiA8ZG9ndXNhbmhAdHIubmV0PiB3cm90ZToKPiAoTWlu
Z3csIHd4THVhIGN2cywgd3gyLjcuMi93eDIuOCBBTlNJIGFuZCBVbmljb2RlLCBXaW5YUCBUdXJr
aXNoKQo+Cj4gSSBjYW4ndCB1c2UgVHVya2lzaCBjaGFycyAoaWUuIPD8/mn25/0g0Nze3dbH3Skg
aW4gbGFiZWwsIHRpdGxlLCBldGMuCj4KPiBJZiBJIGNoYW5nZSB0aGUgZm9sbG93aW5nIGZ1bmN0
aW9ucyB0byBvbGQgaW1wbGVtZW50YXRpb24sIGl0IHdvcmtzOgo+IGx1YTJ3eCwgd3gybHVhLgoK
VGhlIGNoYXJhY3RlcnMgeW91IHNlbnQgYWJvdmUgd29yayBpbiB0aGUgdGl0bGUgb2YgYSB3eEZy
YW1lIGluIHd4THVhCmNvbXBpbGVkIGluIExpbnV4LCB1bmljb2RlIHcvIGdjYy4gU28gaXQncyBh
IHByb2JsZW0gaW4gTVNXLiBJIGFsc28KY2hlY2tlZCB3aXRoIHNvbWUgb3RoZXIgY2hhcnMgb24g
dGhpcyBwYWdlLgpodHRwOi8vd3d3LmNvbHVtYmlhLmVkdS9rZXJtaXQvdXRmOC5odG1sCgpUaGUg
Y29kZSBJIHRoaW5rIHlvdSdyZSB0YWxraW5nIGFib3V0IGlzIGJlbG93LiBUaGluZ3Mgd2VyZSBj
aGFuZ2VkIHRvCmZpeCB1bmljb2RlIHN0cmluZ3MgaW4gTVNXaW5kb3dzLgoKUGxlYXNlIHNlZSB0
aGlzIG1lc3NhZ2UKUmU6IFtXeGx1YS11c2Vyc10gd3hTdHJpbmcsIFVuaWNvZGUgcHJvYmxlbSAu
Li4uIChGaXhlZCwpIFN0ZXZlIEtpZXUKaHR0cDovL3d3dy5tYWlsLWFyY2hpdmUuY29tL3d4bHVh
LXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldC9pbmRleC5odG1sIzAwNjkyCgoKLy8gQ29udmVy
dCBhIDgtYml0IEx1YSBTdHJpbmcgaW50byB3eFN0cmluZwppbmxpbmUgV1hETExJTVBFWFBfV1hM
VUEgd3hTdHJpbmcgbHVhMnd4KGNvbnN0IGNoYXIqIGx1YXN0cikKewogICAgaWYgKGx1YXN0ciA9
PSBOVUxMKSByZXR1cm4gd3hFbXB0eVN0cmluZzsgLy8gY2hlY2sgZm9yIE5VTEwKCiNpZiB3eFVT
RV9VTklDT0RFCiAgICByZXR1cm4gd3hTdHJpbmcobHVhc3RyLCB3eENvbnZVVEY4KTsKI2Vsc2UK
ICAgIHJldHVybiB3eFN0cmluZyh3eENvbnZVVEY4LmNNQjJXQyhsdWFzdHIpLCAqd3hDb252Q3Vy
cmVudCk7CiNlbmRpZiAvLyB3eFVTRV9VTklDT0RFCgogIC8vcmV0dXJuIHd4Q29udmVydE1CMldY
KGx1YXN0cik7IC8vIG9sZCB3YXkgdGhhdCBtb3N0bHkgd29ya3MKfQoKLy8gQ29udmVydCBhIHd4
U3RyaW5nIHRvIDgtYml0IEx1YSBTdHJpbmcKaW5saW5lIGNvbnN0IFdYRExMSU1QRVhQX1dYTFVB
IHd4Q2hhckJ1ZmZlciB3eDJsdWEoY29uc3Qgd3hTdHJpbmcmIHd4c3RyKQp7CiAgICAvL3d4Q2hh
ckJ1ZmZlciBidWZmZXIod3hDb252ZXJ0V1gyTUIod3hzdHIuY19zdHIoKSkpOyAvLyBvbGQgd2F5
CnRoYXQgbW9zdGx5IHdvcmtzCiAgICB3eENoYXJCdWZmZXIKYnVmZmVyKHd4Q29udlVURjguY1dD
Mk1CKHd4c3RyLndjX3N0cigqd3hDb252Q3VycmVudCkpKTsgLy8gc2tpZXUKICAgIHJldHVybiBi
dWZmZXI7Cn0KCgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCkkgaGF2ZSBh
c2tlZCBhYm91dCBjb252ZXJzaW9ucyBvbiB3eC11c2VycyBhIGxvbmcgdGltZSBhZ28gYW5kIGRp
ZG4ndApnZXQgYSBjb25jcmV0ZSBhbnN3ZXIgYXMgdG8gdGhlIHNpbmdsZSBiZXN0IHdheSB0byBk
byBpdC4gVGhlIG9sZCB3YXkKaXMgY29waWVkIGZyb20gdGhlIGZ1bmN0aW9ucyB3eDJzdGMgYW5k
IHN0YzJ3eCB0aGF0IHdlcmUgdXNlZCBpbiB0aGUKd3hTdHlsZWRUZXh0Q3RybCwgaG93ZXZlciBt
b3JlIHJlY2VudCB2ZXJzaW9ucyB1c2UgdGhlIHN0cmluZwpjb252ZXJzaW9uIGZ1bmNpb25zIHRo
YXQgYXJlIHBhcnQgb2YgU2NpbnRpbGxhLCBzZWUKd3hXaWRnZXRzL2NvbnRyaWIvc3JjL3N0Yy9z
Y2ludGlsbGEvc3JjL1VuaUNvbnZlcnNpb24uY3h4LgoKQ291bGQgeW91IHRyeSB0byByZXBsYWNl
IHRoZSBjb2RlIGluIHd4Mmx1YSBhbmQgbHVhMnd4IHdpdGggd3gyc3RjIGFuZApzdGMyd3guIFlv
dSdsbCBoYXZlIHRvICNpbmNsdWRlICJ3eC9zdGMvc3RjLmgiLiBQbGVhc2UgbGV0IHVzIGtub3cg
aWYKaXQgd29ya3MuCgoKSG9wZWZ1bGx5IFN0ZXZlIEtpZXUgd2lsbCByZWFkIHRoaXMgYW5kIGNo
aW1lIGluIHNpbmNlIGhlIHNlZW1zIHByZXR0eQpmYW1pbGlhciB3aXRoIHVuaWNvZGUgc3RyaW5n
cy4KClJlZ2FyZHMsCiAgICBKb2huIExhYmVuc2tpCg==

Re: [wxlua-users] editor.wx.lua output problem

[Andre <ar...@ki...>]

John Labenski <jlabenski@...> writes:

> 
> I think you meant to add -c instead of remove it? Since it wasn't there 
before.

yes should have run diff the other way 

> 
> Anyway, I added -c and tweaked up the C++ console code, fixed saving
> of the files before running them, and now print out the process id for
> informational purposes.

Yes this is a good idea could save some aggravations

> 
> Please try the latest CVS and see if it works a little more nicely.
> I'll test tonight in Linux to see where the output goes, IIRC it goes
> nowhere for a spawned process so we'll have to use the wxLuaConsole
> there too.

I have tried the new version work's great 
> 
> Regards,
>     John Labenski
> 

Thank you

Andre

[wxlua-users] How to compile wxLua as module for -original- lua?

[Hakki D. <dog...@tr...>]

Hi,

(Mingw, wxLua cvs, wx2.7.2/wx2.8 ANSI and Unicode, WinXP Turkish)

I want a wx.dll usable with standart lua.
Is it possible with supplied makefiles?

ps.
If I compile wxLua with the following options;
SHARED = 1, WX_SHARED = 1,USE_LUAMODULE = 1

It gives a wx.dll depending on
LUA5.1.DLL
WXLUA_MSW28U_WXBIND.DLL
WXLUA_MSW28U_WXLUA.DLL

But WXLUA_MSW28U_WXBIND.DLL also depends on
WXLUA_MSW28U_LUA.DLL (which already has lua library in it)



--
Regards,
Hakki Dogusan

[wxlua-users] Problem in using Turkish in wxLua scripts

[Hakki D. <dog...@tr...>]

Hi,

(Mingw, wxLua cvs, wx2.7.2/wx2.8 ANSI and Unicode, WinXP Turkish)


I can't use Turkish chars (ie. ğüşiöçı ĞÜŞİÖÇİ) in label, title, etc.

If I change the following functions to old implementation, it works:
lua2wx, wx2lua.


What to do?


--
Regards,
Hakki Dogusan

Re: [wxlua-users] editor.wx.lua output problem

[John L. <jla...@gm...>]

On 12/5/06, Andre <ar...@ki...> wrote:
> John Labenski <jlabenski@...> writes:
> >
> > I have not looked too much at the console, doesn't this pop up a text
> > box to show the output in? It's a hack for MSW since usually stuff
> > printed to stdout goes nowhere. This would be a nice option though.
>
> Yes the console receives the stdout and stderr (I believe).

I think you meant to add -c instead of remove it? Since it wasn't there before.

Anyway, I added -c and tweaked up the C++ console code, fixed saving
of the files before running them, and now print out the process id for
informational purposes.

Please try the latest CVS and see if it works a little more nicely.
I'll test tonight in Linux to see where the output goes, IIRC it goes
nowhere for a spawned process so we'll have to use the wxLuaConsole
there too.

Regards,
    John Labenski

Re: [wxlua-users] editor.wx.lua output problem

[Andre <ar...@ki...>]

John Labenski <jlabenski@...> writes:

> 
> I have not looked too much at the console, doesn't this pop up a text
> box to show the output in? It's a hack for MSW since usually stuff
> printed to stdout goes nowhere. This would be a nice option though.
> 

Yes the console receives the stdout and stderr (I believe).

> > I am planning to see if I can fix other related problems and maybe add some
> 
> If you work on it could you use the CVS version of editor.wx.lua or at
> least the most recent snapshot from the download page. I would
> appreciate any fixes or enhancements.
I am using the CVS version.
> 
> I went through it a few months ago, adding comments and reordering it,
> but got distracted by the socket code and switched to that.
> 

You can have the socket code :)

> Thanks,
>     John Labenski
> 

Talk to you again

Andre

Re: [wxlua-users] editor.wx.lua output problem

[John L. <jla...@gm...>]

On 12/5/06, Andre <ar...@ki...> wrote:
> I have been playing around with editor.wx.lua THIS IS A GREAT PROGRAM I just
> love it. I encountered the output to problem and tried to solve it.
>
> I am new to this Lua world, so this may be really wrong, but it seems to works.
>
> file wxLua\samples\editor.wx.lua
> line 1513
> from: local cmd = '"'..programName..'" '..'-c '..openDocuments[id].filePath
> ---
> to: local cmd = '"'..programName..'" '..openDocuments[id].filePath
>
> The ouputs goes to the console. Maybe this should be an option.

I have not looked too much at the console, doesn't this pop up a text
box to show the output in? It's a hack for MSW since usually stuff
printed to stdout goes nowhere. This would be a nice option though.

> I am planning to see if I can fix other related problems and maybe add some
> features. Should I report the changes here? Is anybody actively working on this
> editor?

That would be great. You can use the sourceforge patch tracker or just
post them here if they're small.

If you work on it could you use the CVS version of editor.wx.lua or at
least the most recent snapshot from the download page. I would
appreciate any fixes or enhancements.

I went through it a few months ago, adding comments and reordering it,
but got distracted by the socket code and switched to that.

Thanks,
    John Labenski

[wxlua-users] editor.wx.lua output problem

[Andre <ar...@ki...>]

I have been playing around with editor.wx.lua THIS IS A GREAT PROGRAM I just
love it. I encountered the output to problem and tried to solve it.

I am new to this Lua world, so this may be really wrong, but it seems to works.

file wxLua\samples\editor.wx.lua
line 1513
from: local cmd = '"'..programName..'" '..'-c '..openDocuments[id].filePath
---
to: local cmd = '"'..programName..'" '..openDocuments[id].filePath

The ouputs goes to the console. Maybe this should be an option.

I am planning to see if I can fix other related problems and maybe add some
features. Should I report the changes here? Is anybody actively working on this
editor? 

Andre

Re: [wxlua-users] A small bug in wxBitmapFromFile_constructor

[John L. <jla...@gm...>]

On 12/1/06, Pierric <sta...@gm...> wrote:
> Oh~ I see.
> I directly use solution file under build/msw instead of running
> "genwxbind.bat" first. That makes the bug!
> Thanks.

I'm not sure I understand what you mean, but to be sure. You only have
to run genwxbind.bat if you edit any of the *.i files. Any changes to
the generated files in modules/wxbind or modules/wxbindstc will get
overwritten by genwxbind.bat so the real permanent change has to go
into the *.i files or into the override file.

Hope this helps,
    John Labenski

Re: [wxlua-users] A small bug in wxBitmapFromFile_constructor

[Pierric <sta...@gm...>]

Oh~ I see.
I directly use solution file under build/msw instead of running "
genwxbind.bat" first. That makes the bug!
Thanks.

2006/11/30, John Labenski <jla...@gm...>:
>
> On 11/30/06, Pierric <sta...@gm...> wrote:
> > I recently find a small bug in wxbind/src/gdi.cpp,line 4193. Here is the
> > original code:
> > static int LUACALL wxBitmapFromFile_constructor(lua_State
> > *L)
> > {
> >    ....
> >     // call constructor
> >     returns = new wxBitmap(name, type);
> >     ...
> >     return 1;
> > }
> >
> > I changed to the following one :
> > returns = new wxBitmap(name, (wxBitmapType)type);
> >
> > The reason is that the wxBitmap have two different ctor wxBitmap(const
> > wxString&,wxBitmapType) and wxBitmap(const wxImage&,int depth,int depth)
> and
> > the second one is not implicit and the image can be constructed from a
> > string. So here comes the Bug.  The "new wxBitmap(name, type); " exactly
> > calls the second ctor instead the first one.
>
> Great thanks, I fixed it in the bindings/wxwidgets/gdi.i file by
> declaring the constructor as
>
>     %constructor wxBitmapFromFile(const wxString& name, wxBitmapType
> type = wxBITMAP_TYPE_ANY)
>
> with the added benefit that the default tries to determine the file
> type from the extension.
>
> Regards,
>     John Labenski
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

Re: [wxlua-users] A small bug in wxBitmapFromFile_constructor

[John L. <jla...@gm...>]

On 11/30/06, Pierric <sta...@gm...> wrote:
> I recently find a small bug in wxbind/src/gdi.cpp,line 4193. Here is the
> original code:
> static int LUACALL wxBitmapFromFile_constructor(lua_State
> *L)
> {
>    ....
>     // call constructor
>     returns = new wxBitmap(name, type);
>     ...
>     return 1;
> }
>
> I changed to the following one :
> returns = new wxBitmap(name, (wxBitmapType)type);
>
> The reason is that the wxBitmap have two different ctor wxBitmap(const
> wxString&,wxBitmapType) and wxBitmap(const wxImage&,int depth,int depth) and
> the second one is not implicit and the image can be constructed from a
> string. So here comes the Bug.  The "new wxBitmap(name, type); " exactly
> calls the second ctor instead the first one.

Great thanks, I fixed it in the bindings/wxwidgets/gdi.i file by
declaring the constructor as

    %constructor wxBitmapFromFile(const wxString& name, wxBitmapType
type = wxBITMAP_TYPE_ANY)

with the added benefit that the default tries to determine the file
type from the extension.

Regards,
    John Labenski

[wxlua-users] A small bug in wxBitmapFromFile_constructor

[Pierric <sta...@gm...>]

I recently find a small bug in wxbind/src/gdi.cpp,line 4193. Here is the
original code:
static int LUACALL wxBitmapFromFile_constructor(lua_State *L)
{
   ....
    // call constructor
    returns = new wxBitmap(name, type);
    ...
    return 1;
}

I changed to the following one :
returns = new wxBitmap(name, (wxBitmapType)type);

The reason is that the wxBitmap have two different ctor wxBitmap(const
wxString&,wxBitmapType) and wxBitmap(const wxImage&,int depth,int depth) and
the second one is not implicit and the image can be constructed from a
string. So here comes the Bug.  The "new wxBitmap(name, type); " exactly
calls the second ctor instead the first one.

Re: [wxlua-users] wxstedit linux not detected

[John L. <jla...@gm...>]

On 11/9/06, klaas.holwerda <kho...@xs...> wrote:
> After installing wxstedit, i did copy
> /usr/local/lib/libwx_gtk2d_stedit-2.7.a
> to libstedit.a  (the one there was old/release etc. )
>
> And that i think was all to make wxLua configure find it.

Ok good, something would have to be really wrong to get link errors
about wxAssert, but nothing else.

Regards,
    John Labenski

Re: [wxlua-users] wxstedit linux not detected

[klaas.holwerda <kho...@xs...>]

After installing wxstedit, i did copy 
/usr/local/lib/libwx_gtk2d_stedit-2.7.a
to libstedit.a  (the one there was old/release etc. )

And that i think was all to make wxLua configure find it.

klaas.holwerda wrote:
> configure:5978: checking if wxStEdit (version >= 1.2.0) is available
> configure:6011: g++ -o conftest  -g3 -O0 -Wall -Wundef 
> -Wno-ctor-dtor-privacy  
> -I/usr/local/lib/wx/include/gtk2-ansi-debug-static-2.7 
> -I/usr/local/include/wx-2.7 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES 
>   

[wxlua-users] wxstedit linux not detected

[klaas.holwerda <kho...@xs...>]

Hi John,

This is the error i get in config.log.
wxAssert linking error is in general a debug version problem.
I don't remember how i solved it the last time. Or if you made the 
changes already, so i report it again.

Its a static build of wxWidgets 2.7.2, with both debug and release 
installed.
Release installed the latest.

Klaas

configure:5978: checking if wxStEdit (version >= 1.2.0) is available
configure:6011: g++ -o conftest  -g3 -O0 -Wall -Wundef 
-Wno-ctor-dtor-privacy  
-I/usr/local/lib/wx/include/gtk2-ansi-debug-static-2.7 
-I/usr/local/include/wx-2.7 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES 
-D__WXDEBUG__ -D__WXGTK__  conftest.cc  -lstedit -L/usr/local/lib 
-pthread   /usr/local/lib/libwx_gtk2d_stc-2.7.a 
/usr/local/lib/libwx_gtk2d_xrc-2.7.a 
/usr/local/lib/libwx_gtk2d_html-2.7.a 
/usr/local/lib/libwx_gtk2d_adv-2.7.a 
/usr/local/lib/libwx_based_net-2.7.a 
/usr/local/lib/libwx_based_xml-2.7.a 
/usr/local/lib/libwx_gtk2d_core-2.7.a /usr/local/lib/libwx_based-2.7.a 
-lexpat -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 
-lm -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 
-lXinerama -lXxf86vm -lSM -lpng -ljpeg -ltiff -lz -ldl  >&5
/usr/local/lib/libstedit.a(stedit_lib_stedit.o): In function 
`wxSTEditor::SetLanguage(int)':
././src/stedit.cpp:3735: undefined reference to `wxAssert(int, char 
const*, int, char const*, char const*)'
/usr/local/lib/libstedit.a(stedit_lib_stedit.o): In function 
`wxSTEditor::GetFindFlags() const':
././src/stedit.cpp:3036: undefined reference to `wxAssert(int, char 
const*, int, char const*, char const*)'
/usr/local/lib/libstedit.a(stedit_lib_stedit.o): In function 
`wxSTEditor::GetReplaceString() const':
././src/stedit.cpp:3030: undefined reference to `wxAssert(int, char 
const*, int, char const*, char const*)'
/usr/local/lib/libstedit.a(stedit_lib_stedit.o): In function 
`wxSTEditor::GetFindString() const':
././src/stedit.cpp:3024: undefined reference to `wxAssert(int, char 
const*, int, char const*, char const*)'
/usr/local/lib/libstedit.a(stedit_lib_stedit.o): In function 
`wxSTEditor::ShowFindReplaceDialog(bool, bool)':././src/stedit.cpp:3042: 
undefined reference to `wxAssert(int, char const*, int, char const*, 
char const*)'
/usr/local/lib/libstedit.a(stedit_lib_stedit.o):././src/stedit.cpp:1008: 
more undefined references to `wxAssert(int, char const*, int, char 
const*, char const*)' follow
/usr/local/lib/libstedit.a(stedit_lib_stedit.o): In function 
`wxSTEditor::HandleFindDialogEvent(wxFindDialogEvent&)':