wxlua-users Mailing List for wxLua (Page 3)

On Jan 18, 2008 2:20 PM, John Labenski <jla...@gm...> wrote:

> Ok, I'm convinced.
>
> After the next release I will do it, but first we need to get a
> monolithic build working and whatever else there was to do that I've
> forgotten.
>

Sounds good. Again I can't thank you enough for all your hard work. I just
keep asking for things and you keep adding them. That is rare, so thanks!
-- 
Regards,
Ryan

On Jan 18, 2008 6:05 AM, Rob Kendrick <rj...@rj...> wrote:
>
> On Thu, 2008-01-17 at 21:00 -0500, John Labenski wrote:
>
> > Sounds like an interesting project. However, I am not sure exactly
> > what people are to do with their branches as I would hope that useful
> > additions and certainly all bug fixes should go back to the main
> > version.
>
> If people fix a bug using it, they can have bzr produce a diff or bundle
> of their changes to send to other bzr users: perhaps even somebody who
> then applies it to the official CVS.
>
> I've set this up as my project will require some (small) changes to
> wxLua that are not applicable or appropriate for other people.  Having a
> bzr branch lets me keep my changes while still benefiting from the
> changes in CVS without a whole lot of manual patch management.

Sounds good.

> > In terms of wxLua going to Subversion, yes, someday. I'm sorry that
> > I'm dragging my feet on it, but I am no expert in CVS, but I can make
> > do. I am suspicious of svn since it appears as though you download the
> > whole repository with a checkout which I see as a waste of disk space
> > and when you grep for things you're inundated with garbage from the
> > old versions.
>
> This is not the case.  A subversion checkout contains no history.  What
> it does do is keep unmodified versions of every versioned-controlled
> file in a .svn directory for doing fast local and off-line diffs without
> having to talk to the server.  This basically means the cost of a
> checkout is very slightly over twice the size of the data stored in it.
>
> (Also, bzr branches (rather than checkouts) do include all the history,
> which is a requirement of its distributed nature - but you can do a
> "lightweight" checkout which is similar to an svn checkout, in that it
> requires you to be connected to make any commits.)
>
> > I guess I could make a script wrapper for grep to avoid
> > the .svn/ dirs. In any case I'm not convinced that svn is any better,
> > except that you can use the http protocol.
>
> Subversion is bags quicker, has atomic commits, can version things more
> than just files, better handling of binary files, more efficient
> server-side storage, finer-grained and more flexible authentication and
> permissions, vastly superior history tracking, cheap branching and is
> still actually being maintained.  And that's just a start.

Ok, I'm convinced.

After the next release I will do it, but first we need to get a
monolithic build working and whatever else there was to do that I've
forgotten.

Regards,
    John

On Jan 18, 2008 5:49 PM, John Labenski <jla...@gm...> wrote:

> Humm. I don't know how to fix it since when I've verified that the
> line endings are CRLF and then commit, CVS says that nothing has
> changed.
>

I still suspect that your tools work in "UNIX" mode and when CRLF is stored
by them, and then fetched by my  "Windows" mode tools the files end
up ending CRCRLF (If checked in with Windows mode tools,  I think the
files would be normalized to LF ending style in the repository)


I just did a clean fetch for one of the makefiles and looked at it with cygwin
cat -A

this is how it looks like:

^M^M$
# C++ compiler ^M^M$
CXX = cl^M^M$
^M^M$

with a cleaned up makefile I get:

^M$
# C++ compiler ^M$
CXX = cl^M$
^M$

One idea, maybe you should try converting the
makefile.vc to Unix style (only LF) and then
try checking it it?

(or use for example the cvsnt version of cvs tools
and the CRLF version of the files)


  Eero

On Jan 18, 2008 6:05 AM, Rob Kendrick <rj...@rj...> wrote:

> > In terms of wxLua going to Subversion, yes, someday. I'm sorry that
> > I'm dragging my feet on it, but I am no expert in CVS, but I can make
> > do. I am suspicious of svn since it appears as though you download the
> > whole repository with a checkout which I see as a waste of disk space
>

