Thread: [cssed-devel] New test feature
Brought to you by:
iagorubio
From: Iago R. <iag...@hi...> - 2004-03-11 16:45:34
|
Hi all, I'm testing a new feature in cssed. In non technicall words, this feature will let cssed to be opened one time, and from this point all other atempts to open a file with it, will redirect the action to the running instance. This way - as example - if you associate the css file type with cssed, and you've got one instance of cssed running, the next time you open a css file from your filebrowser, it will be opened in the cssed instance you are working. Bluefish users know this behaviour. This feature is filebrowser independent and also works if you use the console. I've got an initial test done, but I'm not sure if I will put it to work in a release.=20 There're lots of things to do with it, but I'd like to know if it's interesting. If it's not, I will not work further on it ;) You've got an snapshot with this feature enabled here http://cssed.sourceforge.net/cssed-0.2.0-ipc-11_3_2004.tar.gz It have not been tested so far, and It have some improvments to be done ( as signal handling ), in the case of left it as an option. I'm not sure to add it in the release, because there must be a thread running waiting for actions from other cssed instances.=20 I'm afraid of resurce consumption in very low-end systems ( it's tested in a Pentium 100 with 32 Mb/RAM and it works quite well, but if we continue to add this kind of features, cssed will not work in this type of systems ;) Any opinions or ideas ? If any of you want a technicall description of this feature, just ask for it ;) but it's based on ipc System-V message queues, so must work in any *nix system. Just read main.c ( this is test code that will be moved to a separate file if we decide to use it ). * How to test it ? Compile the snapshot cd into the /src folder and type: ./cssed utils.c& ( as example ) ./cssed utils.c& ./cssed utils.c& All files must be opened in the first cssed's instance. Some debug output will be printed. You can also use the following command, in a separate console, to see what's going on in the background. $ watch ipcs -q Feedback please ;) --=20 Iago Rubio http://www.iagorubio.com =20 GPGkey pgp.rediris.es id 0x909BD4DD fingerprint =3D D18A B950 5F03 BB9A DD89 AA75 FEDF 1978 909B D4DD ********** iago.rubio(AT)hispalinux.es ********** =20 -------------------------------------------------- |
From: Jeremy G. <j....@lo...> - 2004-03-11 19:10:13
|
On Thu, 2004-03-11 at 08:22, Iago Rubio wrote: > Hi all, > > I'm testing a new feature in cssed. > > In non technicall words, this feature will let cssed to be opened one > time, and from this point all other atempts to open a file with it, will > redirect the action to the running instance. > Sounds cool, will give it a try. > This way - as example - if you associate the css file type with cssed, > and you've got one instance of cssed running, the next time you open a > css file from your filebrowser, it will be opened in the cssed instance > you are working. > > Bluefish users know this behaviour. > > This feature is filebrowser independent and also works if you use the > console. > > I've got an initial test done, but I'm not sure if I will put it to work > in a release. > > There're lots of things to do with it, but I'd like to know if it's > interesting. If it's not, I will not work further on it ;) > > You've got an snapshot with this feature enabled here > http://cssed.sourceforge.net/cssed-0.2.0-ipc-11_3_2004.tar.gz > > It have not been tested so far, and It have some improvments to be done > ( as signal handling ), in the case of left it as an option. > > I'm not sure to add it in the release, because there must be a thread > running waiting for actions from other cssed instances. > > I'm afraid of resurce consumption in very low-end systems ( it's tested > in a Pentium 100 with 32 Mb/RAM and it works quite well, but if we > continue to add this kind of features, cssed will not work in this type > of systems ;) > > Any opinions or ideas ? > > If any of you want a technicall description of this feature, just ask > for it ;) but it's based on ipc System-V message queues, so must work in > any *nix system. Just read main.c ( this is test code that will be moved > to a separate file if we decide to use it ). > > * How to test it ? > > Compile the snapshot cd into the /src folder and type: > > ./cssed utils.c& ( as example ) > ./cssed utils.c& > ./cssed utils.c& > > All files must be opened in the first cssed's instance. > > Some debug output will be printed. > > You can also use the following command, in a separate console, to see > what's going on in the background. > > $ watch ipcs -q > > > Feedback please ;) -Jeremy |
From: <mic...@ea...> - 2004-03-12 15:03:15
Attachments:
PGP.sig
|
Hi Iago, Le 11 mars 2004, =E0 17:22, Iago Rubio a =E9crit : > Hi all, > > I'm testing a new feature in cssed. > > for it ;) but it's based on ipc System-V message queues, so must work=20= > in > any *nix system. No, no. On Mac OS X, there is not ipc System_V message queue. But you=20 can handle it inside gnome, which means a lot of code. Mich=E8le <http://micmacfr.homeunix.org> |
From: Iago R. <iag...@hi...> - 2004-03-12 16:54:31
|
El vie, 12 de 03 de 2004 a las 15:44, Mich=C3=A8le Garoche escribi=C3=B3: > Hi Iago, >=20 > Le 11 mars 2004, =C3=A0 17:22, Iago Rubio a =C3=A9crit : >=20 > > Hi all, > > > > I'm testing a new feature in cssed. > > > > for it ;) but it's based on ipc System-V message queues, so must work=20 > > in > > any *nix system. > No, no. On Mac OS X, there is not ipc System_V message queue. But you=20 > can handle it inside gnome, which means a lot of code. I checked the MacOsX docs before doing it, and it states that exists ipc support in Darwin.=20 But I didn't notice that the headers and the API are not the same as in other *nix systems. "msg.h For information on how to implement message queues, see the Technical Note 1071[39]. The APIs implemented in msg.h are also not supported, such as msgget, msgsnd, msgrcv, and msgctl. The Technical Note mentioned above will help you implement the functionality from these functions." http://developer.apple.com/technotes/tn2002/tn2071.html The technical note 1071 describes how to implement it with the "MPLibrary" shared library. http://developer.apple.com/technotes/tn/tn1071.html Is there this library is all MacOsX systems ? It seems to be a core Darwing feature, if it's supossed to be in all MacOsX systems, may be, I'll take a try ;) What can be problematic is to link with it, as there are no configure checks to test for it. Exists a standard location and name for the library ? Any idea about how to provide this feature in MacOsX without gnome ? --=20 Iago Rubio http://www.iagorubio.com =20 GPGkey pgp.rediris.es id 0x909BD4DD fingerprint =3D D18A B950 5F03 BB9A DD89 AA75 FEDF 1978 909B D4DD ********** iago.rubio(AT)hispalinux.es ********** =20 -------------------------------------------------- |
From: <mic...@ea...> - 2004-03-12 17:17:49
Attachments:
PGP.sig
|
Le 12 mars 2004, =E0 17:34, Iago Rubio a =E9crit : > El vie, 12 de 03 de 2004 a las 15:44, Mich=E8le Garoche escribi=F3: >> Hi Iago, >> >> Le 11 mars 2004, =E0 17:22, Iago Rubio a =E9crit : >> >>> Hi all, >>> >>> I'm testing a new feature in cssed. >>> >>> for it ;) but it's based on ipc System-V message queues, so must = work >>> in >>> any *nix system. >> No, no. On Mac OS X, there is not ipc System_V message queue. But you >> can handle it inside gnome, which means a lot of code. > > I checked the MacOsX docs before doing it, and it states that exists=20= > ipc > support in Darwin. > > But I didn't notice that the headers and the API are not the same as = in > other *nix systems. > > "msg.h > For information on how to implement message queues, see the > Technical Note 1071[39]. The APIs implemented in msg.h are = also > not supported, such as msgget, msgsnd, msgrcv, and msgctl. The > Technical Note mentioned above will help you implement the > functionality from these functions." > http://developer.apple.com/technotes/tn2002/tn2071.html > > The technical note 1071 describes how to implement it with the > "MPLibrary" shared library. > http://developer.apple.com/technotes/tn/tn1071.html > > Is there this library is all MacOsX systems ? > > It seems to be a core Darwing feature, if it's supossed to be in all > MacOsX systems, may be, I'll take a try ;) I doubt you can use it under X11. > > What can be problematic is to link with it, as there are no configure > checks to test for it. > > Exists a standard location and name for the library ? > > Any idea about how to provide this feature in MacOsX without gnome ? No that I know of. Mich=E8le <http://micmacfr.homeunix.org> |
From: Iago R. <iag...@hi...> - 2004-03-12 18:44:26
|
El vie, 12 de 03 de 2004 a las 17:58, Mich=C3=A8le Garoche escribi=C3=B3: > Le 12 mars 2004, =C3=A0 17:34, Iago Rubio a =C3=A9crit : > > It seems to be a core Darwing feature, if it's supossed to be in all > > MacOsX systems, may be, I'll take a try ;) > I doubt you can use it under X11. But interprocces communication is a kernel feature, so why X11 will break it ? The message queue can run in the console, and have no need of graphic features of X11. It's just as shared memory, semaphores, signals, .... those are low level kernel features, and shoud not be broken by any other running proccess in the system. =20 > > What can be problematic is to link with it, as there are no configure > > checks to test for it. > > > > Exists a standard location and name for the library ? > > > > Any idea about how to provide this feature in MacOsX without gnome ? > No that I know of. :( Will take it out with some #defines then to avoid breaking MacOsX building. In the other hand, may be it will never be in a release, but I will investigate further in the MacOsX ipc capabilities. This feature can be implemented storing information in a shared memory segment instead of using message queues. The shared memory api seems to be the same in Linux and MacOsX. But I'm not yet sure it's something to be done. Is this interesting ? or it doesn't deserve the effort. --=20 Iago Rubio http://www.iagorubio.com =20 GPGkey pgp.rediris.es id 0x909BD4DD fingerprint =3D D18A B950 5F03 BB9A DD89 AA75 FEDF 1978 909B D4DD ********** iago.rubio(AT)hispalinux.es ********** =20 -------------------------------------------------- |
From: <mic...@ea...> - 2004-03-13 02:31:08
Attachments:
PGP.sig
|
Le 12 mars 2004, =E0 19:24, Iago Rubio a =E9crit : > El vie, 12 de 03 de 2004 a las 17:58, Mich=E8le Garoche escribi=F3: >> Le 12 mars 2004, =E0 17:34, Iago Rubio a =E9crit : >>> It seems to be a core Darwing feature, if it's supossed to be in all >>> MacOsX systems, may be, I'll take a try ;) >> I doubt you can use it under X11. > > But interprocces communication is a kernel feature, so why X11 will > break it ? It's a micro-kernel feature and the services are implemented in the=20 Carbon layer, so above the X11 layer. > > The message queue can run in the console, and have no need of graphic > features of X11. I's not a standard message queue, that's why it's so complicated to=20 implement outside of CarbonLib. > > It's just as shared memory, semaphores, signals, .... those are low > level kernel features, and shoud not be broken by any other running > proccess in the system. Shared memory is not standard either on the Mac. But you can use=20 sockets; it works like a charm. > >>> What can be problematic is to link with it, as there are no = configure >>> checks to test for it. >>> >>> Exists a standard location and name for the library ? >>> >>> Any idea about how to provide this feature in MacOsX without gnome ? >> No that I know of. > > :( > > Will take it out with some #defines then to avoid breaking MacOsX > building. > > In the other hand, may be it will never be in a release, but I will > investigate further in the MacOsX ipc capabilities. > > This feature can be implemented storing information in a shared memory > segment instead of using message queues. > > The shared memory api seems to be the same in Linux and MacOsX. Alas, no. > > But I'm not yet sure it's something to be done. > > Is this interesting ? or it doesn't deserve the effort. =46rom the Mac point of view, it has no interest, as it will never work=20= as intended (i.e. open a file with cssed by choosing it in the=20 filebrowser). Simply because I cannot associate an X11 application with=20= a file, the application has to be a Mac OS X application for this to=20 work (for example an AppleScript which launches X11, then cssed, then=20 open a file within cssed). Then I can dock cssed like any other Mac OS=20= X application and associate any files with the script. Mich=E8le <http://micmacfr.homeunix.org> |
From: Iago R. <iag...@hi...> - 2004-03-16 10:34:45
|
Hi Mich=C3=A8le, sorry for this delay, I went to Madrid to visit my family there, and I've just come back now. On Sat, 2004-03-13 at 03:30, Mich=C3=A8le Garoche wrote: > Le 12 mars 2004, =C3=A0 19:24, Iago Rubio a =C3=A9crit : [big snip] > > But I'm not yet sure it's something to be done. > > > > Is this interesting ? or it doesn't deserve the effort. > From the Mac point of view, it has no interest, as it will never work > as intended (i.e. open a file with cssed by choosing it in the=20 > filebrowser). Simply because I cannot associate an X11 application with=20 > a file, the application has to be a Mac OS X application for this to=20 > work (for example an AppleScript which launches X11, then cssed, then=20 > open a file within cssed). Then I can dock cssed like any other Mac OS > X application and associate any files with the script. Ok, I will drop it for MacOSX systems then. I'm puting to work some defines to exclude the code from Darwin machines. Sorry again for my delay. --=20 Iago Rubio http://www.iagorubio.com =20 GPGkey pgp.rediris.es id 0x909BD4DD fingerprint =3D D18A B950 5F03 BB9A DD89 AA75 FEDF 1978 909B D4DD ********** iago.rubio(AT)hispalinux.es ********** =20 -------------------------------------------------- |