headers
Axel Huizinga | 1 Jul 2007 12:14
Picon
Favicon

SciTE 1.74 €

Hi,

after updating to 1.74 on my linux 64 bit box
Scite type EUR instead of  €.
Can I change this behaviour?

Axel
_______________________________________________
Scite-interest mailing list
Scite-interest <at> lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
Permalink | Reply | 2 comments |
headers
steve donovan | 1 Jul 2007 13:43
Picon

Re: Re: Re: Single instance and Director Extension in SciTEGTK

On 6/30/07, Chachereau Nicolas <nicolas.chachereau <at> infomaniak.ch> wrote:
> I'll take a serious look at that. As I wrote in an email that
> mysteriously disappeared, I'm not sure I like having potentially so
> many pipes open. That's what I was referring to when saying that I
> would tend to using local sockets. However, I don't know enough about
> them yet... and it's true that they're more complicated than named
> pipes.

That's what I think - named pipes are so easy, you don't need a higher
degree or special equipment ;)  Although controlling a remote instance
of SciTE might be entertaining, it wouldn't be high on most people's
list of piorities.  But, it's true, pipes are global.  I was thinking
whether it's not better to put the pipes in some local user directory
like ~/.scite or something.

BTW, scitepm actually drives SciTE pretty smartly.  It makes up its
own unique pipes, and passes the ipc properties in the environment to
its own SciTE instance.  So there is no problem with multiple scitepm
instances. The new interface extensions can coexist quite happily.

steve d.
Permalink | Reply | 4 comments |
headers
Chachereau Nicolas | 1 Jul 2007 14:42
Picon

Re: Re: Re: Re: Single instance and Director Extension in SciTEGTK

Steve Donovan wrote:
>That's what I think - named pipes are so easy, you don't need a higher
>degree or special equipment ;)  Although controlling a remote instance
>of SciTE might be entertaining, it wouldn't be high on most people's
>list of piorities.  But, it's true, pipes are global.  I was thinking
>whether it's not better to put the pipes in some local user directory
>like ~/.scite or something.

I finally decided that I like what you've done. You're right, let's keep
pipes, because they're easy to use and we can stay backward compatible.
I don't think we need to put them in another place that the current temp
directory. I'm working right now on making the single instance code use
the director interface unless NO_FILER is defined. I'll submit some
suggestions about the director extension when I'm done.

I also tracked down the bug that you encountered in scite-gdb, when you
had several extender: command passed into you ProcessChunk() function
at once. It wasn't actually a bug in SciTE. You need to end your
messages with a new line to ensure they're parsed as separate commands.
Here's the fix:

void scite_exec(const char* fun, const char* buff)
{
    *outbuf = '\0';
    strcpy(outbuf,"extender:");
    strcat(outbuf,fun);
    strcat(outbuf," ");
    slashify(outbuf + strlen(outbuf),buff,0);
    strcat(outbuf, "\n");
    scite_interface(outbuf);
}

(in unix-spawner.c)

(BTW, it's detail, but you might want to always use either spaces or
tabs in your files, not mix them, and also strip trailing spaces)

Nicolas
Permalink | Reply | 0 comments |
headers
Roy Wood | 1 Jul 2007 16:13
Picon

Re: Re: Re: Single instance and Director Extension in SciTEGTK

> BTW, scitepm actually drives SciTE pretty smartly.  It makes up its
> own unique pipes, and passes the ipc properties in the environment to
> its own SciTE instance.  So there is no problem with multiple scitepm
> instances. The new interface extensions can coexist quite happily.

I'm the author of scitepm, so thanks for the nice words.  :-)

I'm very happy to modify scitepm to work with whatever IPC strategy
you guys want to set up in scite.  The code in scitepm is very clean,
and implementing the required changes would be a snap.  Just let me
know what the final interface is going to be.

Oh-- and as far as window focus goes, it would be nice to be able to
request for scite to front itself.  I discussed that with Neil about a
year ago, and he was interested in the idea, but I never got around to
submitting a patch....
Permalink | Reply | 2 comments |
headers
Chachereau Nicolas | 1 Jul 2007 18:27
Picon

Re: Re: Re: Re: Single instance and Director Extension in SciTEGTK