This is not the case at all. You should adhere to a trunk, tags, and
branches mentality and you only get the exact code you have now. IMHO it
promotes much better Software Engineer practices, letting you have a latest
version that always builds, plus then a branch where, for example, you can
iron out all the build file problems.


> Subversion is bags quicker, has atomic commits, can version things more
> than just files, better handling of binary files, more efficient
> server-side storage, finer-grained and more flexible authentication and
> permissions, vastly superior history tracking, cheap branching and is
> still actually being maintained.  And that's just a start.
>

I have to agree here. Subversion is a very good version control solution and
it will seem familiar to CVS users. It also has a very powerful feature
called "externals". They allow checkout from other locations during the main
checkout of a persons project. You can actually "external" wxLua in your
project and it will get the latest changes when ever you update. I am
glossing over this feature, but it is also great and useful for all
developers.
-- 
Regards,
Ryan

On Jan 18, 2008 4:14 AM, Eero Pajarre <epa...@gm...> wrote:
> On Jan 18, 2008 3:46 AM, John Labenski <jla...@gm...> wrote:
> >
> > I think this is a problem on your side. I use cygwin in MSW and all
> > the line endings are CRLF in the makefile.vc files.
> >
>
> I did a new repository using Cygwin and yes there the line-ends are
> CRLF. The odd thing is that my Cygwin is set to using UNIX line-ends
> (as recommended in Cygwin installer) and for example all the .cpp
> files have just LF line-ends. So makefile.vc  seems to be different
> also there.

I make a dir call /mnt/c/ and then run "$mount -t c:/ /mnt/c" and do
all my work from that path instead of /cygdrive/c so it uses CRLF.

> also I see in:
> http://wxlua.cvs.sourceforge.net/wxlua/wxLua/build/msw/makefile.vc?view=log
> that 1.50 version apparently changed every line in Makefile.vc,
> but when I look at the Diff to 1.49 link there are only two changed lines

Humm. I don't know how to fix it since when I've verified that the
line endings are CRLF and then commit, CVS says that nothing has
changed.

> The previous rebake commands have always created significantly smaller
> changed files -sets.
>
> (Yes, I would like to continue using WinCVS, it has served me well for years.)
>
> I found that as well, using Tortoise CVS. Deleting everything and
re-downloading seemed to fix it.
>

So, it's all fixed for you now or is WinCVS still not working?

Regards,
    John

I found that as well, using Tortoise CVS. Deleting everything and 
re-downloading seemed to fix it.

Les

Eero Pajarre wrote:
> For some reason I get "interesting" line end problems
> with different makefile.vc files from the CVS.
> (This did not happen with the versions around 2007-12-22)
>
>   

IMHO requires are a PITA. You then have the hassle of trying to figure 
out what which libs you need to require. I am sure everyone here has 
spent time scratching their head trying to figure out just what lib they 
have forgotten to include when their app won't compile/run. One fairly 
common solution is to 'shotgun' and require everything, defeating the 
object of requires in the first place.

A single shared lib with all bindings sounds good to me.

Les


John Labenski wrote:
> Ok, one thing at a time, but I think we almost have everything else
> working, but we'll only know that when people try it.
>
> For the monolithic build:
>
> How do you envision it? A single shared library with wxLua and all the
> bindings? I assume this is so that wx.so/dll is just a single file.
> Or?
>
> Note: The wxLua libraries were separated since wxPython (for good or
> bad) separates them, but goes even further by making you import each
> library and even classes, "import wx; import wx.lib.docview" for
> example.
>
> Would wxLua like to have to have in addition to wx.so, wxlua.so,
> wxlua_base.so, wxlua_core.so, wxlua_xxx so you can "require" only the
> bits you really want.
>
> Regards,
>     John
>   

On Thu, 2008-01-17 at 21:00 -0500, John Labenski wrote:

> Sounds like an interesting project. However, I am not sure exactly
> what people are to do with their branches as I would hope that useful
> additions and certainly all bug fixes should go back to the main
> version.

If people fix a bug using it, they can have bzr produce a diff or bundle
of their changes to send to other bzr users: perhaps even somebody who
then applies it to the official CVS.

I've set this up as my project will require some (small) changes to
wxLua that are not applicable or appropriate for other people.  Having a
bzr branch lets me keep my changes while still benefiting from the
changes in CVS without a whole lot of manual patch management.

> In terms of wxLua going to Subversion, yes, someday. I'm sorry that
> I'm dragging my feet on it, but I am no expert in CVS, but I can make
> do. I am suspicious of svn since it appears as though you download the
> whole repository with a checkout which I see as a waste of disk space
> and when you grep for things you're inundated with garbage from the
> old versions. 

This is not the case.  A subversion checkout contains no history.  What
it does do is keep unmodified versions of every versioned-controlled
file in a .svn directory for doing fast local and off-line diffs without
having to talk to the server.  This basically means the cost of a
checkout is very slightly over twice the size of the data stored in it.

(Also, bzr branches (rather than checkouts) do include all the history,
which is a requirement of its distributed nature - but you can do a
"lightweight" checkout which is similar to an svn checkout, in that it
requires you to be connected to make any commits.)

> I guess I could make a script wrapper for grep to avoid
> the .svn/ dirs. In any case I'm not convinced that svn is any better,
> except that you can use the http protocol.

Subversion is bags quicker, has atomic commits, can version things more
than just files, better handling of binary files, more efficient
server-side storage, finer-grained and more flexible authentication and
permissions, vastly superior history tracking, cheap branching and is
still actually being maintained.  And that's just a start.

B.

On Jan 18, 2008 3:46 AM, John Labenski <jla...@gm...> wrote:
>
> I think this is a problem on your side. I use cygwin in MSW and all
> the line endings are CRLF in the makefile.vc files.
>

I did a new repository using Cygwin and yes there the line-ends are
CRLF. The odd thing is that my Cygwin is set to using UNIX line-ends
(as recommended in Cygwin installer) and for example all the .cpp
files have just LF line-ends. So makefile.vc  seems to be different
also there.


also I see in:
http://wxlua.cvs.sourceforge.net/wxlua/wxLua/build/msw/makefile.vc?view=log
that 1.50 version apparently changed every line in Makefile.vc,
but when I look at the Diff to 1.49 link there are only two changed lines
(The cd command related to doxygen is probably broken here....)
The difference between the changed lines and the diff show
could be caused by a "whitespace" change which is ignored but the
WWW-diff, and the end of line change could be such.

The previous rebake commands have always created significantly smaller
changed files -sets.

(Yes, I would like to continue using WinCVS, it has served me well for years.)


   Eero

On Jan 17, 2008 8:46 PM, John Labenski <jla...@gm...> wrote:
> > I also added the following to the build/msw/makefile.vc
> >
> > ----------------------
> > # This is an advanced option. Handle with care.
> > # The thread model to use: use 'multi' default to allow
> > # multi-threading. [multi,single]
> > THREADING = multi
> > -----------------------------
>
> This is a known problem, I think it has something to do with the new
> version of Bakefile that we are using, but I would like Francesco to
> confirm it as I he is familiar with the source code for Bakefile.
>

Fixed in CVS by forcing it in bakefile with
<set var="VARS_DONT_ELIMINATE" append="1">THREADING</set>
in build/bakefiles/options.bkl.

Regards,
    John

On Jan 17, 2008 6:17 PM, Eero Pajarre <epa...@gm...> wrote:
> Thanks, I am still working on my "updating wxLua version" project.
> (among other things...) For certain reasons I need to keep my
> application compatible with some wxLua scripts from
> older versions. I first did this by using Lua code to redefine
> or add the missing functions, but then changed to doing
> on the fly text replace operations to the code parts.

I don't think there will be any drastic changes to the Lua code for
wxLua anymore as I am now happy with how things work.

