IRC channel logs
2020-02-28.log
back to list of logs
<fossy>2. can M2-Planet's continue behaviour match GCC's please <fossy>(if that's not possible I'll modify the code to work around that) <OriansJ`>fossy: first The change in functions/numerate_number.c; the correct behavior would have been to return a NULL as numerate_number failures should not terminate the parent program <OriansJ`>in functions/string.c: The correct behavior in postpend_char is to return NULL not terminate the program; as is true for prepend_char and prepend_string <OriansJ`>fossy: as the calling function is supposed to check for NULL returns (Require makes this a single line) <OriansJ`>But I will attempt to get continue to behave correctly today <dddddd>fossy, which branch of your repo is that pull request for? I'm looking at 'cd' at 5e769ae3c491 <dddddd>ef09d3ed558c (in makefile) has conflict marks <dddddd>That 031d076f87a5 refactor-and-move-the-file commit, everything in one go without even explaining what kind of refactors are done is kind of obscure. <dddddd>Also, lacks your copyright statement at the begin of the file. <dddddd>Oh, so... M2-Planet doesn't short-circuit 'or'!? I'd consider that a bug (in line with the 'continue' behaviour), maybe. <dddddd>If "not short-circuit" is what you call lack of "optomizaitons" (notice the typo also)... I don't think that's an optimization, but expected behaviour (again, maybe... we know that M2-Planet does not compile C, but that's a very common behaviour). <dddddd>In fact, I was wondering about or/and in M2-Planet since the mes-m2 questions, because I didn't remember code in M2-Planet handling the short-circuit. I guess my feeling was right. <dddddd>(Again, please note that I don't use github but a mirror, and pull-requests doesn't get mirrored... so maybe I'm looking at the wrong commits). <dddddd>OriansJ`, if shot-circuit of boolean expressions won't be considered bug (fair, because maybe it's not a small change), I'd put it on the "M2-Planet v2 worth" list. <dddddd>fossy, 167df40bd1a4 adds a [debug?] print in set() which I think you don't want there: file_print("hi\n", stdout); <dddddd>... same commit, the error message for "cd" talks about "set". <dddddd>fossy, I like how you're adding clarifications in comments. Great!! Keep it up. <dddddd>In any case, that wasn't an exhaustive review (of maybe not the right thing to look at, even). <dddddd>OriansJ`, in M1.scm I saw several redundant 'begin' uses. I'm removing them (on the base they're not required in guile 2). But I'm wondering if you used them for compatibility with another interpreter and I should recover them... Do we want redundant 'begin'? <fossy>dddddd, OriansJ`: thanks for the comments <fossy>dddddd: how would you suggest I approach the commit? Add an extended description? <fossy>since I essentially made radical changes and then rewrote each function, I couldnt test the code until I had done everything <fossy>so I decided to do one big commit <fossy>dddddd: yes, it does not short circuit OR <fossy>dddddd: yes the cd branch is correct <fossy>(Thats just where id been developing its a poor name, I will change it) <fossy>OriansJ`: thanks for the comments, you are correct for all of those <dddddd>I guess the extended description is the only option if you don't want to refactor incrementally (a bit harder but possible, usually). I don't know the changes involved (back to square one of documenting them) so it's your call how to approach it at the end of the day. <fossy>I dont really want to redo everything to be honest, haha <fossy>documenting them shouldn't be hard because its still reasonably fresh in my brain <fossy>and I did make an effort to put lots of comments in <dddddd>Knowing what motivated the changes (not only which they are) also helps. What flaws you wanted to remove, etc... <fossy>dddddd: RE: the copyright header, which file was that? <fossy>do you think a copyright statement under my name is warranted? <fossy>to be honest I did write most of it <fossy>but there's still quite a bit of oriansjs code in there <fossy>And idk what the gpl says about this etc <dddddd>... but any file you touch (modulo maybe some minor and trivial changes, but even for that it's the correct thing to do) is expected to have you listed as author. <dddddd>You, of course, keep the other authors. <fossy>Hm, thats very interesting, I was not aware of that... <fossy>how do large projects keep track or that?? <dddddd>So, if there's quite a bit of Orians code and your code... both copyright notices. <dddddd>Sorry, what do you mean by tracking? <fossy>like, would large projects have massive copyright headers with hundreds of lines of contributors? <lfam_>fossy: Yes, each contributor will be listed in the copyright header unless they explicity assign their rights to another entity <dddddd>I see, good question. I guess sometimes they're listed in detail in some file covering concrete directories (by subsystem or the like) but I guess there're some large-ish list in some files. <fossy>I guess I need to go fix up one of my slightly larger projects :S <dddddd>In fact, it's not a GPL specific issue. GPL sits on top of copyright. It's the copyright what need to be clear in the first place. <fossy>this is probably offtopic now, but I wonder is "Project maintainers and contributors" acceptable? <fossy>or should individuals be named? <dddddd>On the file level, I'd say individuals. <dddddd>Unless reassignation of copyright to an entity, as said before. <dddddd>... one could even argue that this is not fine-grained enough, but with correct SCM management one can know which exact parts are of whom if the need arises. <dddddd>s/management/handling/ (to avoid silly repetition) hehe