Log for on 20th December 2012:
Times are UTC Toggle Colours
01:12:29  *** FLHerne has quit IRC
01:32:19  *** Zuu has quit IRC
04:53:48  *** Supercheese has joined
06:07:06  <planetmaker> michi_cc: wrt patch 0001: can't we detect incomplete initialization? Wouldn't it be better to return a default value for 4C before complete intialization?
08:30:31  *** Zuu has joined
08:30:31  *** ChanServ sets mode: +v Zuu
08:42:09  *** Zuu has quit IRC
09:26:46  *** FLHerne has joined
09:46:30  *** FLHerne has quit IRC
11:07:48  <michi_cc> planetmaker: It does return a "default" value without the assert (0, what the memory is initialized to). As this is identical to the behaviour var 98 (max speed) always had, which no NewGRF seems to have a problem with, I don't think we need any other special value.
12:30:54  *** Supercheese has quit IRC
12:31:24  *** Supercheese has joined
13:07:27  <planetmaker> ah, right. Ok, then I agree. Btw, and for what it's worth: the other patch, 0002,  looks good to me
13:41:28  *** welshdragon has quit IRC
13:59:06  *** ntoskrnl has joined
14:17:43  <Belugas> hello
14:41:03  <michi_cc> And
14:41:28  <michi_cc> There's some chance I missed usage of one of the magic numbers somewhere though.
14:45:47  <planetmaker> that's the fix for pikka's recent bug report?
14:48:57  <michi_cc> For the last one (well first one :), yes. You've seen my ideas for the other two reports already.
14:49:56  <michi_cc> If we want more commits, that one could be split into a codechange and a fix.
14:51:01  <planetmaker> I don't really mind either way. Might be nicer, but...
14:51:37  <planetmaker> ... it's still small enough to understand without split
17:13:24  *** michi_cc has quit IRC
17:15:23  *** michi_cc has joined
17:15:24  *** ChanServ sets mode: +v michi_cc
17:28:20  *** frosch123 has joined
17:28:20  *** ChanServ sets mode: +v frosch123
17:28:56  *** Zuu has joined
17:28:56  *** ChanServ sets mode: +v Zuu
17:31:37  <michi_cc> frosch123: and
17:37:07  <frosch123> what part of 5396 is a codechange, what the fix?
17:38:55  <frosch123> ChangeVehicleWindow is called for a lot of different windows
17:39:03  <frosch123> can you replace -666 with -4 in all cases?
17:39:10  *** FLHerne has joined
17:41:54  <frosch123> 5398: how long is the value invalid?
17:42:15  <frosch123> only for a tick, or till the vehicle is started ?
17:46:35  <frosch123> ah, ConsistChanged sets the max speed
17:47:16  <frosch123> then it should be fine, though i wonder whether there is a clever place to add a comment about it
17:50:03  <frosch123> 5397 looks nice :) i hope all speedlimits are now in one place :p
18:07:03  <Zuu> Perhaps is useful in trunk no matter if my other goal GUI patch is committed.
18:07:19  *** Alberth has joined
18:07:19  *** ChanServ sets mode: +v Alberth
18:07:25  <Zuu> It reduce code duplication.
18:08:39  <Zuu> The other patch add complete state to goals and a progress column with progress info + visualzation of complete goals.
18:09:18  <frosch123> "int& pos" -> "int &pos"
18:09:47  <Zuu> oh yeah
18:10:12  <Alberth> moin
18:10:21  <Zuu> hello Alberth
18:11:20  <Alberth> is there anybody working on the regions currently?
18:12:03  <frosch123> i am not, and i don't consider the specs finished :)
18:12:31  <frosch123> it needs some clever way to define complex region shapes unter a single id
18:12:37  <frosch123> *under
18:12:44  *** ntoskrnl has quit IRC
18:13:21  <frosch123> Zuu: i would have used ? : instead of (global_section ...) || (!global_section ...)
18:13:27  <frosch123> diff loks fine though
18:20:09  <Alberth> hmm, real and imaginary region shape parts eh?
18:20:40  <Alberth> who defines these regions? ie what kind of expressions can you reasonably expect to be available?
18:21:02  <Alberth> could we eg have  Region1 || Region2  or so?
18:21:35  <frosch123> basic shapes should be rectangles and euclidian circles
18:21:56  <frosch123> || and ! are most likely needed
18:22:05  <frosch123> so one might as wel add &&
18:22:41  <frosch123> || is needed for any complex shape which you can build from multiple rectangles
18:22:49  <frosch123> ! is needed to apply something for everything but a specific region
18:23:49  <Alberth> ! and && together are sufficient, together with the DeMorgan rule, theoretically, I think
18:23:56  <frosch123> so, do we need all of ! || and &&, or does it suffice to have || and maybe a single ! at the very front
18:24:13  <frosch123> ! and || are also sufficient :p
18:24:24  <Alberth> yep :)
18:24:52  <frosch123> but yeah, i meant allowing ! only in front, so only (a || b || ...) and !(a || b || ,..)
18:24:58  <Alberth> but for simplicity, I'd just allow all 3 operators in anyway you like
18:25:08  <Alberth> s/any/any /
18:25:18  <frosch123> i have no idea how to represent those internally :)
18:25:47  <Alberth> simplest would be an expression tree
18:25:54  <frosch123> i.e. whether to make the script construct a parser tree, or whether they are combined from other regions
18:26:26  <frosch123> maybe there is also some clever way to do it with nested squirrel structures
18:26:37  <frosch123> instead of some weird api functions
18:26:55  <Alberth> and you can flatten them to normal form if you like to reduce height
18:27:48  <frosch123> hmm, yeah, storing them in normal form might be the best for savegame representation
18:27:51  <frosch123> just some array :)
18:28:05  <Alberth> other regions could be a starting point, so you can stack them nicely
18:28:24  <frosch123> so, maybe it can also be an array/table representation in squirrel
18:28:31  <Alberth> can you remove regions?
18:28:34  <frosch123> with some general bool functions
18:29:09  <frosch123> i would think that regions are only stored if they have some restriction assigned
18:29:19  <frosch123> in whcih case they can be addressed via an id
18:29:46  <Alberth> so you have to create a restriction and a region at the same time then?
18:29:46  <frosch123> currenlty i wonder whether one can separate the shape construction from the ottd gamestate
18:30:35  <frosch123> i meant constructing a shape purely in squirrel (not in ottd gamestate), then a speical api function to store a shape, which returns an ID
18:30:44  <frosch123> and then various methods to assign restrictions to a region ID
18:31:09  <frosch123> resp, the reverse case: setting the region id in something else
18:31:16  <frosch123> like passing a region id to a goal or newsitem
18:31:25  * Belugas fetches some popcorn and watches
18:34:02  <Alberth> "regions are only stored if they have some restriction assigned" clashes with "constructing a shape purely in .. then a speical api function to store a shape ... and then various methods to assign restrictions", doesn't it?
18:34:21  * Alberth takes some popcorn from sir B
18:34:32  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24829 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:35:07  <frosch123> Alberth: i mean storing them in the ottd gamestate
18:35:19  <frosch123> we do not store squirrel variables in the gamestate
18:35:46  <Zuu> Thanks for the review frosch123 :-)
18:36:26  <Alberth> ah, the api function to store a shape is not still squirrel?
18:36:44  <Alberth> *still in squirrel
18:36:50  <frosch123> Alberth: you could construct a shape completely in squirrel by nesting tables: { add1 = circle1, add2=rect1, sub3={add1=circle, add2=rect} }
18:37:11  * Alberth nods
18:37:17  <frosch123> then call some api function : GSRegion::Create( above struct ) -> regionID
18:37:41  <Alberth> is it in ottd gamestate after the call?
18:37:51  <frosch123> in the savegame, yes
18:38:07  <frosch123> the call would have to send it over the network to all clients
18:38:11  <Alberth> so, what restriction has it assigned then at that point?
18:38:18  <frosch123> since the region checks also needs perfoming on the clients
18:38:39  <frosch123> the "empty" restriction? :p
18:39:13  <frosch123> but yeah, if you meant that above, then you are right about the clash :)
18:39:52  <Alberth> I did :)
18:41:14  <Alberth> so it's two separate processes I think; defining regions, and setting restrictions
18:41:53  <frosch123> yup, i think that is settled
18:42:03  <michi_cc> frosch123: and
18:42:11  <frosch123> i just do not know how many restrictions of which type one could set per region
18:42:41  <michi_cc> And there's exactly one other, totally unrelated use of -666 in the code (SQ_SUSPEND_FLAG in sqvm.h)
18:43:01  <frosch123> must also be a troublesome flag then :)
18:43:51  <Alberth> how is "per region" important? I'd save the regions next to the type
18:44:26  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24830 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:46:20  <Alberth> michi_cc: are negative numbers allowed in an enum?
18:47:06  <frosch123> Alberth: i mean, if you save region a and set it to not allow terraforming for company a, and then you want to disallow company b to build rail in the same shape: do you need a new region id or can you add different restrictions for different companies to the same id?
18:47:49  <michi_cc> Alberth: "The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration." No exclusion of signed types.
18:48:24  <Alberth> I would allow re-use of region IDs, it makes specifying what you mean/want easier.
18:48:49  <frosch123> Alberth: but it makes for a very complicated api
18:49:00  <frosch123> you would have to pass everything to the same function
18:49:14  <frosch123> you cannot add different function for setting the restrictiontype and for setting a companyfilter
18:49:21  <frosch123> and another one for the text to display
18:49:38  <Zuu> Perhaps make it so that restrictions can be altered after the region have been created?
18:49:48  <Zuu> Then you only need to specify one restriction in each call
18:50:06  <frosch123> and it is even harder to read them back
18:50:09  <Zuu> Eg. GSRegion.SetRestriction(region_id, company_id, restriction_enum)
18:51:03  <frosch123> so it would guess it is a lot easier to use, if the api would just provide a bunch of get/set functions which each set a single property
18:51:15  <frosch123> which are combined to a single restriction
18:51:28  <frosch123> similiar like orders :)
18:51:47  <frosch123> if you want to refit to grain and livestock you also need two orders
18:54:03  <frosch123> michi_cc: looks nice, we should have started with using enums for such stuff earlier :)
18:56:18  <frosch123> Zuu: your rtl screenshot looks correct
18:56:35  <frosch123> arabic numbers look the same in arabic as in the west :)
18:57:10  <frosch123> just that they are little endian in arabic, and big endian in the west
18:57:13  <Zuu> I was about to write "western numbers" but realized that we probably didn't invent them. :-)
18:57:19  <Alberth> I don't understand how enabling re-use of a region id makes life more difficult, api-wise. you have to specify a region-id somehow, why does it matter that the same id is used already for something else?
18:57:41  <frosch123> Alberth: how do you access the restrictions?
18:57:48  <frosch123> or do you also want to add a restriction id?
18:58:11  <Alberth> access to do what?
18:58:24  <frosch123> change it, remove it, extend it
18:58:36  <frosch123> or even "read it"
18:59:14  <Alberth> doesn't it make sense to state what region id you want to change/remove/extend/read?
18:59:31  <frosch123> i mean functions like ScriptOrder::IsGotoStationOrder, GetOrderRefit, SetOrderJumpTo
19:00:02  <frosch123> they all modify a specific order
19:00:03  <Alberth> oh wait a second, restrictionIDs. That's new for me
19:00:28  <frosch123> Alberth: imo it does not need restriction ids :)
19:00:45  <frosch123> but it would need them if you can assign different restritions to the same region
19:01:50  <frosch123> but ofc one can also see restrictions just like goals or news entries
19:02:06  <frosch123> give them a separate id, and then assign a region id to them just like one might assign a regionid to news or goals
19:02:12  <frosch123> maybe that is the cleaner approach :)
19:02:35  <frosch123> since it separate the shapes (which could also be useful for other things than restrictions) from the actual restrictions
19:06:10  <Alberth> it starts to feel java-ish :p
19:09:14  <Alberth> but yeah, it is a cleaner solution than using region ids directly
19:30:38  <michi_cc> frosch123: I'm going to commit the stuff now unless you have some clever comment idea for 5398.
19:31:13  <frosch123> i havent :)
19:43:14  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24831 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:43:17  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24832 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:43:21  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24833 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:43:26  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24834 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:52:55  <Zuu> What is the opinion on my change to allow GSs to specify a progress text for each goal? The same patch also adds a boolean property 'complete' for each goal. If this property is true, the progress text change from orange to green.
19:53:17  <Zuu> Should I perhaps move the 'complete' stuff to a later patch or is it fine as is?
19:53:51  <Zuu> More importantly, is this a change that is an improvement over the current situation?
19:54:25  <frosch123> i would still prefer to make the progress a GSText instead of a always a percentage
19:54:37  <Zuu> It is a GSText
19:54:54  <frosch123> that changeD?
19:55:42  <Zuu> +	static bool SetProgress(GoalID goal_id, Text* progress);
19:55:44  <Zuu> 
19:56:03  <frosch123> if (g->progress != NULL) free(g->progress); <- just free(g->progress)
19:56:05  <frosch123> no if needed
19:57:47  <frosch123> did you use the script to generate script_window.hpp ?
19:58:00  <frosch123> it surprises me that the whitespace changes
19:58:01  <Zuu> Your point to allow "3/8" strings for progress made more sense than the AI benefits for a numerical progress as making the goal system to be undestandable by AIs is quite hard anyways.
19:58:38  <frosch123>  Checks if a given goal have been marked as completed. <- has been
19:59:42  <frosch123> +	 * @pre goal != NULL && len(goal) != 0. <- what does that mean?
19:59:55  <frosch123> i guess it should say IsValidGoal(goal_id).
20:00:37  <Zuu> goal is the goal text
20:00:59  <Zuu> It means that the goal text shouldn't be NULL and have a non-zero length.
20:01:14  <Zuu> s/and/or/
20:01:39  <frosch123> ah, it is from the SetText fucntion
20:01:46  <frosch123> remove it from the SetCompleted then :)
20:02:05  <frosch123> also "Text* goal" -> "Text *goal" :)
20:02:31  <frosch123> + * \li GSWindow::WID_GL_GOAL <- we do not add those to the changelog
20:02:54  <frosch123> GSWindow doc says so
20:03:39  <Alberth> Zuu to handle "3/8" for AIs, also have a percentage parameter?
20:03:48  <frosch123> +		SLE_VAR(Goal, progress, SLE_UINT8), <- if you add a new item to a saveload struct you have to specify a savegame version when it was added
20:03:54  <frosch123> and bump the savegame version
20:04:20  <frosch123> Alberth: isn't "completed" enough?
20:05:05  <Alberth> (09:10:06 PM) Zuu: Your point to allow "3/8" strings for progress made more sense than the AI benefits for a numerical progress as making the goal system to be undestandable by AIs is quite hard anyways.  <-- my remark was about this point
20:05:57  <Zuu> Alberth: You also need to tell AIs what the goal is about. Unless the AI know what to do to accomplish a goal, it will not have any help of a progress counter.
20:06:59  <Alberth> ooh, right. I read it wrong. Sorry
20:07:35  <frosch123> DrawString(x, right, y + pos * FONT_HEIGHT_NORMAL, s->completed ? STR_GOALS_PROGRESS_COMPLETE : STR_GOALS_PROGRESS, TC_FROMSTRING, rtl ? SA_LEFT : SA_RIGHT) <- use SA_RIGHT | SA_FORCE
20:07:42  <Zuu> Regarding script_window.hpp I might have done those changes manually or using the script. However, it is probably 1-2 months since I wrote the patch so the white space mismatch may be due to that.
20:09:19  <Zuu> <frosch123> + * \li GSWindow::WID_GL_GOAL <- we do not add those to the changelog   <---- so also remove the note in the changelog about removals?
20:09:28  <frosch123> yes
20:09:59  <frosch123> they are completely version specific, we would already have 50 boring entries for 1.3 otherwise :)
20:10:09  <frosch123> (all the settings windows)
20:10:55  <frosch123> +		g->progress = 0; <- s/0/NULL/
20:12:03  <frosch123> +	if (StrEmpty(text)) return CMD_ERROR; <- CmdSetGoalProgress seems to disallow empty strings, but the api says different
20:12:50  <frosch123> oh, CmdSetGoalText actually sets the progress, not the text
20:13:29  <Zuu> Regarding SLE_VAR, should the version comment be at that line or somewhere else?
20:14:10  <frosch123> no comment, you need SLE_CONDVAR
20:14:24  <frosch123> you have to code that the var is not present in old savegames
20:14:30  <frosch123> else ottd will reject the save as broken
20:16:31  <frosch123> you are not saving "completed", are you?
20:16:52  <frosch123> if it shall be saved, you have to use uint8 instead of bool
20:17:01  <frosch123> bool cannot be saved in an endian-safe way
20:17:58  <frosch123> +typedef uint8 GoalProgress; ///< Percentage completed (0..100). <- i guess that is no longer used
20:20:43  <frosch123> the other places which use Text in the api seem to have a CCountedPtr<Text> thingie at the begin of the function
20:24:28  *** andythenorth has joined
20:24:28  *** ChanServ sets mode: +v andythenorth
20:24:29  <Zuu> * @pre goal != NULL && len(goal) != 0.  <--- this is how the API specify that goal text cannot be empty for GSGoal::Create. I've used the same in the API doc for SetGoalText
20:24:53  <Zuu> <frosch123> no comment, you need SLE_CONDVAR <--- fixed
20:25:40  <Zuu> Hmm completed should be saved
20:25:46  <Zuu> That needs fixing
20:26:12  <Zuu> <frosch123> oh, CmdSetGoalText actually sets the progress, not the text <--- good spot => now fixed
20:26:54  <frosch123> +	return g != NULL && g->completed; <- GOAL::Get will never return NULL, it will assert instead :)
20:27:45  <frosch123> you seem to have the same work disease as me with all those & and * at the left side :)
20:28:08  <frosch123> [21:25] <Zuu> * @pre goal != NULL && len(goal) != 0.  <--- this is how the API specify that goal text cannot be empty for GSGoal::Create. I've used the same in the API doc for SetGoalText <- it is also c&p to SetCompleted, which has no text
20:28:49  <Zuu> Yep, I fixed the SetCompleted c&p error
20:28:55  <frosch123> also ScriptCompanyMode is mentioned in the docs for Set/IsCompelted, but not in the code
20:29:47  <Zuu> But it was a comment to your comment that the Cmd rejects empty strings but that the API docs does't suggest that. My point was that the API does specify that empty strings are rejected using the same way of saying it as GSGoal::Create
20:30:39  <frosch123> "To clear the progress string you can pass NULL or an empty string." <- how do you mean?
20:31:36  <Zuu> If you have previously set a progress text and want to clear it away.
20:31:52  <frosch123> yes, but the command rejects it, that's what i meant :)
20:33:50  <Zuu> Ah.. I changed the command now to accept empty strings and NULL the progress variable (after free) if the string is empty instead of rejecting it.
20:34:49  <frosch123> just say when you have  a new diff :)
20:36:37  <Zuu> Regarding ScriptCompanyMode, that is enforced using:
20:36:38  <Zuu> EnforcePrecondition(false, ScriptObject::GetCompany() == OWNER_DEITY);
20:36:45  <Zuu> But yes, this is getting out of hand. :-)
20:39:56  <Zuu> <frosch123> if it shall be saved, you have to use uint8 instead of bool
20:39:56  <Zuu> <frosch123> bool cannot be saved in an endian-safe way  <--- do I need to make bool/int conversion manually in Load_GOAL/Save_GOAL or does it magically work?
20:40:17  <frosch123> you have to declare the var as uint8
20:40:20  <frosch123> in the struct
20:40:50  <frosch123> ottd accesses it just via its pointer, so it expects the "bool value" to be stored in the first byte
20:40:55  <frosch123> which is not the case on big endian
20:46:38  <Zuu> I've declared it as a SLE_UINT8 now
20:53:41  <Zuu> Updated patch:  (same URL as before)
20:57:37  <Zuu> Hmm, saving with the current patch cause an assert to be triggered :-)
20:59:15  <frosch123> + * Update progress text of a goal. <- c&p on CmdSetGoalCompleted
20:59:42  <frosch123> +	bool completed;        ///< Is the goal completed or not? <- it has to be uint8
20:59:52  <frosch123> the size of bool is compiler specific
21:01:28  <frosch123> actually the indenting policy in _sl files is to use one tab at the front, and then spaces to align the (
21:01:37  <frosch123> very uncommon in ottd, but very common in saveload :)
21:01:39  <Alberth> I wonder whether the goal progress should be updated when the completed flag is set
21:01:54  <frosch123> the colour chanes
21:02:36  <Alberth> progress: 25%    in 'completed' colour :p
21:02:46  <frosch123> +		SLE_CONDVAR(Goal, progress,  SLE_UINT8, 180, SL_MAX_VERSION), <- Zuu: that's where it crashes
21:02:52  <frosch123> a string is no uint8 :)
21:03:08  <frosch123> Alberth: why not? if the goal is to transport 25% of stuff
21:03:14  <Zuu> A future patch could introduce a symbol that is drawn somewhere with a checkmark or something to give more visual feedback than simply changing the colour of the text.
21:03:22  <Alberth> the empty string is uint8 :p
21:04:02  <Zuu> <frosch123> a string is no uint8 :) <--- right, that I should have got right from the beginning :-)
21:05:05  <Zuu> <frosch123> + bool completed;        ///< Is the goal completed or not? <- it has to be uint8   <----- so also the in-memory structure need to have fixed size on all platforms?
21:05:17  <frosch123> yes
21:05:31  <frosch123> the saveload code accesses it as uint8 via a reinterpret cast
21:05:47  <Alberth> otherwise you break automagic getting/setting of the value
21:06:09  <frosch123> Zuu: please check the usage of "CCountedPtr<Text> counter(goal);" in the api functions which take a text parameter
21:06:18  <frosch123> i suppose it is for freeing the text upon return
21:07:09  <Alberth> struct Goal : GoalPool::PoolItem<&_goal_pool> { <-- why does the ///< comments shift in that struct, there does not seem to be a need
21:08:10  <Zuu> When we use uint8 as a bool variable, do we use any special structure for setting/getting it? Or just use 1 for true and 0 for false?
21:08:38  <frosch123> i think just 0 and 1
21:10:08  <Zuu> In the Cmd, should I then verify that the parameter is exactly 0 or 1 and not eg 2 or 3?
21:10:11  <frosch123> Zuu: oh wait, i learned something new, apparently we have SLE_BOOL nowadays
21:10:23  <frosch123> replace_protection uses that :)
21:11:47  <Zuu> hmm, It looks like users of SLE_BOOL use bool as in-memory variable type.
21:12:13  <frosch123> yes, i guess that's what it is about :)
21:12:28  <frosch123> it was all wrong what i said earlier about using uint8 :p
21:13:02  *** Alberth has left
21:13:13  <frosch123> diff has still several "*" in the wrong spot
21:13:40  <Zuu> Ok, I'll look through that.
21:24:36  <Zuu> Hmm "[a-zA-Z0-9]\*" only gave one hit
21:30:08  <frosch123> hmm, yeah, looks like i exagerated :o
21:31:10  <Zuu> I've updated the patch regarding SLE_BOOL and that "*". However the game still crashes upon save.
21:31:55  <Zuu> Also fixed the tab indention of SLE_* stuff. Or at least I've made it now so that things should align up well even if someone got tab-width 8 or 3 or whatever :-)
21:33:53  <frosch123> just check how the other saveload code does it .)
21:34:48  <frosch123> did you check the CCountedPtr thingie?
21:35:29  <Zuu> Right, I got one tab too much. :-)
21:35:46  <Zuu> Nope, the CCountedPtr haven't been checked yet.
21:40:14  <Zuu> It does indeed look like all APIs use it for string parameters. So I guess my patch should use it. Although it would be even better to understand why. :-)
21:40:51  <frosch123> i suspect it does a free of the text no matter how the command returns
21:40:57  <frosch123> (normal or via exception)
21:50:12  <Zuu> I've now figured out why it keep asserting at save. So a fixed patch have been uploaded.
21:50:31  <Zuu> I was using SLE_(COND)VAR instead of SLE_(COND)STR.
21:50:43  <Zuu> for strings
21:54:57  *** andythenorth has quit IRC
21:59:11  *** welshdragon has joined
22:10:23  *** andythenorth has joined
22:10:23  *** ChanServ sets mode: +v andythenorth
22:21:09  *** frosch123 has quit IRC
23:13:44  *** andythenorth has quit IRC
23:36:02  *** FLHerne has quit IRC

Powered by YARRSTE version: svn-trunk