> This change should make it a little cleaner.
> BTW. Did your change also affect wxChoice, I guess
> it had the same issues?

Yes, all of the controls that take wxArrayStrings were affected and
are now fixed.

Regards,
    John

On Jan 17, 2008 4:40 PM, Rob Kendrick <rj...@rj...> wrote:
> For those whom it floats such boats, I have created a wxLua project on
> Launchpad.net for the express purpose of having Launchpad create a bzr
> branch from wxLua's CVS repository for people to branch from for doing
> work on the project.  You can find it here:
>
>         https://launchpad.net/wxlua/trunk
>
> I'm currently set as the project's owner.  If somebody in an official
> capacity wants to take that over, just give me a shout.
>

Sounds like an interesting project. However, I am not sure exactly
what people are to do with their branches as I would hope that useful
additions and certainly all bug fixes should go back to the main
version.

In terms of wxLua going to Subversion, yes, someday. I'm sorry that
I'm dragging my feet on it, but I am no expert in CVS, but I can make
do. I am suspicious of svn since it appears as though you download the
whole repository with a checkout which I see as a waste of disk space
and when you grep for things you're inundated with garbage from the
old versions. I guess I could make a script wrapper for grep to avoid
the .svn/ dirs. In any case I'm not convinced that svn is any better,
except that you can use the http protocol.

Regards,
    John


Regards,
    John

On Jan 17, 2008 7:05 PM, Eero Pajarre <epa...@gm...> wrote:
> After fixing the line ends in my copy

I think this is a problem on your side. I use cygwin in MSW and all
the line endings are CRLF in the makefile.vc files.

> I also added the following to the build/msw/makefile.vc
>
> ----------------------
> # This is an advanced option. Handle with care.
> # The thread model to use: use 'multi' default to allow
> # multi-threading. [multi,single]
> THREADING = multi
> -----------------------------

This is a known problem, I think it has something to do with the new
version of Bakefile that we are using, but I would like Francesco to
confirm it as I he is familiar with the source code for Bakefile.

Regards,
    John

After fixing the line ends in my copy
I also added the following to the build/msw/makefile.vc

----------------------
# This is an advanced option. Handle with care.
# The thread model to use: use 'multi' default to allow
# multi-threading. [multi,single]
THREADING = multi
-----------------------------


This is needed when using static runtime libraries.
(I compile my application with dynamic libs for better debugging support,
 but with static libs for release builds. I don't want to distribute
crt-dll files
with my application)


Now my wxlua compilation seems to work again.

  Eero

On Thu, 2008-01-17 at 18:04 -0500, Ryan Pusztai wrote:

> Does LaunchPad update from CVS all the time? Is it done nightly or
> every ** minutes? 

I don't know.  It doesn't check every 5 minutes or anywhere near as
frequently: I've seen projects who havn't had their CVS updated in
hours.  I do not know if the time it waits before rechecking varies
depending on how much activity there has been recently.

> Can anybody "push" to LaunchPad? 

Not to the "trunk" which has been created.  You can have Launchpad host
branches for you that only you can push to, though.  I don't know how
advanced the access controls are here.

> Do you recommend any particular GUI for Windows? I already have stuff
> setup for Ubuntu ;-). 

Sorry, I don't develop under Windows.  There might be details on bzr's
web site, though.

B.

For some reason I get "interesting" line end problems
with different makefile.vc files from the CVS.
(This did not happen with the versions around 2007-12-22)


I am using WinCVS, but it has usually worked fine,
returning text files as proper (windows compliant)  text files.

Now the makefile.vc files do not seem to end with the
CRLF characters which are expected on windows,
instead there seems to be several CR?  (0x0d)
characters,  which confuses some of my file-end fixing
tricks.

Could somebody else check the state of these files.

in directories
build/msw
apps/build/msw
modules/buld/msw
and maybe others?

 Eero

Thanks, I am still working on my "updating wxLua version" project.
(among other things...) For certain reasons I need to keep my
application compatible with some wxLua scripts from
older versions. I first did this by using Lua code to redefine
or add the missing functions, but then changed to doing
on the fly text replace operations to the code parts.

This change should make it a little cleaner.
BTW. Did your change also affect wxChoice, I guess
it had the same issues?


    Eero

ps. I am now experiencing some problems with makefile.vc files, but I
will send a separate email regarding that.

On Jan 17, 2008 5:56 PM, Rob Kendrick <rj...@rj...> wrote:

> Bazaar is a distributed version control system.  You can branch
> remotely-stored branches that you don't have write-access to, work on
> your local branch, push your changes else where or back to the original
> author, etc.  It can fetch from a simple HTTP server (no modules or
> webdav needed) and push back to anything it can use to write files (alas
> not HTTP PUT, however.)  I use sftp, which is built atop of SSH.  The
> way Launchpad works is it only reads from CVS: it doesn't write to it.
>
> It also does not require you to be connected to the internet to make
> changes: you can commit to your local branch.  When you push to another
> branch (such as one stored on a server) you get the opportunity to
> merge.
>
> Bazaar can directly branch from Subversion too (but not CVS, alas), so
> if you wanted to do some disconnected work, you could do this:
>        bzr branch svn://foo/bar
>        <disconnect from internet>
>        <edit some files>
>        bzr commit -m "message"
>        <edit some more>
>        bzr commit -m "message"
>        <connect to internet>
>        bzr push svn://foo/bar
>
> http://doc.bazaar-vcs.org/bzr-0.9/tutorial.html has an excellent
> tutorial that pretty much shows everything you'd need to know.
>

Does LaunchPad update from CVS all the time? Is it done nightly or every **
minutes? Can anybody "push" to LaunchPad? Do you recommend any particular
GUI for Windows? I already have stuff setup for Ubuntu ;-).
-- 
Regards,
Ryan

On Thu, 2008-01-17 at 17:43 -0500, Ryan Pusztai wrote:
> Can you expand on this a bit. I am not a Bazaar user, but I can't use
> CVS from work and Bazaar looks like it can use SSH and http and that
> is great. Can anybody make changes to the code? Do the changes get
> filtered down to the CVS? Do you branch and then do what ever you want
> to the code? Can you give me a quick run down on daily activities?

Bazaar is a distributed version control system.  You can branch
remotely-stored branches that you don't have write-access to, work on
your local branch, push your changes else where or back to the original
author, etc.  It can fetch from a simple HTTP server (no modules or
webdav needed) and push back to anything it can use to write files (alas
not HTTP PUT, however.)  I use sftp, which is built atop of SSH.  The
way Launchpad works is it only reads from CVS: it doesn't write to it.

It also does not require you to be connected to the internet to make
changes: you can commit to your local branch.  When you push to another
branch (such as one stored on a server) you get the opportunity to
merge.

Bazaar can directly branch from Subversion too (but not CVS, alas), so
if you wanted to do some disconnected work, you could do this:
	bzr branch svn://foo/bar
	<disconnect from internet>
	<edit some files>
	bzr commit -m "message"
	<edit some more>
	bzr commit -m "message"
	<connect to internet>
	bzr push svn://foo/bar

http://doc.bazaar-vcs.org/bzr-0.9/tutorial.html has an excellent
tutorial that pretty much shows everything you'd need to know.

B.

On Jan 17, 2008 4:40 PM, Rob Kendrick <rj...@rj...> wrote:

> For those whom it floats such boats, I have created a wxLua project on
> Launchpad.net for the express purpose of having Launchpad create a bzr
> branch from wxLua's CVS repository for people to branch from for doing
> work on the project.  You can find it here:
>
>        https://launchpad.net/wxlua/trunk
>
> I'm currently set as the project's owner.  If somebody in an official
> capacity wants to take that over, just give me a shout.
>

Can you expand on this a bit. I am not a Bazaar user, but I can't use CVS
from work and Bazaar looks like it can use SSH and http and that is great.
Can anybody make changes to the code? Do the changes get filtered down to
the CVS? Do you branch and then do what ever you want to the code? Can you
give me a quick run down on daily activities?

John,
There had been talk about moving to Subversion, are there any plans? Once
things settle with the build system.
-- 
Regards,
Ryan

On Jan 17, 2008 1:39 PM, Eero Pajarre <epa...@gm...> wrote:
> I dont really get why wxListBox with two parameters is not accepted
> with wxLua. It was accepted on some previous version, and it
> looks like that wxWidgets library would accept two parameter version.
>
> Specifically
> -----test.lua---
> frame=wx.wxFrame(wx.NULL,-1,"Test",wx.wxPoint(-1,-1),wx.wxSize(800,600));
> lb=wx.wxListBox(frame,-1)
> ------------------
>
> causes:
>
> test.lua:2: wxLua: Function call has invalid arguments.Function
> called: 'wxListBox(wxFrame, number)'
> 01. wxListBox::wxListBox(wxWindow, number, wxPoint [, wxSize,
> wxArrayString, number, wxValidator, string])
> 02. wxListBox::wxListBox()
> stack traceback:
>         [C]: in function 'wxListBox'
>         test.lua:2: in main chunk
>
> I have tried to follow where the problem starts, and currently I am
> starting to suspect
> genwxbind.lua .....
>

No, it was actually the bindings themselves. I had changed from using
the old style "int count, wxString* items" to "const wxArrayString&
items", but since the C++ version requires you to input "wxWindow, id,
pos, size, wxArrayString, ..." I didn't remove the defaults for pos
and size or as I've done now added a suitable default value for the
wxArrayString.

Should work with only two inputs now.

Thanks,
     John

On Jan 17, 2008 1:36 PM, John Labenski <jla...@gm...> wrote:

> On Jan 17, 2008 1:27 PM, Rob Kendrick <rj...@rj...> wrote:
> > I'd like to see just one DSO containing all the bindings that you can
> > just do 'require "wx"' from inside a standard Lua interpreter.  Just one
> > file you can put along side. (Excluding the WxWidgets DSOs themselves,
> > obviously: although I suppose the bindings could statically link to them
> > too, although that's not an option for me as Ubuntu doesn't come with
> > static versions, but that's outside your control.)
>

I agree with this. I have build files for wx.dll/so linked against the
monolithic wxWidgets dll/so (if it is available in wx-config for Linux) This
would be so great.
-- 
Regards,
Ryan

For those whom it floats such boats, I have created a wxLua project on
Launchpad.net for the express purpose of having Launchpad create a bzr
branch from wxLua's CVS repository for people to branch from for doing
work on the project.  You can find it here:

	https://launchpad.net/wxlua/trunk

I'm currently set as the project's owner.  If somebody in an official
capacity wants to take that over, just give me a shout.

B.

I dont really get why wxListBox with two parameters is not accepted
with wxLua. It was accepted on some previous version, and it
looks like that wxWidgets library would accept two parameter version.

Specifically
-----test.lua---
frame=wx.wxFrame(wx.NULL,-1,"Test",wx.wxPoint(-1,-1),wx.wxSize(800,600));
lb=wx.wxListBox(frame,-1)
------------------

causes:

test.lua:2: wxLua: Function call has invalid arguments.Function
called: 'wxListBox(wxFrame, number)'
01. wxListBox::wxListBox(wxWindow, number, wxPoint [, wxSize,
wxArrayString, number, wxValidator, string])
02. wxListBox::wxListBox()
stack traceback:
	[C]: in function 'wxListBox'
	test.lua:2: in main chunk

I have tried to follow where the problem starts, and currently I am
starting to suspect
genwxbind.lua .....


     Eero

On Thu, 2008-01-17 at 13:27 -0500, John Labenski wrote:
> Have you had a chance to investigate this, yet?  It's not a show-stopper
> > for me, but it would reduce the complexity of my build system.
> 
> Thanks for reminding me, I had forgotten. I put %wxchkver_2_8_6 in
> front of them in CVS.

Works a treat.  Ta.

B.