Hello there,
Does ADD_FUNCTION macro still works outside the program scope on the module level in a Pike C module (not in a cmod) ? We have currently issues in our Caudium C module... and it seems that the following code has stopped to work :
main.c
/* ... */
void pike_module_init( void ) {
/* some other add_function_constant() */
add_function_constant( "http_date", f_http_date, "function(int|void:string)", 0);
/* */
init_external_module();
/* */
}
in external.c we have :
void init_external_module (void) {
ADD_FUNCTION("whatever",f_whatever, tFunc(tVoid, tInt), 0);
}
Before (on 7.2 and in 7.4) it has used to work, but today on Pike 7.5 it has suddenlt stopped to work...
Is this normal ?
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
Your error description is a bit vague. Do you mean it doesn't compile? Do you include program.h in external.c?
/ Martin Nilsson (provokatör)
Previous text:
2004-03-26 23:38: Subject: ADD_FUNCTION() macro on pike 7.5 ?
Hello there,
Does ADD_FUNCTION macro still works outside the program scope on the module level in a Pike C module (not in a cmod) ? We have currently issues in our Caudium C module... and it seems that the following code has stopped to work :
main.c
/* ... */
void pike_module_init( void ) {
/* some other add_function_constant() */
add_function_constant( "http_date", f_http_date, "function(int|void:string)", 0);
/* */
init_external_module();
/* */
}
in external.c we have :
void init_external_module (void) {
ADD_FUNCTION("whatever",f_whatever, tFunc(tVoid, tInt), 0);
}
Before (on 7.2 and in 7.4) it has used to work, but today on Pike 7.5 it has suddenlt stopped to work...
Is this normal ?
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
/ Brevbäraren
On Fri, Mar 26, 2004 at 11:37:40PM +0100, Xavier Beaudouin wrote:
Before (on 7.2 and in 7.4) it has used to work, but today on Pike 7.5 it has suddenlt stopped to work...
The problem is a bit different, I guess. Actually, in Pike 7.2/7.4 it was enough to use add_function() (not add_function_constant()) to make function visible outside, but this behavior was changed somewhere in 7.5. I've no idea why, but there was some discussion concerning this topic (I posted similar question).
But, because I don't (yet) know - what is correct - to use plain add_function() or add_function_constant(), it is difficult to say - is this change normal or not (was it a bug or feature?) :)
What is interesting, if add_function() is used outside start_new_program(), and then this module is inherited (from Pike code), everything is like it was before (even in 7.5) - so, actually, it affects only those modules which are used directly (without "transitional" Pike module).
Say, I've:
add_function("blabla", f_blabla, ...); and then, instead of using Blabla.so directly, use it through Blabla.pmod:
inherit _Blabla; // Where _Blabla.so is our module and then, I use it like Blabla.blabla - it will behave as expected (i.e. function is constant) in Pike 7.2/7.4/7.5 (at least, this is what I figured from my tests).
Regards, /Al
For Pike 7.5, you should use PIKE_MODULE_INIT, not "void pike_module_init( void )". This works in 7.4 too.
Although I bet your actual problem is that C modules are now programs, not objects. So you need to instantiate them before accessing non-constant members. This is the most brain-damaged aspect of 7.5.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-03-26 23:38: Subject: ADD_FUNCTION() macro on pike 7.5 ?
Hello there,
Does ADD_FUNCTION macro still works outside the program scope on the module level in a Pike C module (not in a cmod) ? We have currently issues in our Caudium C module... and it seems that the following code has stopped to work :
main.c
/* ... */
void pike_module_init( void ) {
/* some other add_function_constant() */
add_function_constant( "http_date", f_http_date, "function(int|void:string)", 0);
/* */
init_external_module();
/* */
}
in external.c we have :
void init_external_module (void) {
ADD_FUNCTION("whatever",f_whatever, tFunc(tVoid, tInt), 0);
}
Before (on 7.2 and in 7.4) it has used to work, but today on Pike 7.5 it has suddenlt stopped to work...
Is this normal ?
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
/ Brevbäraren
On Fri, Mar 26, 2004 at 11:55:01PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Although I bet your actual problem is that C modules are now programs, not objects.
Ahhh.. That was it... But if they weren't programs before, how it was possible to inherit them (I hope this is not completely stupid question)?
Regards, /Al
inherit on an object actually inherits the object_program() of that object.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-03-26 23:58: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
On Fri, Mar 26, 2004 at 11:55:01PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Although I bet your actual problem is that C modules are now programs, not objects.
Ahhh.. That was it... But if they weren't programs before, how it was possible to inherit them (I hope this is not completely stupid question)?
Regards, /Al
/ Brevbäraren
Hello
For Pike 7.5, you should use PIKE_MODULE_INIT, not "void pike_module_init( void )". This works in 7.4 too.
Although I bet your actual problem is that C modules are now programs, not objects. So you need to instantiate them before accessing non-constant members. This is the most brain-damaged aspect of 7.5.
This is really bad... This make all pike C modules now incompatible between pike version... ;(
Very bad thing for pexts, and all hardly developped pike modules in C...
So bad there is no warning on this important code change...
We will add lots of #ifdef but, this is bad ;(
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
This is really bad... This make all pike C modules now incompatible between pike version... ;(
Not for normal usage; a corresponding .pmod is automatically generated.
Very bad thing for pexts, and all hardly developped pike modules in C...
So bad there is no warning on this important code change...
We will add lots of #ifdef but, this is bad ;(
I don't see why you would need any changes.
NB: The reason for the change is to reduce the differences between dynamic and static modules.
/Xavier
/ Henrik Grubbström (Lysator)
Previous text:
2004-03-27 20:14: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Hello
For Pike 7.5, you should use PIKE_MODULE_INIT, not "void pike_module_init( void )". This works in 7.4 too.
Although I bet your actual problem is that C modules are now programs, not objects. So you need to instantiate them before accessing non-constant members. This is the most brain-damaged aspect of 7.5.
This is really bad... This make all pike C modules now incompatible between pike version... ;(
Very bad thing for pexts, and all hardly developped pike modules in C...
So bad there is no warning on this important code change...
We will add lots of #ifdef but, this is bad ;(
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
/ Brevbäraren
Le 27 mars 04, à 20:20, Henrik Grubbström (Lysator) @ Pike (-) developers forum a écrit :
This is really bad... This make all pike C modules now incompatible between pike version... ;(
Not for normal usage; a corresponding .pmod is automatically generated.
normal usage yes... eg pike C modules generated *inside* pike source code.
but outside that, eg custom pike C modules made (hardly) by hand, the .pmod is not automatically generated.
Very bad thing for pexts, and all hardly developped pike modules in C...
So bad there is no warning on this important code change...
We will add lots of #ifdef but, this is bad ;(
I don't see why you would need any changes.
to replace ADD_FUNCTION() to add_function_constant() to workaround this change.
NB: The reason for the change is to reduce the differences between dynamic and static modules.
This one is good.... but external (home made) modules are allways dynamic modules (eg .so)...
/Xavier -- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
but outside that, eg custom pike C modules made (hardly) by hand, the .pmod is not automatically generated.
Not if you use the correct build procedure (pike -x module) for external modules.
This one is good.... but external (home made) modules are allways dynamic modules (eg .so)...
No. If the Pike can not handle dynamic modules (because it is not possible on that platform) you would compile pike with the external modules as static modules.
/ Martin Nilsson (provokatör)
Previous text:
2004-03-29 13:22: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Le 27 mars 04, à 20:20, Henrik Grubbström (Lysator) @ Pike (-) developers forum a écrit :
This is really bad... This make all pike C modules now incompatible between pike version... ;(
Not for normal usage; a corresponding .pmod is automatically generated.
normal usage yes... eg pike C modules generated *inside* pike source code.
but outside that, eg custom pike C modules made (hardly) by hand, the .pmod is not automatically generated.
Very bad thing for pexts, and all hardly developped pike modules in C...
So bad there is no warning on this important code change...
We will add lots of #ifdef but, this is bad ;(
I don't see why you would need any changes.
to replace ADD_FUNCTION() to add_function_constant() to workaround this change.
NB: The reason for the change is to reduce the differences between dynamic and static modules.
This one is good.... but external (home made) modules are allways dynamic modules (eg .so)...
/Xavier
Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
/ Brevbäraren
Martin Nilsson (provokatör) @ Pike (-) developers forum wrote:
but outside that, eg custom pike C modules made (hardly) by hand, the .pmod is not automatically generated.
Not if you use the correct build procedure (pike -x module) for external modules.
...which doesn't solve the compatibility problems for modules < 7.4 anyway.
/ David
I distinctly remember compiling modules with -x module in 7.4 as late as just last week.
/ Peter Bortas (Kein Paket!)
Previous text:
2004-03-29 13:50: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Martin Nilsson (provokatör) @ Pike (-) developers forum wrote:
but outside that, eg custom pike C modules made (hardly) by hand, the .pmod is not automatically generated.
Not if you use the correct build procedure (pike -x module) for external modules.
...which doesn't solve the compatibility problems for modules < 7.4 anyway.
/ David
/ Brevbäraren
Yes, that's what I said: for modules < 7.4 meaning for 7.2, 7.0 and so on then you have a problem.
Peter Bortas (Kein Paket!) @ Pike (-) developers forum wrote:
I distinctly remember compiling modules with -x module in 7.4 as late as just last week.
/ Peter Bortas (Kein Paket!)
Previous text:
2004-03-29 13:50: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Martin Nilsson (provokatör) @ Pike (-) developers forum wrote:
but outside that, eg custom pike C modules made (hardly) by hand, the .pmod is not automatically generated.
Not if you use the correct build procedure (pike -x module) for external modules.
...which doesn't solve the compatibility problems for modules < 7.4 anyway.
Well, while it would have been nice to know that this happened up front, it's not the end of the world, really. I mean, as an example, the caudium devel tree only supports 7.5, so why not use the new "official" system? It would certainly clean up the mess of stuff we have to spend our time maintaining, wouldn't it?
As for old stuff, I personally am working on getting the development version stable so I don't have to maintain old code. And for code that must be kept, I do it separately. We'll probably expend more effort discussing the merits and whys of this situation longer than it would take to just "bite the bullet" and do it.
I think it's unreasonable to expect things to not change and improve just so we lazy developers don't have to update our code. Once every four years isn't that bad.
Just my 0.01374 EUR...
Bill
Yes, that's what I said: for modules < 7.4 meaning for 7.2, 7.0 and so on then you have a problem.
Le 29 mars 04, à 14:35, Bill Welliver a écrit :
Well, while it would have been nice to know that this happened up front, it's not the end of the world, really. I mean, as an example, the caudium devel tree only supports 7.5, so why not use the new "official" system? It would certainly clean up the mess of stuff we have to spend our time maintaining, wouldn't it?
Yes we can... But AFAIK "official" system was optional some day ago. So giving it as mandatory will give us (= Caudium) more problems than it solve.
As for old stuff, I personally am working on getting the development version stable so I don't have to maintain old code. And for code that must be kept, I do it separately. We'll probably expend more effort discussing the merits and whys of this situation longer than it would take to just "bite the bullet" and do it.
I think it's unreasonable to expect things to not change and improve just so we lazy developers don't have to update our code. Once every four years isn't that bad.
I agree, but low level change should not be kept secret... And I still think that changing low level thing on Pike C modules every day will make some developper more and more lazy about Pike...
I am a bit surprised that so much changes inside current pike (that'll maybe be future stable pike ?) are not public ?
Where is a changelog about that ? Nothing ?
I have asked for a commit log sent by mail one year ago to help external developpers to see what are the changes... But nothing as usual...
The main problem is killing API will kill pike because :
- no changelog - too little (or maybe near no) docs for core developpers - some things are very hard to be done... : - cmod : is there any BNF / docs clearly explained on how to make them ? - pike C modules : they are bloody hard to make, but changing the low level api will tell developpers : "ok the thing is not mature, I will go somewhere else where it is mature".
Maybe this is done for a secret reason, but what ever it is, it is very not a good think for our litle pike community.
My 0,02€...
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
I realize this might be the wrong forum for this, but what problems does it create?
Yes we can... But AFAIK "official" system was optional some day ago. So giving it as mandatory will give us (= Caudium) more problems than it solve.
Well, good communications has been and continues to be a problem. I think a certain amount of the problem is that the vast majority of the developers can just talk to one another, so there's no record of the discussion or notification of changes taking place somewhere those of us who aren't at IDA can look at.
So, until someone at IDA volunteers to take notes, or one of us decides to move to sweden, it's going to continue to be a problem.
I agree, but low level change should not be kept secret... And I still think that changing low level thing on Pike C modules every day will make some developper more and more lazy about Pike...
I don't think that "being public" is the problem. I mean, it's not like there isn't a fine web interface to the changes that do get made. The problem is that no one is "interpreting" the changes and letting the non-core developers know about it. The pike newsletter was a nice idea, but there was only one issue of it.
I am a bit surprised that so much changes inside current pike (that'll maybe be future stable pike ?) are not public ?
I have to admit, it would be nice if a changelog were updated _as_ features got added, rather than an afterthought. It's always easier to prune entries than to go back afterwward looking for things that changed.
How about it? I think that would be a good policy to have: if you add or change functionality, you should have a description of the change or addition in the CHANGELOG. No exceptions.
Where is a changelog about that ? Nothing ?
As always, documentation is a problem. I'm slowly progressing with the tutorial, but that doesn't address the other problems such as c module development. I don't know that complaining more about the problem will do any good, as the people who have the knowledge to write the docs are so busy (understandably) with other things. My solution was to learn how to write modules and then document the process. I've not gotten very far with that yet, though.
Bill
Well, good communications has been and continues to be a problem. I think a certain amount of the problem is that the vast majority of the developers can just talk to one another, so there's no record of the discussion or notification of changes taking place somewhere those of us who aren't at IDA can look at.
This isn't how it works. We seldom see each other except for occasional dinners, movies and other non-computer related activities. The discussions are often computer, programming and Pike-related, but on a conceptual level.
The pike newsletter was a nice idea, but there was only one issue of it.
I though so too (obviously, since I tried to start the newsletter). I just made one as an example and then tried to get an author/editor. If anyone would like to make a new try I think we would all appreciate it.
I have to admit, it would be nice if a changelog were updated _as_ features got added, rather than an afterthought. It's always easier to prune entries than to go back afterwward looking for things that changed.
It is not always appearent what is an important change and what the implications of a change really is. Remember that the change that started this discussion really was very minor in terms of changed code and was more of a bug fix than a feature change.
/ Martin Nilsson (provokatör)
Previous text:
2004-03-29 19:41: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
I realize this might be the wrong forum for this, but what problems does it create?
Yes we can... But AFAIK "official" system was optional some day ago. So giving it as mandatory will give us (= Caudium) more problems than it solve.
Well, good communications has been and continues to be a problem. I think a certain amount of the problem is that the vast majority of the developers can just talk to one another, so there's no record of the discussion or notification of changes taking place somewhere those of us who aren't at IDA can look at.
So, until someone at IDA volunteers to take notes, or one of us decides to move to sweden, it's going to continue to be a problem.
I agree, but low level change should not be kept secret... And I still think that changing low level thing on Pike C modules every day will make some developper more and more lazy about Pike...
I don't think that "being public" is the problem. I mean, it's not like there isn't a fine web interface to the changes that do get made. The problem is that no one is "interpreting" the changes and letting the non-core developers know about it. The pike newsletter was a nice idea, but there was only one issue of it.
I am a bit surprised that so much changes inside current pike (that'll maybe be future stable pike ?) are not public ?
I have to admit, it would be nice if a changelog were updated _as_ features got added, rather than an afterthought. It's always easier to prune entries than to go back afterwward looking for things that changed.
How about it? I think that would be a good policy to have: if you add or change functionality, you should have a description of the change or addition in the CHANGELOG. No exceptions.
Where is a changelog about that ? Nothing ?
As always, documentation is a problem. I'm slowly progressing with the tutorial, but that doesn't address the other problems such as c module development. I don't know that complaining more about the problem will do any good, as the people who have the knowledge to write the docs are so busy (understandably) with other things. My solution was to learn how to write modules and then document the process. I've not gotten very far with that yet, though.
Bill
/ Brevbäraren
Sigh.
Stop treating Pike developing version as a release version. If you don't want to be involved in the development of the langauge Pike, stay away from the develop version.
No changes are secret. The CVS is there for everyone to read. There is a fully functional and very usable CVS viewer at the Pike site. Use it.
Yes we can... But AFAIK "official" system was optional some day ago. So giving it as mandatory will give us (= Caudium) more problems than it solve.
I fixed the Makefile for an external module made at Roxen IS a few years back to use the "official" system. It was as complicated as making a Makefile with
all: (cd Module; pike -x module all module.so MAKE=$(MAKE))
I am a bit surprised that so much changes inside current pike (that'll maybe be future stable pike ?) are not public ?
I'm surprised that you think much has changed. You need to update your Makefile. Had you made your Makefile properly (i.e. including the apropriate src/modules/ include files) you wouldn't even need that.
I have asked for a commit log sent by mail one year ago to help external developpers to see what are the changes... But nothing as usual...
There are no internal developers. Only those who do stuff and those who don't. There are no secret meetings where Roxen and ex-Roxen people decide the future of Pike. This is where Pike development is discussed. Appearently no one else thought it was necessary to complement the CVS viewer with a mailer. Why have you not made a mailer yourself?
The main problem is killing API will kill pike because :
I am a bad C programmer. I am a fairly decent programmer, but I'm not good at C. That hasn't stopped me from making several C-modules using the cmod API without really having any help from anyone. I agree that it is tricky to have to look for calling examples in the code or reading the actual core code instead of a proper documentation. Anyone who knows some C can really write a C API documentation, and I have several times asked the "pike community" for help, but nothing as usual...
/ Martin Nilsson (provokatör)
Previous text:
2004-03-29 19:21: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Le 29 mars 04, à 14:35, Bill Welliver a écrit :
Well, while it would have been nice to know that this happened up front, it's not the end of the world, really. I mean, as an example, the caudium devel tree only supports 7.5, so why not use the new "official" system? It would certainly clean up the mess of stuff we have to spend our time maintaining, wouldn't it?
Yes we can... But AFAIK "official" system was optional some day ago. So giving it as mandatory will give us (= Caudium) more problems than it solve.
As for old stuff, I personally am working on getting the development version stable so I don't have to maintain old code. And for code that must be kept, I do it separately. We'll probably expend more effort discussing the merits and whys of this situation longer than it would take to just "bite the bullet" and do it.
I think it's unreasonable to expect things to not change and improve just so we lazy developers don't have to update our code. Once every four years isn't that bad.
I agree, but low level change should not be kept secret... And I still think that changing low level thing on Pike C modules every day will make some developper more and more lazy about Pike...
I am a bit surprised that so much changes inside current pike (that'll maybe be future stable pike ?) are not public ?
Where is a changelog about that ? Nothing ?
I have asked for a commit log sent by mail one year ago to help external developpers to see what are the changes... But nothing as usual...
The main problem is killing API will kill pike because :
- no changelog
- too little (or maybe near no) docs for core developpers
- some things are very hard to be done... :
- cmod : is there any BNF / docs clearly explained on how to make
them ?
- pike C modules : they are bloody hard to make, but changing the low
level api will tell developpers : "ok the thing is not mature, I will go somewhere else where it is mature".
Maybe this is done for a secret reason, but what ever it is, it is very not a good think for our litle pike community.
My 0,02...
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
/ Brevbäraren
I have asked for a commit log sent by mail one year ago to help external developpers to see what are the changes... But nothing as usual...
Commit logs are available via http from both pike.ida.liu.se and community.roxen.com. Unfortunately nobody has implemented smtp support into either system.
The main problem is killing API will kill pike because :
- too little (or maybe near no) docs for core developpers
Some core subsystems are documented; cf src/code/README.txt, src/gc.c etc.
- some things are very hard to be done... :
- cmod : is there any BNF / docs clearly explained on how to make them ?
http://pike.ida.liu.se/projects/docs/cmods/cmod-thesis.pdf http://pike.ida.liu.se/projects/docs/cmods/cmod-tutorial.pdf
- pike C modules : they are bloody hard to make, but changing the low level api will tell developpers : "ok the thing is not mature, I will go somewhere else where it is mature".
Hard? What do you find hard?
/Xavier
/ Henrik Grubbström (Lysator)
Previous text:
2004-03-29 19:21: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Le 29 mars 04, à 14:35, Bill Welliver a écrit :
Well, while it would have been nice to know that this happened up front, it's not the end of the world, really. I mean, as an example, the caudium devel tree only supports 7.5, so why not use the new "official" system? It would certainly clean up the mess of stuff we have to spend our time maintaining, wouldn't it?
Yes we can... But AFAIK "official" system was optional some day ago. So giving it as mandatory will give us (= Caudium) more problems than it solve.
As for old stuff, I personally am working on getting the development version stable so I don't have to maintain old code. And for code that must be kept, I do it separately. We'll probably expend more effort discussing the merits and whys of this situation longer than it would take to just "bite the bullet" and do it.
I think it's unreasonable to expect things to not change and improve just so we lazy developers don't have to update our code. Once every four years isn't that bad.
I agree, but low level change should not be kept secret... And I still think that changing low level thing on Pike C modules every day will make some developper more and more lazy about Pike...
I am a bit surprised that so much changes inside current pike (that'll maybe be future stable pike ?) are not public ?
Where is a changelog about that ? Nothing ?
I have asked for a commit log sent by mail one year ago to help external developpers to see what are the changes... But nothing as usual...
The main problem is killing API will kill pike because :
- no changelog
- too little (or maybe near no) docs for core developpers
- some things are very hard to be done... :
- cmod : is there any BNF / docs clearly explained on how to make
them ?
- pike C modules : they are bloody hard to make, but changing the low
level api will tell developpers : "ok the thing is not mature, I will go somewhere else where it is mature".
Maybe this is done for a secret reason, but what ever it is, it is very not a good think for our litle pike community.
My 0,02...
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
/ Brevbäraren
Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
I have asked for a commit log sent by mail one year ago to help external developpers to see what are the changes... But nothing as usual...
Commit logs are available via http from both pike.ida.liu.se and community.roxen.com. Unfortunately nobody has implemented smtp support into either system.
Maybe you can use http://sourceforge.net/projects/cvs-syncmail
Nevertheless even if commits logs are usefull I think a ChangeLog that everybody change when he feels he made something new or that is not compatible is a good thing to do. It's better and far much easier to do it after you coded something because:
. It's the person who changed the code that write it so he knows the best. . Less chances of forgotting something . No need for a hard time making the ChangeLog for a single person when making the release . Help people that follow Pike developpment but that can't follow all the commits logs to understand better what is going to happen.
/ David
Commit logs are available via http from both pike.ida.liu.se and community.roxen.com. Unfortunately nobody has implemented smtp support into either system.
Maybe you can use http://sourceforge.net/projects/cvs-syncmail
Is anyone against using syncmail ?
It's really easy to install, the longer part being creating a pike-commits mailing list but only a root @ pike.ida.liu.se can install it. I'm personnaly very interested in receiving commit logs by email.
If you don't want to bother with setting up a mailing list I'm sure we can setup one @caudium.net.
/ David
Personally, I´d rather see a RSS feed from the CVS repository. It is really easy to hack such a view of the checkins and that way I don't get more mail that I never have the time to read...
/ Marcus Agehall (Scanian)
Previous text:
2004-03-30 14:37: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Commit logs are available via http from both pike.ida.liu.se and community.roxen.com. Unfortunately nobody has implemented smtp support into either system.
Maybe you can use http://sourceforge.net/projects/cvs-syncmail
Is anyone against using syncmail ?
It's really easy to install, the longer part being creating a pike-commits mailing list but only a root @ pike.ida.liu.se can install it. I'm personnaly very interested in receiving commit logs by email.
If you don't want to bother with setting up a mailing list I'm sure we can setup one @caudium.net.
/ David
/ Brevbäraren
Didn't codelibrarian get an RSS mode after Per's changes?
/ Peter Bortas (Kein Paket!)
Previous text:
2004-03-30 14:49: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Personally, I´d rather see a RSS feed from the CVS repository. It is really easy to hack such a view of the checkins and that way I don't get more mail that I never have the time to read...
/ Marcus Agehall (Scanian)
I was more asking if anyone was against having syncmail on the pike server or against some people could receive your work by email (I don't see why it would be a problem, but I'm just asking in case), if you don't subscribe to the mailing list, you won't receive more mail and thus there is no need to be against for your reason since we can have both.
BTW about the reason why I prefer mail it's because it's a push thing: I get the log when someone commit, I don't have to check regulary myself.
Marcus Agehall (Scanian) @ Pike (-) developers forum wrote:
Personally, I´d rather see a RSS feed from the CVS repository. It is really easy to hack such a view of the checkins and that way I don't get more mail that I never have the time to read...
/ Marcus Agehall (Scanian)
Previous text:
2004-03-30 14:37: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Commit logs are available via http from both pike.ida.liu.se and community.roxen.com. Unfortunately nobody has implemented smtp support into either system.
Maybe you can use http://sourceforge.net/projects/cvs-syncmail
Is anyone against using syncmail ?
It's really easy to install, the longer part being creating a pike-commits mailing list but only a root @ pike.ida.liu.se can install it. I'm personnaly very interested in receiving commit logs by email.
If you don't want to bother with setting up a mailing list I'm sure we can setup one @caudium.net.
/ David
/ Brevbäraren
Don't get me wrong here. If you like to have e-mails, you may. I'm merely pointing out an alternative which does the pulling part for you. I don't like the push-method, but as you pointed out, I don't have to use it.. ;)
/ Marcus Agehall (Scanian)
Previous text:
2004-03-30 15:08: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
I was more asking if anyone was against having syncmail on the pike server or against some people could receive your work by email (I don't see why it would be a problem, but I'm just asking in case), if you don't subscribe to the mailing list, you won't receive more mail and thus there is no need to be against for your reason since we can have both.
BTW about the reason why I prefer mail it's because it's a push thing: I get the log when someone commit, I don't have to check regulary myself.
Marcus Agehall (Scanian) @ Pike (-) developers forum wrote:
Personally, I´d rather see a RSS feed from the CVS repository. It is really easy to hack such a view of the checkins and that way I don't get more mail that I never have the time to read...
/ Marcus Agehall (Scanian)
Previous text:
2004-03-30 14:37: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Commit logs are available via http from both pike.ida.liu.se and community.roxen.com. Unfortunately nobody has implemented smtp support into either system.
Maybe you can use http://sourceforge.net/projects/cvs-syncmail
Is anyone against using syncmail ?
It's really easy to install, the longer part being creating a pike-commits mailing list but only a root @ pike.ida.liu.se can install it. I'm personnaly very interested in receiving commit logs by email.
If you don't want to bother with setting up a mailing list I'm sure we can setup one @caudium.net.
/ David
/ Brevbäraren
/ Brevbäraren
Don't get me wrong here. If you like to have e-mails, you may. I'm merely pointing out an alternative which does the pulling part for you. I don't like the push-method, but as you pointed out, I don't have to use it.. ;)
okay.
There is some people that like email, other that like using their navigator to look at a website to see changes, other that like RSS...
David's proposition is not mandatory, if you don't like mail, then don't subscribe the mailing list.... that's simple.
But if a mailing list is made you :
- subscribe on it - subscribe on it with disgest mode - not subscribe on it
It is end user's problems.
I don't see why commits log cannot be sent by mail as well than other way of getting it.
On other hand, the cvssync from sourceforge is stable (very stable I can say) and *fast* to install. It is just an very easy administrator task and can be done in 5 minutes.
Yes we can reinvent another one that does RSS, but I think it is mutch faster than reinvent the wheel... and can the pike community afford the price to make a "cvssync that rocks and make everything people like." ?
Just make add cvssync, make a mailing list if you like (or tell us, the caudium group to make it if you don't want to waste time to make the mailing list) and make announce on pike-devel and pike mailing list.
This should be a small thing to do, but the biggest one that the pike community have made for external developpers.
Sincerly, /Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
Some core subsystems are documented; cf src/code/README.txt, src/gc.c etc.
There is actually some quite useful documentation of C-functions and macros available in Pike 0.5. Needless to say it is nothing near complete or up to date.
/ Martin Nilsson (provokatör)
Previous text:
2004-03-29 20:07: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
I have asked for a commit log sent by mail one year ago to help external developpers to see what are the changes... But nothing as usual...
Commit logs are available via http from both pike.ida.liu.se and community.roxen.com. Unfortunately nobody has implemented smtp support into either system.
The main problem is killing API will kill pike because :
- too little (or maybe near no) docs for core developpers
Some core subsystems are documented; cf src/code/README.txt, src/gc.c etc.
- some things are very hard to be done... :
- cmod : is there any BNF / docs clearly explained on how to make them ?
http://pike.ida.liu.se/projects/docs/cmods/cmod-thesis.pdf http://pike.ida.liu.se/projects/docs/cmods/cmod-tutorial.pdf
- pike C modules : they are bloody hard to make, but changing the low level api will tell developpers : "ok the thing is not mature, I will go somewhere else where it is mature".
Hard? What do you find hard?
/Xavier
/ Henrik Grubbström (Lysator)
There's also the "PIKE C MODULE HOW-TO" that Elias Levy wrote for Pike 0.6.
/ Henrik Grubbström (Lysator)
Previous text:
2004-03-29 20:10: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Some core subsystems are documented; cf src/code/README.txt, src/gc.c etc.
There is actually some quite useful documentation of C-functions and macros available in Pike 0.5. Needless to say it is nothing near complete or up to date.
/ Martin Nilsson (provokatör)
I've been thinking about folding the 0.5 function/macro documentation into the source, making a parallell autodoc documentation (/*: perhaps). However I would like it to read the C prototypes and make it as easy to use as pike autodoc in that regard. Since it probably would take some effort I've refrained so far.
/ Martin Nilsson (provokatör)
Previous text:
2004-03-29 20:12: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
There's also the "PIKE C MODULE HOW-TO" that Elias Levy wrote for Pike 0.6.
/ Henrik Grubbström (Lysator)
Ah. Sorry for the missinterpretation.
/ Peter Bortas (Kein Paket!)
Previous text:
2004-03-29 14:00: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Yes, that's what I said: for modules < 7.4 meaning for 7.2, 7.0 and so on then you have a problem.
Peter Bortas (Kein Paket!) @ Pike (-) developers forum wrote:
I distinctly remember compiling modules with -x module in 7.4 as late as just last week.
/ Peter Bortas (Kein Paket!)
Previous text:
2004-03-29 13:50: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Martin Nilsson (provokatör) @ Pike (-) developers forum wrote:
but outside that, eg custom pike C modules made (hardly) by hand, the .pmod is not automatically generated.
Not if you use the correct build procedure (pike -x module) for external modules.
...which doesn't solve the compatibility problems for modules < 7.4 anyway.
/ Brevbäraren
I don't see why you would need any changes.
to replace ADD_FUNCTION() to add_function_constant() to workaround this change.
That seems like a very strange work around to me. The obvious one is to instead do a wrapper like the one that pike -x module would.
NB: I also think those wrappers are messy and should disappear again. I think it's better to let C modules be objects (in the static case too) and perhaps have a magic constant to let them tell that they don't want to be cloned.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-03-29 13:22: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Le 27 mars 04, à 20:20, Henrik Grubbström (Lysator) @ Pike (-) developers forum a écrit :
This is really bad... This make all pike C modules now incompatible between pike version... ;(
Not for normal usage; a corresponding .pmod is automatically generated.
normal usage yes... eg pike C modules generated *inside* pike source code.
but outside that, eg custom pike C modules made (hardly) by hand, the .pmod is not automatically generated.
Very bad thing for pexts, and all hardly developped pike modules in C...
So bad there is no warning on this important code change...
We will add lots of #ifdef but, this is bad ;(
I don't see why you would need any changes.
to replace ADD_FUNCTION() to add_function_constant() to workaround this change.
NB: The reason for the change is to reduce the differences between dynamic and static modules.
This one is good.... but external (home made) modules are allways dynamic modules (eg .so)...
/Xavier
Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
/ Brevbäraren
How about using the magic identifier "_module_value" which is already allocated for such purposes? If it exists as a constant, use that value as the module value instead of cloning the program.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-03-31 18:28: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
I don't see why you would need any changes.
to replace ADD_FUNCTION() to add_function_constant() to workaround this change.
That seems like a very strange work around to me. The obvious one is to instead do a wrapper like the one that pike -x module would.
NB: I also think those wrappers are messy and should disappear again. I think it's better to let C modules be objects (in the static case too) and perhaps have a magic constant to let them tell that they don't want to be cloned.
/ Martin Stjernholm, Roxen IS
I wouldn't mind, but maybe it'd have to be fixed so that it works for static modules too?
/ Martin Stjernholm, Roxen IS
Previous text:
2004-03-31 20:01: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
How about using the magic identifier "_module_value" which is already allocated for such purposes? If it exists as a constant, use that value as the module value instead of cloning the program.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
That would be the idea, yes. Static and dynamic modules should work the same, and they should work like dynamic modules used to work in 7.4 since that's what the largest amount of external code depends on.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-03-31 21:49: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
I wouldn't mind, but maybe it'd have to be fixed so that it works for static modules too?
/ Martin Stjernholm, Roxen IS
On Sat, Mar 27, 2004 at 08:13:06PM +0100, Xavier Beaudouin wrote:
We will add lots of #ifdef but, this is bad ;(
I don't think so. Only slight change is necesary for every C module, and - what is good - it will work both in 7.4 _and_ 7.5.
But I agree that this change better be announced (however, I guess it was).
Regards, /Al
We need a #pike for C modules :)
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2004-03-27 20:14: Subject: Re: ADD_FUNCTION() macro on pike 7.5 ?
Hello
For Pike 7.5, you should use PIKE_MODULE_INIT, not "void pike_module_init( void )". This works in 7.4 too.
Although I bet your actual problem is that C modules are now programs, not objects. So you need to instantiate them before accessing non-constant members. This is the most brain-damaged aspect of 7.5.
This is really bad... This make all pike C modules now incompatible between pike version... ;(
Very bad thing for pexts, and all hardly developped pike modules in C...
So bad there is no warning on this important code change...
We will add lots of #ifdef but, this is bad ;(
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
/ Brevbäraren
Although I bet your actual problem is that C modules are now programs, not objects. So you need to instantiate them before accessing non-constant members. This is the most brain-damaged aspect of 7.5.
What's the reason for that?
/ Mirar
Previous text:
2004-03-26 23:51: Subject: ADD_FUNCTION() macro on pike 7.5 ?
For Pike 7.5, you should use PIKE_MODULE_INIT, not "void pike_module_init( void )". This works in 7.4 too.
Although I bet your actual problem is that C modules are now programs, not objects. So you need to instantiate them before accessing non-constant members. This is the most brain-damaged aspect of 7.5.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
Bill Welliver -
David Gourdelier -
Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum
-
Marcus Agehall (Scanian) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (provokat�r) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Peter Bortas (Kein Paket!) ＠ Pike (-) developers forum
-
Xavier Beaudouin