| *** kylel1 is now known as kylel | 07:10 | |
| lkcl | programmerjake, i added whitespace-recognition to the page-reader for pseudocode so that comments with indentation are correctly ignored | 10:53 |
|---|---|---|
| programmerjake | lkcl: i'm going to sleep now, feel free to revert once you got the fix to work, the commit you pushed didn't fix it. | 11:15 |
| lkcl | programmerjake, ok willdo | 11:19 |
| programmerjake | :) | 11:20 |
| lkcl | didn't realise comment-checking was in so many places. am slightly on autopilot | 11:26 |
| ghostmansd[m] | Hi folks, JFYI, from now on, I'll use my private email, so I've subscribed to our archive from it | 11:40 |
| ghostmansd[m] | I've also sent my public key, but this message is pending, because I'm not member yet. Perhaps idiotic Gmail's dot in email might confuse the mailing archive. | 11:41 |
| ghostmansd[m] | My address I use and post is ghostmansd in Gmail, but when I initially created it, it was ghostman.sd. These are the same, Gmail doesn't care about dots. | 11:43 |
| lkcl | ghostmansd[m], will take a look | 11:46 |
| lkcl | mailing lists care :) | 11:47 |
| lkcl | i've added that address as "approved to post" so you should be fine now | 11:48 |
| ghostmansd[m] | Hm, somehow I didn't receive this message on local email, only on 3mdeb... | 12:04 |
| ghostmansd[m] | Ah, got it, I need to confirm | 12:05 |
| ghostmansd[m] | lkcl, could you, please, add the public key to git and talos1? | 12:53 |
| lkcl | yep 1 sec.. | 14:14 |
| lkcl | ghostmansd, sorted | 14:17 |
| ghostmansd[m] | lkcl, star | 14:19 |
| ghostmansd[m] | Ok looks like git works with new pubkey | 17:47 |
| ghostmansd[m] | lkcl, I've just checked sv_binutils.py, it works after your changes :-) | 17:50 |
| ghostmansd[m] | I see a strange commit claiming to clean whitespaces up, though | 17:50 |
| lkcl | deep joy | 17:50 |
| lkcl | ah yes. 80 char limit | 17:50 |
| ghostmansd[m] | But, instead of cleaning those... | 17:50 |
| ghostmansd[m] | It adds few in the end of the line | 17:50 |
| ghostmansd[m] | I'm kinda confused | 17:51 |
| ghostmansd[m] | at least terminal highlights this | 17:51 |
| lkcl | yes that'll be my mistake | 17:51 |
| ghostmansd[m] | BTW, as for line break limit | 17:51 |
| ghostmansd[m] | Perhaps we could establish some sort of git hook? | 17:51 |
| lkcl | unfortunately in some cases (URLs in comments) it's actually necessary | 17:52 |
| ghostmansd[m] | Ah, OK, fair enough | 17:52 |
| lkcl | stackexchange for example | 17:52 |
| lkcl | i'll do the whitespace now | 17:53 |
| lkcl | sorted | 17:53 |
| ghostmansd[m] | Heck | 17:59 |
| ghostmansd[m] | Missed your message | 17:59 |
| ghostmansd[m] | I did the same thing, but a bit more... | 17:59 |
| lkcl | doh :) | 18:00 |
| ghostmansd[m] | Ok, done | 18:00 |
| lkcl | looks good | 18:01 |
| lkcl | i'm kinda of the generally-vague opinion that if it looks clean / tidy it's easier to understand | 18:02 |
| ghostmansd[m] | Same :-) | 18:02 |
| lkcl | but it may just be the fact of making changes that causes "learning" | 18:02 |
| lkcl | hey if it works | 18:02 |
| ghostmansd[m] | I prefer spacing twice on function declarations, though | 18:02 |
| ghostmansd[m] | And always indent by fixed amount, never giving a crap about padding to method name | 18:02 |
| ghostmansd[m] | In my experience, function names and methods change names and arguments two often to consider them for a padding | 18:03 |
| lkcl | i do wish autopep8 wasn't borked when it comes to function arguments | 18:04 |
| ghostmansd[m] | But I've never given a f*ck to this on code reviewa | 18:04 |
| lkcl | f(x,y,z,a,b,c,d,e,f,g,h,i,j...) is correctly formatted by autopep8 | 18:05 |
| lkcl | as is f1(...) and f12(...) | 18:05 |
| lkcl | but the moment you go above 4-character indentation on the function-name-plus-bracket it goes to hell | 18:05 |
| lkcl | really weird bug | 18:05 |
| ghostmansd | lol | 18:06 |
| lkcl | you have to actually like... have a good reason | 18:06 |
| ghostmansd | actually PEP8 is not the strongest parts of Python | 18:06 |
| ghostmansd | many dubious choices, like "hey, two line breaks between functions, but not inside the class" | 18:06 |
| lkcl | and "the lead developer has to have about 10 xterms side-by-side due to memory recall problems" is a pretty big one | 18:06 |
| ghostmansd | I mean, why the heck these are different? | 18:06 |
| lkcl | as is "for developers with less resources i.e. low-resolution screens a large width is a problem" | 18:07 |
| lkcl | oh, yes. | 18:07 |
| ghostmansd | lkcl, I've updated the email on binutils commit, it was surprisingly easy... | 18:08 |
| lkcl | i rationalised that one as, "if it's top-level (no indentation) then 2 lines is good" | 18:08 |
| ghostmansd | and this will be the same email which I used to contact FSF earlier | 18:08 |
| lkcl | ahh brilliant | 18:08 |
| lkcl | yeah ~/.gitconfig or something? | 18:08 |
| ghostmansd | > [if it's top-level] Well, I'm actually interested how they treat when you have nested functions :-) | 18:09 |
| ghostmansd | ~/.gitconfig or something?git rebase -r <some commit before all of your bad commits> --exec "git commit --amend --no-edit --reset-author" | 18:09 |
| ghostmansd | Taken as is from stack overflow, can I call myself wise now, eh? | 18:09 |
| ghostmansd | actually kinda neat, I liked the overall idea | 18:10 |
| lkcl | yyeah i'd kiiinda prefer not to have a full commit-history rewrite? | 18:10 |
| lkcl | y'ken? | 18:10 |
| lkcl | because there are some places using git submodules and i'm not sure if the rewrite would cause merry havoc there | 18:10 |
| ghostmansd | it for sure can :-) | 18:10 |
| ghostmansd | depends on how badly you deal with it, though | 18:11 |
| ghostmansd | as any force rewrite | 18:11 |
| lkcl | like, "whoops that commit listed in the .gitmodules file no longer exists" | 18:11 |
| ghostmansd | true | 18:11 |
| ghostmansd | though, generally, this might be the problem with 3rd party modules | 18:11 |
| ghostmansd | actually I'm unsure of what to do with openpower-isa | 18:12 |
| ghostmansd | I'm thinking of leaving it as is, frankly | 18:12 |
| ghostmansd | because, whilst binutils are easy (nobody depends on them) | 18:12 |
| ghostmansd | openpower-isa is used by many people, and I don't want to break anyone's work | 18:12 |
| ghostmansd | also, binutils DO have linear history | 18:13 |
| ghostmansd | and sv_binutils.py in openpower-isa doesn't | 18:13 |
| lkcl | yeah it's pretty critical, it's the simulator, wiki overlay, and hardware, all depend on it | 18:13 |
| lkcl | have to be extremely careful | 18:13 |
| ghostmansd | what'd you recommend? at this stage, I'd like to keep any published stuff to be published w/o affairs to external companies | 18:14 |
| lkcl | pfhhh... ok go for it | 18:15 |
| ghostmansd | and, frankly, I'm not sure what to do here: if I publish binutils patch with a couple of files which are clearly auto-generated, then anyone can go and check the affiliation | 18:15 |
| lkcl | well copyright assignment there should take care of tha | 18:16 |
| lkcl | t | 18:16 |
| ghostmansd | you mean FSF copyright assignment, right? | 18:16 |
| lkcl | yehyeh | 18:16 |
| ghostmansd | but this doesn't concern openpower-isa repository... or does it? | 18:17 |
| ghostmansd | because, well, we have the generated files in binutils... | 18:17 |
| ghostmansd | but sv_binutils.py resides at openpower-isa | 18:17 |
| ghostmansd | frankly I'm noob in licensing, so I have no idea | 18:18 |
| lkcl | well as the output from a compiler (which is what sv_binutils.py is), copyright decisions can be made on the *output* from the compiler which have absolutely nothing to do with the copyright of the *tool*. | 18:18 |
| ghostmansd | yeah, and we intend to provide the output to binutils-gdb | 18:19 |
| ghostmansd | I mean, well, the compiler is also FOSS | 18:19 |
| lkcl | and that's where it gets interesting, going forward, because we *may* have to assign the copyright of openpower-isa to the *OpenPOWER* Foundation | 18:19 |
| lkcl | it is, after all, trademarked | 18:19 |
| ghostmansd | aha, this really gets interesting | 18:19 |
| lkcl | it'll be part of the submission of what we're doing to the OPF ISA WG | 18:20 |
| ghostmansd | so, yes, if we assign sv_binutils.py copyrights to FSF, this would really deal badly with OpenPOWER | 18:20 |
| ghostmansd | I mean, this would be a real conflict, right? | 18:20 |
| lkcl | ah not quite | 18:21 |
| lkcl | because part of the deal with the FSF is a "re-licensing back" | 18:21 |
| lkcl | but yes it's a... weird situation :) | 18:21 |
| ghostmansd | OK, I guess the current approach is OK: we grant the copyright to output | 18:22 |
| ghostmansd | That is, nothing but binutils-gdb files participate | 18:23 |
| ghostmansd | so, OK, there's only one reason to change the committer email now :-) | 18:23 |
| lkcl | lxo, wasn't there something about that in recent discussions? or was that for gcc? | 18:24 |
| ghostmansd | but for me even that one is sufficient, so I'm going to do it now | 18:24 |
| lkcl | yep go for it. | 18:24 |
| lkcl | we'll sort out any mess afterwards | 18:24 |
| ghostmansd | thank you! | 18:24 |
| * lkcl salutes :) | 18:24 | |
| lxo | one issue is copyright, the other is whether the generated files qualify as source code. is one expected to modify those generated files in the process of developing binutils, or would one rather use the input to the tool? in the latter case, the input is the source code, and its output is object code even if it looks like sources | 18:30 |
| lxo | (under the terms and understanding of the GPL) | 18:30 |
| lkcl | the generated files are definitely source code: they're sufficiently regular - and so large - that it would be quite insane to write them by hand | 18:32 |
| lxo | that's really not what matters. the relevant question (per convo with rms not long ago, on an unrelated issue) is which one you'd rather modify in the course of development | 18:34 |
| ghostmansd | Hm. In this particular case, the generator itself. | 18:35 |
| lkcl | you _could_ hand-edit the autogenerated file if you really wanted to | 18:36 |
| ghostmansd | I mean, I can do it either way... but the correct one is affecting the generator. | 18:36 |
| lxo | lkcl, it's not about what could be conceivably possible, it's about what one would rather do, which form would be most convenient to modify the program | 18:49 |
| lxo | say, if the generator were to be lost forever, one could then decide that the generated file, being sufficiently modifiable, is good enough to carry on the development. but otherwise, the generator's inputs (and possibly the generator itself, depending on details) would probably be it. | 18:50 |
| lkcl | yehyeh | 18:53 |
| lkcl | it's just that the inputs are strictly speaking - or have to become - the property of the OpenPOWER Foundation. | 18:53 |
| lxo | as for copyright assignments, if the generator is conceived of as a compiler, its inputs and the outputs are really just different forms of the same work. I don't think (but IANAL) one could assign copyrights over the latter but not the former | 18:54 |
| lkcl | being, as they would become, part of the OpenPOWER ISA Specification | 18:54 |
| lkcl | what might turn out to be the saving grace is that specifications themselves are not copyrightable | 18:56 |
| lkcl | (but the document *containing* the specification *can* be) | 18:56 |
| lxo | *nod*. it's tricky :-( | 19:00 |
| lxo | anyway, I have to go now. 'later | 19:00 |
| lkcl | ok :) | 19:01 |
| lkcl | thx | 19:01 |
| ghostmansd | OK, it seems like I finally came up with something that seems to work | 19:36 |
| ghostmansd | This URL https://pastebin.com/v4x7dF7v contains the script | 19:36 |
| ghostmansd | The overall idea is to create a new commit with author reset, then override the original one | 19:36 |
| ghostmansd | Folks, before I even consider pushing it with $(git push --force-with-lease) or even simple $(git push --force), I'd like to have as many eyes as possible on this. And, ideally, if we can, I'd like to have yet another backup of openpower-isa repository. | 19:38 |
| ghostmansd | lkcl ^ | 19:38 |
| tplaten | I'm trying to find out which type of DDR3 module the orangecrab has | 19:44 |
| tplaten | In ls2.py I find from gram.modules import MT41K256M16, MT41K64M16 | 19:45 |
| programmerjake | rewriting history will have bad effects such as reversions losing what commit was reverted because the sha1 changes, as well as the many links to specific commits from bugzilla, emails, the wiki, and more...is there any way you can add your old email as an alias of your new email in a .mailmap and have that be sufficient ghostmansd? | 19:45 |
| programmerjake | see https://github.com/llvm/llvm-project/blob/main/.mailmap for an example | 19:46 |
| tplaten | I had a look at coldboot.c, it copies the flash content to dram, which I currently do not have working on the orangecrab yet | 19:47 |
| ghostmansd[m] | programmerjake, I'm rather worrying about the whole affiliation with foreign company. | 19:51 |
| programmerjake | hmm...i'll let you decide but wanted to mention that there will be bad sideeffects of rewriting history, also it'll still be pretty easy to figure out your previous affiliation if one wanted to... | 19:53 |
| ghostmansd[m] | And, unfortunately, some of commits were done after these embargoes were applied, and after weapon was transferred to Ukraine. | 19:54 |
| ghostmansd[m] | I do not really bother about the fact that affiliation had placw. :-) | 19:55 |
| ghostmansd[m] | *place | 19:55 |
| ghostmansd[m] | I bother about the fact that any new submissions, including such big as binutils, might raise unneeded discussion and attract unneeded attention. | 19:55 |
| ghostmansd[m] | This is, I want these binutils works, and future ones, to be done by me outside of any companies. I simply do not want to take this risk. | 19:56 |
| ghostmansd[m] | Ergo, before submitting anything such public as binutils, I'd like to leave this controversy out of scope. | 19:57 |
| programmerjake | so imho if there are any legal problems, they won't change by rewriting history. | 19:57 |
| programmerjake | ok. would it work to have the previous history in a history tag or something so links to commits don't turn into 404s? | 19:58 |
| ghostmansd[m] | I think yes, why not. | 19:59 |
| ghostmansd[m] | On the other hand, I think we might leave openpower-isa out of it. | 19:59 |
| programmerjake | ok, in that case, go ahead and rewrite. maybe have the tag have a message stating it corresponds to commit xyz that is the rewritten version | 20:00 |
| ghostmansd[m] | Ok, let's wait for Luke | 20:01 |
| programmerjake | sounds good! | 20:01 |
| ghostmansd[m] | On the other hand, I think that the whole discussion depends on how FSF treats sv_binutils.py. | 20:06 |
| tplaten | I had a look at https://orangecrab-fpga.github.io/orangecrab-hardware/r0.2/OrangeCrab-r0.2-ibom.html | 20:09 |
| programmerjake | hmm...iirc gcc dropped the copyright assignment requirement...did binutils do that too? | 20:10 |
| ghostmansd[m] | As for the sources and code contributed to binutils, I clearly want this to be committed by me personally w/o any references to foreign company. I have no idea what laws will be here by the time I complete these works. Considering how the situation changes, I want to make things as simple as they can be. | 20:10 |
| tplaten | U4 is Micron Technology Inc.MT41K64M16TW-107:J TRMT41K64M16TW-107_J-TRBGA-96_9.0x13.0mm_Layout2x3x16_P0.8mm1 | 20:10 |
| programmerjake | tplaten: neat website, didn't know they added that feature to kicad | 20:11 |
| programmerjake | ghostmansd[m]: yeah, makes sense | 20:13 |
| lkcl | works for me | 20:15 |
| tplaten | I knew that Neo900 UG had developed some kicad addon, I don't know if it is still actively maintained. | 20:22 |
| tplaten | The software package is called eeshow. | 20:23 |
| tplaten | https://neo900.org/stuff/eeshow/ | 20:23 |
| tplaten | last commit is 5 years old | 20:25 |
| ghostmansd[m] | After giving it a thought, I think programmerjake is right. I'll simply create a .mailmap file, and that's it for openpower-isa. | 20:40 |
| programmerjake | i'll join the meeting in a few min... | 21:56 |
| lkcl | jn, lxo sadoon_albader[m markos meeting | 22:06 |
| ghostmansd[m] | https://sourceware.org/gdb/wiki/ContributionChecklist | 22:25 |
| ghostmansd[m] | A nice summary of contributing to binutils | 22:25 |
| *** psydroid is now known as psydroid[m] | 23:42 | |
| *** psydroid[m] is now known as psydroid | 23:43 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!