Roy Wood wrote:
>I'm the author of scitepm, so thanks for the nice words.  :-)
>
>I'm very happy to modify scitepm to work with whatever IPC strategy
>you guys want to set up in scite.  The code in scitepm is very clean,
>and implementing the required changes would be a snap.  Just let me
>know what the final interface is going to be.

Hey, nice to hear of you. I think you won't have to modify anything,
at least not in terms of IPC... I was reluctant to keep pipes at
first, but now I think I'll go along with Steve's implementation.
Besides, I'm more or less done implementing the single instance code
using director messages through the new pipe system.

>Oh-- and as far as window focus goes, it would be nice to be able to
>request for scite to front itself.  I discussed that with Neil about a
>year ago, and he was interested in the idea, but I never got around to
>submitting a patch....

That's the next thing on my todo list, and I already have some pointers.
Basically we need to call gtk_window_present() but there is some stuff
with timestamps - to ensure the window gets fronted unless it's
annoying for the user - that I've got to research. What would the
message be called? I'd propose "focus:"... any other or better ideas?

Nicolas
Permalink | Reply | 1 comment |
headers
Roy Wood | 1 Jul 2007 18:36
Picon

Re: Re: Re: Re: Single instance and Director Extension in SciTEGTK

> That's the next thing on my todo list, and I already have some pointers.
> Basically we need to call gtk_window_present() but there is some stuff
> with timestamps - to ensure the window gets fronted unless it's
> annoying for the user - that I've got to research. What would the
> message be called? I'd propose "focus:"... any other or better ideas?

Sure, "focus:" works fine for me....
Permalink | Reply | 0 comments |
headers
Richard Baker | 1 Jul 2007 21:55
Picon
Favicon

Re: Embedding Python

You might want to investigate "Lunatic Python"...

http://labix.org/lunatic-python

-------------
Introduction

Lunatic Python is a two-way bridge between Python and Lua,
allowing these languages to intercommunicate. Being two-way
means that it allows Lua inside Python, Python inside Lua,
Lua inside Python inside Lua, Python inside Lua inside Python,
and so on.
-------------

-- Richard
Permalink | Reply | 0 comments |
headers
Chachereau Nicolas | 1 Jul 2007 22:35
Picon

Invalid free() in src/SciTEBuffers.cxx

Hi everybody,

while working on the single instance code, I encountered the
following error when the second instance exited:

*** glibc detected *** free(): invalid pointer: <memory address> ***

I investigated the problem using valgrind (just discovered
this tool... powerful), which told me the exact place in the
code (after recompiling SciTE with -g), where it reported
both "Conditional jump or move depends on uninitialised value"
and "Invalid free". This probably never came to light before
because we were using exit() and the destructors were never
called.

This is the patch, we just need to initialise stack in the class
BufferList in SciTEBuffers.cxx:

diff -a -u -r1.159 SciTEBuffers.cxx
--- SciTEBuffers.cxx	13 Jun 2007 14:09:10 -0000	1.159
+++ SciTEBuffers.cxx	1 Jul 2007 20:23:37 -0000
 <at>  <at>  -74,7 +74,7  <at>  <at> 
 	flags = 0;
 }

-BufferList::BufferList() : current(0), stackcurrent(0), buffers(0), size(0), length(0),
initialised(false) {}
+BufferList::BufferList() : current(0), stackcurrent(0), stack(0), buffers(0), size(0),
length(0), initialised(false) {}

 BufferList::~BufferList() {
 	delete []buffers;

Nicolas
Permalink | Reply | 1 comment |
headers
Neil Hodgson | 2 Jul 2007 01:57
Picon

Re: Invalid free() in src/SciTEBuffers.cxx

Chachereau Nicolas:

> This is the patch, we just need to initialise stack in the class
> BufferList in SciTEBuffers.cxx:

   OK, committed.

   Neil
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 2 Jul 2007 02:33
Picon

Re: SciTE 1.74 €

Axel Huizinga:

>  after updating to 1.74 on my linux 64 bit box
>  Scite type EUR instead of  €.
>  Can I change this behaviour?

   What locale settings are you using? Often people use ISO-8859-1
which does not include € but it should be OK in UTF-8. You can try
character.set=1000 for ISO-8859-15 but that hasn't been thoroughly
tested or documented.

   Neil
Permalink | Reply | 1 comment |

Gmane