-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Comment By: Enrico Tröger (eht16)
Completely unrelated to Geany. HTTP usually doesn't support write operations, right? So how do you want to write files to it or even mount it?
Opening a file through HTTP works with g_file_new_for_uri(), but yes, write operations will fail.
Instead, use dav:// assuming your server supports it. Then you can mount it as usual and after having mounted it, you can open and edit files on it.
I dunno how to do it "as usual" since I use Nautilus 2.22 for now that AFAIK doesn't really support GIO, and I dunno how to mount a location with GVFS without Nautilus… But yes, I understand the meaning :)
Yes, that's the way. And when we save the file in Geany, we set an ignore flag to ignore the next 'file has changed' signal. And there probably begin the problems. Also, this works only if the file was actually only changed which happens when saving with Geany. When you save the file with Gedit, it (probably) won't work because Gedit first saves the file into a temp file, then move it to the real file. So, the real file is never 'changed' but 'created'. And the 'created' notification is currently ignored at all.
Hum… I've just tried with Gedit modifying an opened file in Geany, and the tab becomes orange, but when I start to modify it again, Geany tells me that the file was not found on the disk, asking me whether I want to save it… and if I say yes, then ask me if I want to overwrite the existing file. Well, not perfect (but I personally don't mind about that since this feature helps me mostly for files modified by a script).
This doesn't really explain your problems, I think. But is one of the things I meant when saying 'not yet 100% functional'. Let me give it another try tomorrow and in the meantime just revert to before r3484 :).
OK, I see. And yes, just take the time you need and let us (me?) know when we can test your new efforts :)
Too bad, I hoped there was something real exotic which would explain the behaviour :).
Hey no, sorry :D
P.S.: quoting in the tracker is awful. Moving to the mailing list?
Yeah, great idea!
Just ask me if you need any other test or information.
Regards, Colomban
Colomban Wendling wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Comment By: Enrico Tröger (eht16)
Completely unrelated to Geany. HTTP usually doesn't support write operations, right? So how do you want to write files to it or even mount it?
Opening a file through HTTP works with g_file_new_for_uri(), but yes, write operations will fail.
Instead, use dav:// assuming your server supports it. Then you can mount it as usual and after having mounted it, you can open and edit files on it.
I dunno how to do it "as usual" since I use Nautilus 2.22 for now that AFAIK doesn't really support GIO, and I dunno how to mount a location with GVFS without Nautilus… But yes, I understand the meaning :)
Yes, that's the way. And when we save the file in Geany, we set an ignore flag to ignore the next 'file has changed' signal. And there probably begin the problems. Also, this works only if the file was actually only changed which happens when saving with Geany. When you save the file with Gedit, it (probably) won't work because Gedit first saves the file into a temp file, then move it to the real file. So, the real file is never 'changed' but 'created'. And the 'created' notification is currently ignored at all.
Hum… I've just tried with Gedit modifying an opened file in Geany, and the tab becomes orange, but when I start to modify it again, Geany tells me that the file was not found on the disk, asking me whether I want to save it… and if I say yes, then ask me if I want to overwrite the existing file. Well, not perfect (but I personally don't mind about that since this feature helps me mostly for files modified by a script).
This doesn't really explain your problems, I think. But is one of the things I meant when saying 'not yet 100% functional'. Let me give it another try tomorrow and in the meantime just revert to before r3484 :).
OK, I see. And yes, just take the time you need and let us (me?) know when we can test your new efforts :)
Too bad, I hoped there was something real exotic which would explain the behaviour :).
Hey no, sorry :D
P.S.: quoting in the tracker is awful. Moving to the mailing list?
Yeah, great idea!
Just ask me if you need any other test or information.
Regards, Colomban -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkl1BcIACgkQyqbACDEjVWhKpACg3Z8Z3cpGhLD6ZnrMYOpbFwTh mD4AoIZvuldC/BPFpYraJmg+/o+GuRCe =kOgp -----END PGP SIGNATURE-----
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hello, sorry if this bug is too plain andi am wasting your time, but i really try to help ;) Now back to the topic...i try with make distclean, make clean all and this has no effect. I`m not have running gam or fam. Gvfs things on my computer is 1.0.2-0ubuntu1 version, Gnome version is 2.24.1, Geany is svn r3490, GTK+ 2.14.4, GLib 2.18.2 I edited only local files and filesystem is also ext3 :)
Ddb don`t find nothing trouble... We reports bugs and use svn version`s becouse really want to help...now im learning C and Gtk things and i think Geany is my exactly programming model :)
P.S. Geany is still my favorite editor...and i don`t like shits like zend,net beans and other`s java like things...:)
Just ask and me, if you need test for something ;)
Regards, Atanas Beloborodov Practitioner a.beloborodov@viscomp.bg mailto:a.beloborodov@viscomp.bg Mobile: +359 896 733 612
*Viscomp EOOD* 92V "Hristo Botev" Blvd 4000 Plovdiv Bulgaria Tel: +359 32 655 175 Fax: +359 32 655 176 www.viscomp.bg http://www.viscomp.bg
On Mon, 19 Jan 2009 23:59:15 +0100, Colomban Wendling ban-ubuntu@club-internet.fr wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Comment By: Enrico Tröger (eht16)
Completely unrelated to Geany. HTTP usually doesn't support write operations, right? So how do you want to write files to it or even mount it?
Opening a file through HTTP works with g_file_new_for_uri(), but yes, write operations will fail.
Btw, gvfs-cat http://host.tld/file will show the contents of the URI. Similarly, gvfs-copy will copy it to a file. Both are similar to what 'wget' does but after all, unrelated to Geany :).
Instead, use dav:// assuming your server supports it. Then you can mount it as usual and after having mounted it, you can open and edit files on it.
I dunno how to do it "as usual" since I use Nautilus 2.22 for now that AFAIK doesn't really support GIO, and I dunno how to mount a location with GVFS without Nautilus… But yes, I understand the meaning :)
You can easily mount resources on the command line, try:
gvfs-mount sftp://username@host.tld/ gvfs-mount ftp://username@host.tld/ gvfs-mount dav://host.tld/ gvfs-mount davs://host.tld/
(when the username is omitted, gvfs-open will ask for it if necessary, note that when using dav or davs for some reason you can't specify an username in the URI, at least it doesn't work for me, just as a hint)
When you need a GUI, use Nautilus 2.24 or Sion (http://goodies.xfce.org/projects/applications/sion, there are no Xfce-deps).
Yes, that's the way. And when we save the file in Geany, we set an ignore flag to ignore the next 'file has changed' signal. And there probably begin the problems. Also, this works only if the file was actually only changed which happens when saving with Geany. When you save the file with Gedit, it (probably) won't work because Gedit first saves the file into a temp file, then move it to the real file. So, the real file is never 'changed' but 'created'. And the 'created' notification is currently ignored at all.
Hum… I've just tried with Gedit modifying an opened file in Geany, and the tab becomes orange, but when I start to modify it again, Geany tells me that the file was not found on the disk, asking me whether I want to save it… and if I say yes, then ask me if I want to overwrite the existing file. Well, not perfect (but I personally don't mind about that since this feature helps me mostly for files modified by a script).
Hmm, strange. I just fixed a couple of issues in SVN r3495. It's still not 100% perfect but should be much better now.
Regards, Enrico
On Tue, 20 Jan 2009 10:08:39 +0200, Atanas Beloborodov a.beloborodov@viscomp.bg wrote:
Hello, sorry if this bug is too plain andi am wasting your time, but i really try to help ;)
And this is really appreciated. I'm sorry, I was a bit too sensitive about your reports.
Now back to the topic...i try with make distclean, make clean all and this has no effect. I`m not have running gam or fam. Gvfs things on my computer is 1.0.2-0ubuntu1 version, Gnome version is 2.24.1, Geany is svn r3490, GTK+ 2.14.4, GLib 2.18.2 I edited only local files and filesystem is also ext3 :)
If you could, please try SVN r3495, things should be better now, I hope.
Ddb don`t find nothing trouble...
Do you still get these critical warnings? GDB should stop on them when Geany is started within gdb and with '--g-fatal-warnings'. Then it stops and after you typed 'bt' it should give a backtrace which would help to find the cause for these messages. Though it's likely that these are unrelated to GIO problems.
We reports bugs and use svn version`s becouse really want to
And that is great! Thanks.
Regards, Enrico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Enrico Tröger a écrit :
You can easily mount resources on the command line, try: […]
OK, thanks for the infos, I'll try that :)
Hum… I've just tried with Gedit modifying an opened file in Geany, and the tab becomes orange, but when I start to modify it again, Geany tells me that the file was not found on the disk, asking me whether I want to save it… and if I say yes, then ask me if I want to overwrite the existing file. Well, not perfect (but I personally don't mind about that since this feature helps me mostly for files modified by a script).
Hmm, strange. I just fixed a couple of issues in SVN r3495. It's still not 100% perfect but should be much better now.
Well, with the new code of r3495 almost all seems to be fixed for me: * I have worked about 2 hours for real without reproduce the bug; * If I copy a file to the place of an opened one (both with cp and saving with Gedit), tab becomes orange and when I start editing the buffer the message telling me the file has changed on disk appears and work as expected.
But I /can/ always reproduce the bug if I save and type at a very fast speed, such as chain <letter><^S> about 4 times per second or so – but who's saving its buffers between every letters when typing?
Now for me, if it remains possible to reproduce the bug, it seems not in real world.
Thanks for the pretty fast fix :)
Regards, Colomban
Enrico Tröger wrote :
If you could, please try SVN r3495, things should be better now, I hope.
Sorry for my leater reponse,i really have a lot hard work these day`s.
Do you still get these critical warnings? GDB should stop on them when Geany is started within gdb and with '--g-fatal-warnings'. Then it stops and after you typed 'bt' it should give a backtrace which would help to find the cause for these messages. Though it's likely that these are unrelated to GIO problems.
Regards, Enrico
Now i`m with svn r3499 and there is no bug or any warnings :)
When i edit file with tow editor`s Geany works as expected - tab becomes orange color and there is no probles when save/type after every word. :)
P.S. Now i have a little question.How i can add a menu, or just define a class, such as Tools -> Create Class -> Some other language class. I cannot found nothing in manual. Maybe i`m wrong...
Thanks for great work ! :)
On Thu, 22 Jan 2009 10:15:40 +0200, Atanas Beloborodov a.beloborodov@viscomp.bg wrote:
Enrico Tröger wrote :
If you could, please try SVN r3495, things should be better now, I hope.
Sorry for my leater reponse,i really have a lot hard work these day`s.
Do you still get these critical warnings? GDB should stop on them when Geany is started within gdb and with '--g-fatal-warnings'. Then it stops and after you typed 'bt' it should give a backtrace which would help to find the cause for these messages. Though it's likely that these are unrelated to GIO problems.
Regards, Enrico
Now i`m with svn r3499 and there is no bug or any warnings :)
When i edit file with tow editor`s Geany works as expected - tab becomes orange color and there is no probles when save/type after every word. :)
Cool.
P.S. Now i have a little question.How i can add a menu, or just define a class, such as Tools -> Create Class -> Some other language class. I cannot found nothing in manual. Maybe i`m wrong...
This is not (yet?) possible. Currently, the GTK+ and C++ class templates are hardcoded in the classbuilder plugin. It's a pitty. If anyone wants to improve this, patches are welcome :).
Regards, Enrico
On Wed, 21 Jan 2009 21:55:33 +0100, Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Hey,
But I /can/ always reproduce the bug if I save and type at a very fast speed, such as chain <letter><^S> about 4 times per second or so – but who's saving its buffers between every letters when typing?
Now for me, if it remains possible to reproduce the bug, it seems not in real world.
Yes, it was also hard for me to reproduce but I got it. It happens when you save a document quickly after the last save process. The 'file has changed' notification takes a moment (I didn't measured it but I'd say something about 0.5-1 sec) until it is triggered. So there is a little time frame where the state is inconsistent and this time frame is hit when saving really fast continuously. For me, it is practically impossible to hit this in a normal work flow. But the time frame might be significantly larger on other systems, not sure by what factors it is influenced. One of the main factors is probably the used file alteration system, as mentioned before it can FAM, Gamin or nothing (i.e. usual file polling). And then FAM and Gamin can use the kernel's inotify (which probably only exists on Linux) or they also do just polling. And there are probably other possibilities.
After all, since we are working towards the next release, I disabled the GIO based file monitoring for now since it doesn't work as stable yet as I wish.
If anyone wants to re-activate it, in src/document.c is a commented macro USE_GIO_FILEMON, uncomment it and recompile Geany. Otherwise, the old polling method is used which is also not that bad.
Regards, Enrico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Enrico Tröger a écrit :
On Wed, 21 Jan 2009 21:55:33 +0100, Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Hey,
But I /can/ always reproduce the bug if I save and type at a very fast speed, such as chain <letter><^S> about 4 times per second or so – but who's saving its buffers between every letters when typing?
Now for me, if it remains possible to reproduce the bug, it seems not in real world.
Yes, it was also hard for me to reproduce but I got it. It happens when you save a document quickly after the last save process. The 'file has changed' notification takes a moment (I didn't measured it but I'd say something about 0.5-1 sec) until it is triggered. So there is a little time frame where the state is inconsistent and this time frame is hit when saving really fast continuously. For me, it is practically impossible to hit this in a normal work flow. But the time frame might be significantly larger on other systems, not sure by what factors it is influenced. One of the main factors is probably the used file alteration system, as mentioned before it can FAM, Gamin or nothing (i.e. usual file polling). And then FAM and Gamin can use the kernel's inotify (which probably only exists on Linux) or they also do just polling. And there are probably other possibilities.
I've got it one time yesterday, but it was with an uncommon action (resulting on saving 2 times in ~1sec). The I agree it is unstable and not suitable for a release now.
But to solve the problem due to latency, can't a "stack" help? I mean instead of just marking to ignore next notification, increment a "notify_skip" when saving and decrement it on notification received, then only use notification if notify_skip is equal to 0. I think it should work if the problem is only receiving first notif after second save, and it is pretty easy to implement as you said there's already a flag.
I'll try that if I find fast how to do that.
Regards, Colomban
On Sat, 24 Jan 2009 22:57:41 +0100, Colomban Wendling ban-ubuntu@club-internet.fr wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Enrico Tröger a écrit :
On Wed, 21 Jan 2009 21:55:33 +0100, Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Hey,
But I /can/ always reproduce the bug if I save and type at a very fast speed, such as chain <letter><^S> about 4 times per second or so – but who's saving its buffers between every letters when typing?
Now for me, if it remains possible to reproduce the bug, it seems not in real world.
Yes, it was also hard for me to reproduce but I got it. It happens when you save a document quickly after the last save process. The 'file has changed' notification takes a moment (I didn't measured it but I'd say something about 0.5-1 sec) until it is triggered. So there is a little time frame where the state is inconsistent and this time frame is hit when saving really fast continuously. For me, it is practically impossible to hit this in a normal work flow. But the time frame might be significantly larger on other systems, not sure by what factors it is influenced. One of the main factors is probably the used file alteration system, as mentioned before it can FAM, Gamin or nothing (i.e. usual file polling). And then FAM and Gamin can use the kernel's inotify (which probably only exists on Linux) or they also do just polling. And there are probably other possibilities.
I've got it one time yesterday, but it was with an uncommon action (resulting on saving 2 times in ~1sec). The I agree it is unstable and not suitable for a release now.
But to solve the problem due to latency, can't a "stack" help? I mean instead of just marking to ignore next notification, increment a "notify_skip" when saving and decrement it on notification received, then only use notification if notify_skip is equal to 0. I think it should work if the problem is only receiving first notif after second save, and it is pretty easy to implement as you said there's already a flag.
Yup, something like this could work, good idea. I'll play with that after the next release.
This week, I also played with delaying the received events to 'collect' them and after some time has passed, check what we received and react approrpiately. But this also failed badly :).
Regards, Enrico
