IRC logs for #openrisc Thursday, 2014-05-29

--- Log opened Thu May 29 00:00:10 2014
olofkblueCmd: Yes. Removing the interface stuff is a nice cleanup and I don't want to come across as an ungrateful bastard. My only issue right now is that more random code ends up in core.py05:56
stekernolofk: I think that moving the fusesoc cache into a global one (at least before you have a working caching mechanism) was a mistake07:54
stekern...because, even if what you wrote in your e-mail is a probable reason why it didn't work for him, I *had* used a stale cached version of mor1kx when I tested...08:23
stekernnow it turned out that it works with the latest version too08:23
stekernbut, even though I08:24
stekern*know* that only deleting the build dir isn't enough, I still do the mistake thinking it will08:24
blueCmdolofk: refactoring out that big if statement in the constructor of to a function is a good idea, but nothing that I would block the merge on08:31
blueCmdat most I can agree on adding a '# TODO(bluecmd): Refactor this mess' in the constructor08:51
stekernthat commit was the one I liked the most :(08:52
blueCmdstekern: which one?08:52
blueCmdstekern: I think  d74bd5d is what olofk is talking about08:56
blueCmdbut he doesn't want to merge 9cbbe6d either :P08:56
blueCmdI'll soon start to compare him with one mr. Depper08:56
stekernU Drepper?08:57
stekern(because I realised that the U on it own could get interpreted as 'you')08:58
stekernI think most project maintainers are annoying bastards, and in many cases it's for the good. So olofk seems like a good fit! ;)08:59
stekernolofk: no offense, jk =P08:59
blueCmdbut yes, U. Drepper09:00
stekernno, I think he is definitely speaking about 9cbbe6d09:19
blueCmdstekern: yes, you're right - I'm confused09:25
stekernI'm always right, unless when I'm wrong09:35
stekernand when that happens, I hate to admit it, but people who can't admit that they are wrong annoys me (I'm married to one, so I should know ;)), so I do it anyway.09:39
blueCmdWebCoreSupport/FrameLoaderClientQt.h:139:18: internal compiler error: in expand_expr_addr_expr_1, at expr.c:762909:41
stekernIs that related to your atomics, or is it some old latent bug?09:44
stekernI don't understand the point Jose is trying to make on the ML09:44
stekernQ: did you clean the fusesoc cache? A: We load the program with openocd09:45
blueCmdstekern: I don't know as of yet, it might be all kinds of things09:57
blueCmdstekern: not sure he's answering to the question per say09:57
blueCmdper se*09:58
stekernyeah, I think you are right... it seems they are trying to load the program with openocd, set the breakpoint from within openocd, then open gdb and the bp isn't there?10:03
stekernor something like that... is that even supposed to work?10:03
olofkYawn.... the Hitler of project maintainers is now awake10:05
stekernOlof Drepper10:05
olofk's lonely heart club band10:05
stekernStefan Poetter10:06
stekernand Christian Sievers10:06
olofk"There's nothing wrong with my code. It's your fault!"10:06
olofkWhat could possibly go wrong? :)10:06
stekernI should probably turn off gmail notifications, the distraction chops off what I write in the middle10:08
olofkTwo more patches pushed10:10
-!- Netsplit *.net <-> *.split quits: bentley`10:10
olofkNow I just need a coffe to wake up a bit before picking the last two10:11
olofkSleeping makes you extremely tired10:11
stekerndoesn't you have a living alarm clock?10:15
stekernwhen I for once wanted to sleep longer, mine woke me at 7 by yelling in my ear that "I WANT BREAKFAST!!!"10:15
olofkOh god10:22
blueCmdstekern: yes! I got olofk to apply my patch :)10:26
blueCmdname calling worked10:26
stekernthat's good to know in the future10:27
stekernI can see how we are building a nice and cozy environment here ;)10:27
olofkI got so flattered when I was called an annoying bastard. No one has ever said anything so nice to me before10:28
olofkThink they should all be applied now. Check if I missed something. Had to do some manual conflict resolving since I pulled them in a different order10:29
olofkSo, regarding the cache mess10:29
olofkYes, I think you're right in that I should have kept it more visible10:30
olofkBut there are two issues10:30
olofkI think that the first thing to do is to change it to ignore the --force flag and always rebuild until there are mechanisms in place to check if things have been changed10:31
olofkBut to avoid needless rebuilds in the future there should be something to checksum the sources, or at least check the timestamps to know if we need to rebuild10:33
olofkI'm considering taking advantage of make or waf here since they already have this implemented10:34
olofkBut haven't investigated it further10:34
olofkThe other issue will have to wait post coffe10:34
stekernI think at least a couple of things should automatically wipe the cache:10:37
stekern1) you change the provider of a core10:37
stekern2) the build dir have changed10:38
stekern3) an alternative of 2), the builddir have been wiped10:38
stekern2) and 3) ultimately makes a global cache moot though10:39
stekerndoes the --force flag wipe the cache?10:39
blueCmd--force doesn't sound like 'wipe the cache' to me10:41
olofkNo, I'm talking about the problem where the simulation binary/FPGA image is not being rebuilt10:42
stekernah, right10:43
stekernI'm only concerned about the cache issues10:43
stekernincremental build is another (interesting) topic10:44
olofkYes, but ok. Caches first :)10:44
blueCmdre: using make, please don't10:45
olofkIn my grand plan, this is a bit related to versioning as well, so I'll outline my long-term plan and we'll see what we should do short-term10:45
blueCmdmake uses timestamps, it's trivial to implement10:45
blueCmdmake is horrible in all other regards10:45
stekernwhy is it so much easier to open tabs in a browser than to close them10:46
blueCmdctrl-w ?10:46
blueCmdit was more a philosophical question10:46
stekernblueCmd: the one thing I like with the Makefile generation is that it makes the builddir a completely usable "projectdir" completely independent of fusesoc10:47
stekernnot sure if that's a reason enough to keep it though...10:47
olofkblueCmd, stekern: Those are different issues, imo10:47
stekernheh, yes I don't have much problems on the technical level of closing browser tabs ;)10:48
olofkmakefile generation will stay for the reason that stekern mentioned10:48
olofkBut using make to decide if the source has changed is another thing10:49
olofkIt's actually more rsync, that I'm looking for to implement10:52
olofkSo fusesoc could update the list of input files (for example icarus.scr in the icarus case) if any files were changed, and then make would rebuild the whole thing because icarus.scr was changed10:54
olofkBad example, since icarus doesn't use make currently, but you get the point10:55
olofkanyway, back to the caches: All cores will be versioned, so you can make incompatible changes to a core and make other cores depend on the old or the new one10:57
olofkAnd FuseSoC will expect that a versioned core is not changed11:00
olofkThis will make it troublesome for people who are developing cores, but I see two ways around that11:00
olofk1. Use a local provider, like stekern is already doing for mor1kx (am I right?)11:01
olofk2. Add a "live" tag to the core description to force it to always be refetched11:01
olofkWe could implement 2 straight away for those cores we expect to be updated a lot11:02
olofkThe last thing to solve is changes to the core that uses the same upstream code, like changing provider, adding patches, changing modelsim settings and so on11:07
stekernyes, I always just comment out the provider section and symlink the dirs of the core I'm hacking on11:07
olofkFor those I propose gentoo style revisions11:07
stekernI don't see that as an issue11:07
blueCmdstekern: that's what I'm afraid of, if we make fusesoc like autoconf - only generating Makefiles, we are bound to end up with the same mess that cmake is trying to solve11:41
blueCmdand jam*11:41
stekerncomparing fusesoc to autoconf, just because the output file format would be the same, that seems a bit unfair.12:08
stekernI don't hate make (autoconf otoh...), but I'm not in love with it neither...12:09
stekernthe current Makefile that is generated could easily be replaced with a .sh though, there's no "logic" in it at all12:10
stekernI'd be fine with that as well12:11
stekernyou'll probably be more likely to find make than a shell on windows machines though12:12
blueCmdstekern: what are you hoping to achieve with having it output a builder instead of just building?12:15
stekern"a completely usable "projectdir" completely independent of fusesoc"12:20
blueCmdwhich is good why?12:22
stekernbecause, you can pack that up as a "known to be good" static version12:23
stekernas I said, I don't know how important that is to sustain, but I have had use for it a couple of times already12:24
blueCmdmy personal oppinion is that it adds a nightmarish complexity and makes testing much harder12:25
stekernhow is that complex?12:26
blueCmdit might be possible to do in a nice way if we wrapp each command in a thing than can either just run it or write a makefile/script for it12:26
stekernas I said, the Makefile can easily be replaced with a shell script12:27
blueCmdstekern: you need to implement the syntax for Makefiles in fusesoc12:27
stekernI agree that making them any more complex than that, that's a bad idea12:27
stekernI mean, look at the Makefile, if you call that complex, then I'll stop arguing ;)12:28
blueCmdstekern: sure, when you write them manually12:32
blueCmdmy build directory has 298 files12:32
blueCmdthat means 298 dependencies and build targets (some ratio of either)12:32
stekernthere's nothing about the files in the Makefile12:33
blueCmdif you want to track modification and dependencies12:33
stekernagain, the Makefile doesn't do anything fancy, it's just a 'script'12:33
blueCmdstekern: I would urge you to write a Makefile that would be a model how the output would look like12:33
blueCmdI don't think it will be very nice12:34
stekernI'm not sure I'm following what you are saying now....12:34
blueCmdwell, if it's just a script that's a bit of a waste of using Make then12:34
stekern...which I have been saying all the time, we could replace it with a .sh12:35
blueCmdhaving fusesoc just dump all commands it would execute to a file and call it a Makefile?12:35
blueCmdstekern: right, I saw that but I assumed you actually wanted to have the same functionallity in both the makefile and the script12:35
blueCmdthat the script would _also_ look at depdendencies and timestamps12:35
stekerndid you look at the quartus Makefile that is generated? ;)12:36
blueCmdI did not12:36
blueCmdthis is why we cannot have nice things12:36
blueCmdyeah, that's just a waste12:41
stekernso, what would you like to replace it with?12:41
blueCmdthat will either run nothing or all 5 commands12:41
blueCmd5 invokations of subprocess.call12:41
stekernah, but then you depend on python12:42
blueCmdhaha, yes. fusesoc kinda already does12:42
stekernyes, but the whole point was to *not* depend on fusesoc12:42
blueCmd(if you want to archive the project as you said before)12:42
stekernyeah, maybe it's not important12:43
blueCmdbut that is an odd case and I hate to see it drive the design descisions12:43
blueCmd(with correct spelling of decisions)12:43
blueCmdfrom a testing perspective I would love to have a 'CommandOutput' interface that could either be 'Execute' or 'SaveToScript'12:44
blueCmdit would be quite neat and not hard to do, and would also clean up the mess of 'Launcher' in utils.p12:46
stekernI just liked the transparency of the standalone builddir that could be thrown to your buddies with a comment "just run make"12:47
stekern...if it actually have any real world use *shrug*12:47
blueCmdstekern: I know, and it's a neat idea - it can be implemented quite nicely as an 'export' command or something, but I hate it when the intermediate files produce more intermediate files12:48
stekernand by transparency, I mean, "it does what the Makefile say, no fusesoc magic involved"12:49
blueCmdpersonally I would like to see 'fusesoc export de0_nano' spit out a .tar with script/makefile/whatever12:49
stekernright, *that* I'd like too12:50
blueCmdhaving that the standard code path would force all design decisions to take into account 'How do we do this in the Makefile?'12:50
blueCmdor script or whatever12:51
stekern(even though fusesoc "magic" in that case would just be doing exactly the same as the Makefile)12:51
blueCmdit might not be a problem, but I hate to discover that it is further down the road12:51
stekernyeah, I can see the reasoning in that...12:51
blueCmdIn my world having 'fusesoc build de0_nano' be the optimized, fully magical one and then having 'fusesoc export de0_nano' spit out a non-magical, perhaps slightly less optimized version is an exciting idea12:52
blueCmdnormally people would at this point go 'but it's easier to have just one codepath so that we know when it breaks' which brings me back to the point of unit tests12:53
blueCmdand mockable interfaces.12:53
olofkMaking the build dir independent on fusesoc is absolutely a design decision, and that will stay. You can't possibly argue that it adds complexity15:39
olofkAnd it's very useful15:40
olofkAnd it could as well be a shell script, but a Makefile is easier15:42
olofkComparing it to cmake or autoconf is a little over the top15:43
blueCmdolofk: it does add complexity15:58
blueCmddenying that is lying to yourself - it's ofc easier to just run the command than to run the same commands to a file, then execute the file15:59
olofkOk.. fine. It adds complexity.18:37
stekernolofk: wait until he notices the .tcl files... ;)20:37
stekernargh.. my 2 line cgen patch doesn't seem to please Frank in whatever-which-way I twist it...21:00
poke53281blueCmd: Tried the debian port. Get when I try to chroot a "kernel too old" message. :(21:12
stekernwhat kernel do you have?21:14
poke53281I use a virtual machine for this. And I don't have the rights to change the kernel.21:14
stekernoh, that *is* old21:14
poke53281I wanted to omit the installing of debian in another virtual machine.21:17
poke53281But it looks like, this is the only way. The binfmt tool is not available in other distributions.21:18
poke53281Anyway, the initramsfs has already a size >120MB. So it will be difficult to run it in jor1k.21:20
--- Log closed Fri May 30 00:00:11 2014

Generated by 2.15.2 by Marius Gedminas - find it at!