[crossfire] New type sstring?

[Nicolas Weeger]

Hello.

I'd like to add a typedef const char* sstring and use that for relevant 
members / variables. sstring is of course shared_string.

It wouldn't change much things, but clarify when the string is shared 
(add_string / add_refcount) and when it's safe to alter it.

Unless I'm mistaking the const char* - sstring conversion would be implicit, 
so wouldn't need to change all functions immediately :)

What do you think of that?

Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'aléatoire !]

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Plugin API

[Nicolas Weeger]

Hello.

I'd like to propose changes to the plugin API.

Currently, plugins call eg char* directory = cfapi_system_directory(val, 3) 
to get a directory information.

I'd like to change that to the general format: int result = 
cfapi_system_directory(val, 3, directory, sizeof(directory)) with result a 
plugin-specific code (0 = no error, 1 = invalid parameter, ...)

Basically, to wrap a server function
object* get_split_ob(object* ob, int nrof)
one should call
cfapi_object_get_split(val, ob, nrof, split)
with object* split.


This way, the plugin layer could return some information (object was lost, 
invalid parameter).
It would also avoid having static variables used to return int/float values.

If no one objects, I'd feel like doing that starting around next week :)

Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'aléatoire !]

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] New type sstring?

[Alex Schultz]

Nicolas Weeger wrote:
 I'd like to add a typedef const char* sstring and use that for relevant 
 members / variables. sstring is of course shared_string.

 It wouldn't change much things, but clarify when the string is shared 
 (add_string / add_refcount) and when it's safe to alter it.

 Unless I'm mistaking the const char* - sstring conversion would be 
 implicit, 
 so wouldn't need to change all functions immediately :)

 What do you think of that?
I'd say this would be a great idea as it would make it easier to tell in
the code when things are a shared string :)
I'm not 100% sure of the choice of that particular name 'sstring',
however I don't have any better alternatives in mind at the moment.

Alex Schultz

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/

[Mark Wedel]

Kevin R. Bulgrien wrote:
 Log Message:
 ---
 1.10 branch
 Hello.

 I (and I'm sure others) would have appreciated some notification of
 incoming 1.10 release, as I'm trying to fix some things related to Windows
 version of server.

 Could I ask for ~2 weeks notice before releases, so we can freeze stuff
 and fix critical/blocking bugs?

 Nicolas
 
 The old adage about CVS not being a replacement for developer communication
 likely applies well in this situation, IMO.
 
 2 weeks not needed here as _any_ notice would be appreciated.  I had two
 regressions to fix in maps.  I could have had them fixed in a few hours,
 but had just discovered them through playtesting and was needing to
 experiment a bit to learn how to fix them.  (I have fixed them now, but it
 is too late.)  With 24 or 48 hours notice, these regressions might have
 been fixed for the release as I could have upped priority for hammering
 out a correction.
 
 I acknowledge it is my problem for not having tested well enough before
 committing.  At the time I did test on my server, but did not have in mind
 the nuances of testing for hidden attribute changes that come in from the
 arch when switching out floor pieces.  I know now, so hopefully it won't
 happen again.


  As said before in other thread, sorry about no advanced notice.

  If I knew I was going to make the release last weekend, I would have given 
advanced noticed.

  It just turned out that I found myself with the time to do the release when I 
sat down at the computer at the weekend.  So I basically had these options:

1) Start the release process since I know I had time then.

2) Give notice about an upcoming release, and hope that I'd actually have the 
time to do it before when I said so.  My estimated probability of this was low 
(and if the deadline is missed, it almost seems like the process is restarted, 
since at some point, the immediancy of a release coming out goes away.

3) Do neither - wait 2-3 months when I estimate I may have time, and schedule a 
release then (which would be when the release is done if I missed schedule on 
#2)

  IMO, none of those is ideal - the ideal is ability to announce I'll do a 
release in 2 weeks, and then actually do the release then.  But as of right 
now, 
that seemed low.  And since there were no docs, its not like I could point 
someone else to do the release in that timely fashion.  Hopefully, since I'm 
writing docs, that may be more doable.

  Looking back, the only thing I might really change is perhaps saying 
something 
on irc like I'm going to do a release starting right now - if you have 
anything 
ready to commit, let me know now and commit it, to catch any of those ready to 
commit fixes (but that in itself can sometimes be dangerous).  If I had a time 
machine, I'd send a note to myself 2 weeks ago to send mail to the list saying 
I'm going to do a release in 2 weeks.  But I have to go on what I knew at the 
time, not what I knew later.

  Otherwise, I still think my decision to do a release now is better than 
waiting another 2 months for a release.  Even though the code has some bugs, 
I'd 
say it is better than what is out there right now as 1.9.1, and at some level, 
getting code out there for others to use has some advantages.

  This is one of the arguments for frequent releases - sure, each build will 
have some bugs, and could be made better if delayed, but by getting the builds 
out there, you get people to discover some of those new bugs so that they can 
get fixed in the next release.  If infrequent releases are done, quality may in 
fact not be better because people are stuck using an old buggy build for a 
longer time period.

  Now to turn this more constructive, I think the real question is:  How often 
should we be doing releases?  Every month?  Every 3 months?  Somewhere in 
between?

  I think anything more frequent then every month (save for critical builds/to 
fix something DOA) doesn't make much sense, as I don't think the 1.x branch is 
changing fast enough.

  I also think that less than every 3 months is too long a gap - just looking 
at 
the client, there were lots of things changed since the last release, such that 
if there were 3 releases in that time period, each would still have enough 
changes to be compelling.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire