Thread: [Screem-devel] sitecopy update latest
Status: Inactive
Brought to you by:
davek
From: David A K. <da...@ri...> - 2000-07-29 13:03:12
|
Well its working with the updated sitecopy, after spending a lovely time sorting out the build process for libneon, Joe, why don't you use automake? its some much easier. I've only tested the ftp uploading so far so there are probably lots of little bugs still around. Incidently I've also fixed a bug with the excludes, and added support for the ignores and asciis I've also not done all the threading related stuff to the interface yet either. The changes are being commited now. David -- Make your site SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: Joe O. <jo...@or...> - 2000-07-29 16:41:58
|
On Sat, Jul 29, 2000 at 02:03:07PM +0100, David Knight wrote: > Well its working with the updated sitecopy, after spending a lovely time > sorting out the build process for libneon, Integrating neon should just require adding NEONOBJS to Makefile.in or configure.in and calling NEON_LIBRARY in configure.in. Maybe automake makes it harder... did this not work for you? > Joe, why don't you use automake? its some much easier. I don't see the need: I don't find my Makefile's complex or hard to maintain. Regards, joe |
From: David A K. <da...@ri...> - 2000-07-29 18:30:42
|
Joe Orton <jo...@or...> writes: > Integrating neon should just require adding NEONOBJS to Makefile.in or > configure.in and calling NEON_LIBRARY in configure.in. Maybe automake > makes it harder... did this not work for you? no, there we libtool issues which meant it didn't work like that, I just build a library from all the libneon src files, which causes *.lo to be built for each .c file. I then link those into the upload wizard > > Joe, why don't you use automake? its some much easier. > > I don't see the need: I don't find my Makefile's complex or hard to > maintain. Maybe, but automakes are even easier :-) David -- Make your site SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: Joe O. <jo...@or...> - 2000-07-29 23:19:08
|
On Sat, Jul 29, 2000 at 07:30:36PM +0100, David Knight wrote: > > Integrating neon should just require adding NEONOBJS to Makefile.in or > > configure.in and calling NEON_LIBRARY in configure.in. Maybe automake > > makes it harder... did this not work for you? > > no, there we libtool issues which meant it didn't work like that, I > just build a library from all the libneon src files, which causes *.lo > to be built for each .c file. I then link those into the upload wizard Okay. It seems a bit reduntant to build the .lo's and the .o's since only one of these are going to be used, I think? > > > Joe, why don't you use automake? its some much easier. > > > > I don't see the need: I don't find my Makefile's complex or hard to > > maintain. > > Maybe, but automakes are even easier :-) :) On this front... do you really mean to have the Makefile.in's under version control? And some Makefile's too... "cvs update" is a complete mess after changing my build flags from what the tree has. Generally it's a good idea to add generated files to .cvsignore and not keep them under version control at all. Good to have: Makefile.in Makefile POTFILES cat-id-tbl.c stamp-cat-id in po/.cvsignore too. joe |
From: Joe O. <jo...@or...> - 2000-07-29 23:22:17
|
On Sun, Jul 30, 2000 at 12:19:00AM +0100, Joe Orton wrote: > :) On this front... do you really mean to have the Makefile.in's under > version control? And some Makefile's too... "cvs update" is a complete > mess after changing my build flags from what the tree has. Generally > it's a good idea to add generated files to .cvsignore and not keep them > under version control at all. Sorry: I see Lee mentioned this already last month. FYI this output of "cvs update" gives a good indication of what still needs to be deleted: C aclocal.m4 M config.h.in M docs/Makefile.in M plugins/Makefile.in M plugins/colourWizard/Makefile.in M plugins/cssWizard/Makefile.in M plugins/entityWizard/Makefile.in C plugins/frameWizard/Makefile M plugins/frameWizard/Makefile.in M plugins/galleryWizard/Makefile.in M plugins/imageWizard/Makefile.in M plugins/linkWizard/Makefile.in M plugins/mailWizard/Makefile.in M plugins/ssiWizard/Makefile.in M plugins/tableWizard/Makefile.in M plugins/uploadWizard/Makefile.in M plugins/uploadWizard/common.h C po/cat-id-tbl.c C po/screem.pot C resources/Makefile M resources/Makefile.in C resources/Applets/Makefile M resources/Applets/Makefile.in C resources/Images/Makefile M resources/Images/Makefile.in C resources/Javascript/Makefile M resources/Javascript/Makefile.in C resources/PHP3/Makefile M resources/PHP3/Makefile.in M splash/Makefile.in Regards, joe |
From: David A K. <da...@ri...> - 2000-07-29 23:58:23
|
Joe Orton <jo...@or...> writes: > "cvs update" gives a good indication of what still needs to be deleted: right, those should all be sorted out now. If there are any others hiding, flush them out and I'll delete them as well. David -- Make your site SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: David A K. <da...@ri...> - 2000-07-29 23:26:47
|
Joe Orton <jo...@or...> writes: > On Sat, Jul 29, 2000 at 07:30:36PM +0100, David Knight wrote: > > no, there we libtool issues which meant it didn't work like that, I > > just build a library from all the libneon src files, which causes *.lo > > to be built for each .c file. I then link those into the upload wizard > > Okay. It seems a bit reduntant to build the .lo's and the .o's since > only one of these are going to be used, I think? well 1 is a symlink to the other with the screem build > > > > Joe, why don't you use automake? its some much easier. > > > > > > I don't see the need: I don't find my Makefile's complex or hard to > > > maintain. > > > > Maybe, but automakes are even easier :-) > > :) On this front... do you really mean to have the Makefile.in's under > version control? And some Makefile's too... "cvs update" is a complete > mess after changing my build flags from what the tree has. Generally > it's a good idea to add generated files to .cvsignore and not keep them > under version control at all. they should be in /CVSROOT/cvsignore, but some were in before I did this and they just haven't been removed yet. David -- Make your site SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: Joe O. <jo...@or...> - 2000-07-29 23:34:05
|
On Sun, Jul 30, 2000 at 12:26:40AM +0100, David Knight wrote: > > Okay. It seems a bit reduntant to build the .lo's and the .o's since > > only one of these are going to be used, I think? > > well 1 is a symlink to the other with the screem build Oh, mine didn't build like that :( I get separate .lo's compiled to .o's: joe@ankh:~/src/cvs/screem/libneon$ make /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I ../ -I ./ -D _GNU_SOURCE -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -Wall -Wno-unused -Wmissing-prototypes -Wmissing-declarations -I/usr/include/gnome-xml -Ilibneon -c base64.c rm -f .libs/base64.lo gcc -DHAVE_CONFIG_H -I. -I. -I.. -I ../ -I ./ -D _GNU_SOURCE -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -Wall -Wno-unused -Wmissing-prototypes -Wmissing-declarations -I/usr/include/gnome-xml -Ilibneon -Wp,-MD,.deps/base64.pp -c base64.c -fPIC -DPIC -o .libs/base64.lo gcc -DHAVE_CONFIG_H -I. -I. -I.. -I ../ -I ./ -D _GNU_SOURCE -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -Wall -Wno-unused -Wmissing-prototypes -Wmissing-declarations -I/usr/include/gnome-xml -Ilibneon -Wp,-MD,.deps/base64.pp -c base64.c -o base64.o >/dev/null 2>&1 joe |
From: Joe O. <jo...@or...> - 2000-07-29 17:08:23
|
libneon/sslcerts.c won't build, I haven't de-mutt-ified it yet: Index: Makefile.am =================================================================== RCS file: /cvsroot/screem/screem/libneon/Makefile.am,v retrieving revision 1.1 diff -u -p -r1.1 Makefile.am --- Makefile.am 2000/07/29 13:09:47 1.1 +++ Makefile.am 2000/07/29 17:04:11 @@ -3,12 +3,6 @@ INCLUDES = -I ../ -I ./ \ noinst_LTLIBRARIES = libneon.la -if ENABLE_SSL - EXTRA_SRC = sslcerts.c -else - EXTRA_SRC = "" -endif - libneon_la_SOURCES = "\ base64.c base64.h\ dates.c dates.h\ |
From: David A K. <da...@ri...> - 2000-07-29 18:25:51
|
David A Knight <da...@ri...> writes: > I've only tested the ftp uploading so far so there are probably lots > of little bugs still around. Well, I've just built mod-dav for Apache and the webdav uploading also works nicely. I've also implemented the threading, again with a lot of cut/paste from Lee's Gnome frontend for Sitecopy. 1 point on the threading Lee: gdk_threads_enter(); gtk_main(); gdk_threads_leave(); will cause a lockup, removing the threads_enter/leave calls and everything still appears to work fine. David -- Make your site SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: Lee M. <le...@fo...> - 2000-07-30 13:16:21
|
> David A Knight <da...@ri...> writes: > > > I've only tested the ftp uploading so far so there are probably lots > > of little bugs still around. > I've also implemented the threading, again with a lot of cut/paste from > Lee's Gnome frontend for Sitecopy. I can't remember how well sync'ed my xsitecopy code was with sitecopy by the 0.10.0 release... As I mentioned before, I've had plenty of system issues. I've now got them all sorted, (it's amazing what a clean win98 install, a clean mandrake 7.1 install, and a new graphics card can do for system performance:). So I'll check out screem from cvs shortly and start trying to get myself back up to date on the state of things. Speaking of threading - does the upload wizard now run properly on a separate thread? I know it was done *really* badly (the same as xsitecopy) when I first integrated it so that it pthread_join'ed on the upload thread... I recently sorted almost all that out for xsitecopy, however with the new sitecopy API I had major trouble with fe_login() calls. I was using a blocking dialog (gnome_dialog_run_and_close()) and the whole app then just froze up/died when a call to fe_login was made... Have you tested an upload when user/pass aren't specified David? I'd be interested to see your results if you have, as then xsitecopy/screem will be all the better from that. :) > 1 point on the threading Lee: > > gdk_threads_enter(); > gtk_main(); > gdk_threads_leave(); > > will cause a lockup, removing the threads_enter/leave calls and everything > still appears to work fine. Surely that has real problems though - if you're running a thread-aware gtk main loop but that loop doesn't have a lock, aren't all sorts of weird race conditions going to crop up? Or are you talking about embedded calls to gtk_main() ? That was one of my main problems with fe_login in the gnome sitecopy front end - I wasn't sure whether a call to gtk_threads_enter() was necessary before the gnome_dialog_run_and_close() call... Cheers, Lee. |
From: David A K. <da...@ri...> - 2000-07-30 13:39:19
|
"Lee Mallabone" <le...@fo...> writes: > Speaking of threading - does the upload wizard now run properly on a > separate thread? I know it was done *really* badly (the same as xsitecopy) > when I first integrated it so that it pthread_join'ed on the upload > thread... It does seem to run properly yes, although there is a problem if there is an error in uploading the site, at least with the rshdriver. > I recently sorted almost all that out for xsitecopy, however with the new > sitecopy API I had major trouble with fe_login() calls. I was using a > blocking dialog (gnome_dialog_run_and_close()) and the whole app then just > froze up/died when a call to fe_login was made... Have you tested an upload > when user/pass aren't specified David? I'd be interested to see your results > if you have, as then xsitecopy/screem will be all the better from that. :) I've just tried it, and I get the same problem that occurs when a site fails for some reason, without the dialog appearing. It all runs nicely if there are no problems though :-) > > 1 point on the threading Lee: > > > > gdk_threads_enter(); > > gtk_main(); > > gdk_threads_leave(); > > > > will cause a lockup, removing the threads_enter/leave calls and everything > > still appears to work fine. > > Surely that has real problems though - if you're running a thread-aware gtk > main loop but that loop doesn't have a lock, aren't all sorts of weird race > conditions going to crop up? yes but if the main loop is in the gdk_threads_enter, then no other section can enter it until gdk_threads_leave is called, which causes the wait on the gdk_threads_mutex. > Or are you talking about embedded calls to gtk_main() ? That was one of my > main problems with fe_login in the gnome sitecopy front end - I wasn't sure > whether a call to gtk_threads_enter() was necessary before the > gnome_dialog_run_and_close() call... I'm not sure what I'm talking about :-) The behaviour I experienced was a lock up when the main display tried to appear, the window appeared, but did not redraw, and the reason I mention above is the only thing I can think of causing it. David -- Make your site SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: David A K. <da...@ri...> - 2000-07-30 14:04:53
|
David A Knight <da...@ri...> writes: > I've just tried it, and I get the same problem that occurs when a site > fails for some reason, without the dialog appearing. It all runs nicely > if there are no problems though :-) OK, I've fixed the problem, I was missing a gdk_threads_enter() before the gnome_warning_dialog which caused a crash. The fe_login doesn't seem to be getting called though, it just end up with a dialog saying there was an authentication problem. (FTP driver) David -- Make your site SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: David A K. <da...@ri...> - 2000-07-30 14:15:40
|
David A Knight <da...@ri...> writes: > David A Knight <da...@ri...> writes: > > > I've just tried it, and I get the same problem that occurs when a site > > fails for some reason, without the dialog appearing. It all runs nicely > > if there are no problems though :-) > > OK, I've fixed the problem, I was missing a gdk_threads_enter() before > the gnome_warning_dialog which caused a crash. > > The fe_login doesn't seem to be getting called though, it just end up with > a dialog saying there was an authentication problem. (FTP driver) Ah, a good reason why it didn't I wasn't checking the username and password were actually > 0 length so they were non null which meant that fe_login wasn't called. Now the problem that arises is: GLib-WARNING **: g_main_run(): called recursively from within a source's check() or prepare() member or from a second thread, iteration not possible which I suspect is the problem you had Lee. I guess its time to use a quick hack that I used to use on dialogs before I knew of gnome_dialog_run. David -- Make your site SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: David A K. <da...@ri...> - 2000-07-30 23:54:56
|
"Lee Mallabone" <le...@fo...> writes: > I recently sorted almost all that out for xsitecopy, however with the new > sitecopy API I had major trouble with fe_login() calls. I was using a > blocking dialog (gnome_dialog_run_and_close()) and the whole app then just > froze up/died when a call to fe_login was made... Have you tested an upload > when user/pass aren't specified David? I'd be interested to see your results > if you have, as then xsitecopy/screem will be all the better from that. :) I've got some good news for you, check out the latest CVS code, fe_login() is now working nicely. Instead of gnome_dialog_run_and_close() it simply connects the close and clicked callbacks of the dialog, then calls sem_wait() The callbacks call sem_post() after setting a global variable containing the value of the button pressed if any. David -- Make your site SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |