Summary
- Don't merge norefs until regressions are fixed and scripts are converted
- Array slicing should copy in all cases
- No conclusion on how to proceed wrt to the game/release title
- License is not totally clear
- Followup in the forums
Full Log
17:50:10<!Newton> what about a meeting today?
17:51:07<!Newton> since nobody posted anything he wants to talk about, I guess the meeting for this week will be omitted?
17:51:24<!Isilkor> I don't have anything I want to talk about
17:52:43<!Randrian> have we made saturday the new meeting day?
17:52:51<!ck> I want to talk about how to proceed wrt release
17:56:43<!PeterW> I want to talk about making norefs official
17:59:05<!Newton> mh okay, go on then. its 18:00 ^^
17:59:33-Newton:#openclonk-dev- ad-hoc meeting in #openclonk-dev!
17:59:55<!Newton> Randrian: well the doodle didn't change so much, Saturday is still the best day
18:00:37<!PeterW> Well, on the other hand, I might be gone soon... ;)
18:00:59<!Guenther> monday and tuesday have the most green, saturday the least red
18:01:01<!Newton> you could also post it in the forum
18:01:10<!PeterW> Well, it's not much
18:01:15<!Newton> because i guess not so many people can even say anything about that@norefs
18:01:32<!PeterW> norefs just needs a bit of "anybody with a good reason not to do it?"
18:01:42<!Newton> but OK, from the engine coders, everyone except S2 is here
18:01:51<!Randrian> what is norefs?
18:01:53<!PeterW> Saving is still an issue
18:02:01<!PeterW> The complete removal of references from C4Script
18:02:08<!Guenther> Sven2 has already said he's in favor, iirc
18:02:37<!PeterW> For scripters this means that reference parameters and return references won't work anymore
18:02:39<!Newton> what would it mean for the scripter btw, whcih changes does it have?
18:03:01<!PeterW> So no "Local(2) = 3" anymore, for example
18:03:02<!Newton> I didnt even know there was such a thing as return references
18:03:04<!Randrian> well functions like SimFlight() which have references as parameters have to be changed.
18:03:19<!Guenther> The necessary changes to the scripts in planet/ are all of the return-arrays-instead nature
18:03:20<!PeterW> I already did that - they should return a result array now
18:03:38<!PeterW> (Needs testing, though.)
18:04:08<!ck> I guess the best testing you can get is to merge it ;)
18:04:14<!PeterW> The only exception is EffectVar - "EffectVar(...) = bla" still works because the engine automatically rewrites it to "SetEffectVar(..., bla)"
18:04:30<!PeterW> (which is a new engine function I introduced for this)
18:04:39<!Guenther> Also, arrays have reference semantics now - var a = [1,2,3], b = a; b[0]=2; modifies a now, too
18:04:45<!Newton> object DoSomeEffect(x,y) { CreateParticle(...,x,y) return this; }
18:04:58<!Newton> var someObject;
18:05:23<!Newton> someObject->DoSomeEffect()->DoSomeEffect()->DoSomeEffect(); would still work?
18:05:41<!PeterW> Yep, that's important to note because it might silently break some scripts @ array reference semantics
18:06:10<!PeterW> Yes
18:06:25<!Newton> good
18:06:31<!PeterW> Object references, Proplist references and all the likes still work - just not value references
18:06:31<!Newton> how can an array be copied then?
18:07:01<!Randrian> is this array reference thing really good? Looks like a good potential for silent bugs that are hard to find.
18:07:03<!Guenther> With array slicing!
18:07:08<!PeterW> var copy = CreateArray(GetLength(first)); for(var i = 0; i < GetLength(first); i++) ...
18:07:09<!PeterW> ;)
18:07:26<!PeterW> Array slicing currently doesn't work this way
18:07:36<!PeterW> a[:] returns a
18:07:48<!PeterW> We should probably change that
18:08:17<!PeterW> Well, depends on your viewpoint @ potential for bugs
18:08:29<!Guenther> Definitely. That was probably just an optimization relying on the copy semantics.
18:08:31<!PeterW> Proplists and objects already work this way... :)
18:08:57<!Randrian> well, for objects you expect it.
18:09:21<!PeterW> So maybe it's not that hard to expect it for arrays as well?
18:09:35<!PeterW> It's a weak reasoning - but we can't really tell without some testing
18:09:36<!Newton> what about: array doArrayStuff(array blub) { for(var i=0; i<GetLength(blub); ++i) blub[i]++ return array; }
18:09:46<!ck> So maybe it's not that hard to expect it for integers as well? :P
18:10:01<!Guenther> PeterW: Yes, but let's be honest - copy semantics being easier for scripters was one of the reasons we decided to use them
18:10:04<!PeterW> Well, you can't really change integers
18:10:09<!Newton> array bla; array blub = doArrayStuff(bla);
18:10:12<!Newton> bla == blub?
18:10:31<!PeterW> Well, yes, I still think they are easier
18:11:02<!PeterW> But as the sole reason I don't think it would have supported keeping references
18:11:20<!Guenther> Somebody should probably review some scripts to check what the typical usage is
18:11:48<!PeterW> bla and blub would be the same @ Newton
18:11:55<!ck> I think consistency is key here... arrays should work the same way as proplists
18:12:48<!PeterW> The correct implementation would add an "blub = blub[:]" there @ Newton
18:13:03<!Randrian> what does [:] mean?
18:13:08<!Guenther> ck: At the moment, they kind of behave like strings...
18:13:09<!PeterW> Or call doArrayStoff with "bla[:]"
18:13:14<!PeterW> That's a slice
18:13:34<!Guenther> bla[:] == bla[0:GetLength(bla)]
18:13:35<!PeterW> bla[1:2] is array elements 1 to 2
18:13:43<!PeterW> 2 exclusive.
18:13:45<!Randrian> ah ok. Like in python.
18:14:08<!Guenther> yep. It should work exactly like in python, if it doesn't, file a bug
18:14:23<!PeterW> so [0,1,2,3,4][2:4] -> [2,3]
18:15:21<!Guenther> Coincidentally, arrays with reference semantics is also what Python does.
18:16:01<!PeterW> Should be no surprise. All languages that treat values as objects are bound to do it that way.
18:16:43<!PeterW> That's my cheap argument: Ruby and Python do it that way, it /must/ be right ;)
18:17:00<!Guenther> Actually, does anybody know a language which doesn't?
18:17:09<!PeterW> Perl? :)
18:17:32<!ck> Guenther: STL containers, if that counts as "language" :)
18:17:35<!Guenther> (Apart from those languages which have immutable arrays/lists, of course)
18:18:16<!PeterW> Well, yes, perl. I have no idea whether they implement CoW internally, though.
18:18:17<!Guenther> puh, I only remember arrays in perl being somewhat confusing
18:18:44<!Guenther> But I think that was a syntax problem
18:19:41<!Guenther> I'd bet Python and Ruby do it this way because it's easier to implement
18:19:45<!PeterW> Well, if you want a reference to an array, you'd do something like my $ref = \@array, and access it using $ref->[idx], if that's what you mean ;)
18:20:10<!PeterW> (Currently doing work for one of the founders of the perl monks KL, it shows ;( )
18:20:39<!Newton> shit@l
18:20:41<!Newton> bla an
18:20:44<!Newton> d blub the same
18:21:09<!PeterW> Well, yeah
18:21:16<!Isilkor> Newton: depends on what doArrayStuff does, though
18:21:36<!Newton> increase every element by one
18:21:40<!PeterW> But you really don't want to know what kind of housekeeping is required for the engine to realize at "blub[i]++" that it needs to duplicate the array.
18:21:46<!Newton> and then return the modified array
18:22:02<!Isilkor> Newton: it should make a clone of that array then
18:22:14<!PeterW> And I don't know whether a scripter really knows that "blub[i]" might end up duplicating the whole array
18:22:37<!Newton> well this must be documented very clearly in the docs
18:22:46<!PeterW> I mean, worst case - we have a huge array, some spurious reference somewhere, and you end up building a very slow program because you don't realize it
18:23:04<!Guenther> I _think_ we managed to get the duplication down to a unsurprising amount
18:23:34<!Guenther> because once you have done the copy, you don't need to create another one
18:23:41<!Newton> if its documented properly in the reference, I am OK with merging noref into default
18:24:01<!PeterW> Well, yes, but it was quite a bit of work, wasn't it?
18:24:11<!PeterW> And we had quite a number of bugs on the way.
18:24:24<!PeterW> I don't know, I don't trust complicated implementations :)
18:24:49<!Guenther> except if you store the array in lots of variables, and I think it's reasonable to assume that doing var a = CreateArray(100), b = a; for (var i = 0; i < GetLength(a); ++i) a[i] = b; can lead to lots of copies later
18:25:04<!PeterW> In my opinion, it just means that the user won't be able to tell what he's actually doing with it.
18:25:08-!- Prior is now known as Prior-OFF
18:25:57<!Guenther> well, I somewhat trust our current implementation - we thought about it a lot and I'm satisfied that our reasoning is correct
18:26:13<!Guenther> on the other hand, we just saw to what kind of bugs the references lead
18:26:38<!Guenther> was it the bow-doesn't-work bug?
18:27:11-!- Luchs is now known as Luchs^away
18:27:14<!Newton> hm?
18:27:15<!Guenther> http://hg.openclonk.org/openclonk/rev/f9a02581e861
18:27:30-!- Prior-OFF [~Miranda@euirc-8c3a9589.dip0.t-ipconnect.de] has quit [Connection reset by peer]
18:27:47<!Guenther> That change is all about me having forgotten about the pitfalls of C4Value references
18:30:18<!Guenther> So getting rid of references is not so much about the complicated array reference counting, but about making future changes to the engine easier
18:31:33<!PeterW> Well, there's also the argument about lesser memory consumption and potentially performance... ;)
18:31:54<!Guenther> Did anybody messure this yet?
18:32:48<!PeterW> Well, it's not like anybody has been complaining recently...
18:33:03<!ck> can we agree on something here? Peter to merge norefs? Peter to merge norefs after [:] creates a copy?
18:33:42<!PeterW> Hm, if I should merge I have another sub-issue:
18:33:50<!PeterW> Should I merge by script fixes?
18:34:04<!Guenther> er, what?
18:34:16<!PeterW> These where very ad-hoc and even incorrect, as Mortimer has already shown
18:34:59<!PeterW> I just wanted to see quickly whether I'm able to get the engine running. Maybe some scripters feel like they want to decide for themselves how their code should be refactored.
18:35:05<!ck> well, if you don't then don't we end up with something unplayable?
18:35:14<!PeterW> I remember doing quite a lot of changes in Maikels code
18:35:44<!PeterW> Well, this will break quite a lot no matter how we do it
18:35:59<!ck> why?
18:36:02<!ck> I'd prefer to not break the default branch
18:36:08-!- Mimmo_O [~mimmoisgr@euirc-93219395.dip0.t-ipconnect.de] has joined #openclonk-dev
18:36:12-!- mode/#openclonk-dev [+ao Mimmo_O Mimmo_O] by ChanServ
18:36:27<!PeterW> Well, because most "FindRelaunchPos"-type scripts currently use reference parameters
18:37:53<!ck> I'd suggest to fix all affected scripts before merging
18:38:12<!PeterW> http://hg.openclonk.org/openclonk/rev/427442d5de82
18:38:29<!PeterW> And that only fixes about a quarter of the issue
18:39:34<!PeterW> Well, okay, then the branch is definetely not ready for merge yet.
18:40:19<!ck> okay
18:40:44<!Newton> + docs?
18:41:09<!PeterW> Yeah, docs should have quite a bit about the old references
18:41:30<!PeterW> At least if nobody has deleted what I wrote back then about type checks
18:42:18<!PeterW> Well, okay, I might look into it shortly.
18:42:52<!PeterW> ... at least I know that it won't just be reverted now :P
18:43:04<!PeterW> Okay, gotta go, have fun.
18:43:10-!- PeterW [~peter@euirc-a15152fb.superkabel.de] has quit [Quit: Leaving]
18:45:10<!ck> okap so concerning the title stuff I think we have two options: Either make a logo reading "BackToClonk" with BackTo and Clonk ~the same size
18:45:24<!ck> or abandoning the subtitle as suggested by Clonkonaut and keep with OpenClonk
18:46:52<!Newton> it will be tiresome to make a different logo for each release
18:47:00<!Newton> what about zappers suggestion?
18:47:09<!Newton> keep OpenClonk and add subtitles
18:48:54<!Guenther> Yeah, we should probably admit defeat and recognize that we won't find a better name than OpenClonk
18:49:19-!- ala [~bla.bla@euirc-bcd09bc8.pools.arcor-ip.net] has joined #openclonk-dev
18:49:37<!Sven2> We still have to call it "An OpenClonk project"?
18:49:56<!Newton> I guess not
18:49:59<!ck> yeah, so if we are going to add another subtitle it might be too many titles
18:50:10<!Newton> only if we use Clonk in the title, no?@an openclonk project
18:50:28<!Sven2> Yes. Which we would do if we call it OpenClonk
18:50:36<!Newton> hm
18:50:39<!ck> oh, but we do want to keep Clonk in the title I hope
18:51:04<!Sven2> Actually, I would rather drop Clonk from the title (still keeping the OpenClonk subtitle) than have a doubled "OpenClonk"
18:51:29<!Guenther> We might have a better chance at finding a really good name if we drop the Clonk
18:51:45<!Newton> I don't think that matthes would insist that we call it OpenClonk - an OpenClonk project if we were to use that name
18:52:25<!Sven2> He wrote so in the licence :P
18:52:26<!Guenther> It's probably bad marketing strategy to use a different domain name than the title of the game
18:52:28<!Newton> ack@drop clonk
18:52:45<!Newton> I mean, ack@think about a title which doesnt HAVE to contain clonk
18:53:52<!Sven2> WEll, designing a complete new title without the Clonk logo is not any easier than designing a title with the Clonk logo in the same size
18:54:33<!Guenther> With a complete new title, we would get rid of the openclonk.org versus FooClonk distinction
18:55:34<!Guenther> By the way, clonk.org is strange.
18:55:46<!Sven2> "Back to the Rocks" ;)
18:56:01<!Sven2> Though it's more like "Back to the Rocket Launchers" with all the boompacks right now
18:59:16<!Sven2> Newton:
18:59:16<!Sven2> Open Clonk
18:59:16<!Sven2> (in small font below OC: title [of the current release])
18:59:31<!Sven2> "Open Clonk" is not OK; must not use the name "Clonk" as as a separate word?
18:59:51<!ck> yeah, that's exactly what Newton explains one line above ;)
19:00:55<!Isilkor> Sven2: I don't think the license specifically states that it needs to be one word with camel casing
19:01:03<!ck> Are we allowed to do something like OpenClonk [Something]?
19:01:39<!Guenther> We must "prefix the word with an added name of your choosing" and "you must subtitle your project with the term 'An OpenClonk project'"
19:02:03<!Guenther> whatever "prefix" means exactly is not very clear
19:02:22<!Guenther> though the examples do point in a certain direction
19:02:44<!ck> (such as OpenClonk Rage - An OpenClonk project ;) )
19:03:15<!Isilkor> ck: While that may be legally acceptable, I'm quite sure it'll rub matthes the wrong way ;)
19:04:07<!Guenther> Hm. "subtitle your _project_"
19:04:09<!ck> It does not sound that good anyway
19:04:14<!Guenther> What's our project?
19:04:46<!Guenther> It's certainly not the software product that has a title containing Clonk...
19:04:56<!ck> Guenther: why not?
19:05:11<+occ> Lykanthrop * b4d4bdbbf21e planet/Objects.c4d/Items.c4d/Tools.c4d/JarOfWinds.c4d/Script.c: Jar of Winds autorelaod
19:05:28<!Guenther> Okay, it might be, but it must not - "project" just pops out of nowhere in the licence
19:06:23<!Guenther> except that Clonk may be used within software products "using source code from the OpenClonk project"
19:06:40<!Guenther> which is clearly separate from the "your project"
19:07:00<!Guenther> Probably the second project was intended to be a "product"
19:07:17<!ck> I'm not sure I get the point :)
19:07:24-!- Mortimer [~chatzilla@euirc-807d1a09.dip.t-dialin.net] has quit [Client exited]
19:07:48<!Guenther> The point is that the license was not very carefully written, and is subject to a lot of interpretation
19:08:14<!Guenther> We might want to spare us that interpretation risk
19:08:44<!ck> by not using Clonk in the title?
19:08:48<!Guenther> I'm not particularly a fan of "FooClonk - An OpenClonk project" anyway
19:09:55<!Guenther> heh, dict.leo.org hasn't even a translation of "to subtitle"
19:10:25<!ck> Is the "An OpenClonk project" subtitle only necessary if we use Clonk in the title or also if we use the Clonk Rage source code?
19:11:00<!Guenther> Well, just read the license yourself
19:11:18<!Guenther> As I mentioned, it isn't even clear _what_ we have to subtitle
19:11:56<!Guenther> We could interpret it to mean that we have to put that subtitle on our website, but not on our software product
19:12:02<!ck> I guess the subtitle should appear everywhere where the "normal" title appears as well.
19:12:24<!Guenther> That's one interpretation, and _probably_ the intention
19:12:57<!ck> Of course we can also simply ask for clarification :)
