| --- Log opened Thu May 29 00:00:10 2014 | ||
| olofk | blueCmd: 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.py | 05:56 |
|---|---|---|
| stekern | olofk: I think that moving the fusesoc cache into a global one (at least before you have a working caching mechanism) was a mistake | 07: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 |
| stekern | now it turned out that it works with the latest version too | 08:23 |
| stekern | but, even though I | 08:24 |
| stekern | *know* that only deleting the build dir isn't enough, I still do the mistake thinking it will | 08:24 |
| blueCmd | olofk: refactoring out that big if statement in the constructor of core.py to a function is a good idea, but nothing that I would block the merge on | 08:31 |
| blueCmd | at most I can agree on adding a '# TODO(bluecmd): Refactor this mess' in the constructor | 08:51 |
| stekern | that commit was the one I liked the most :( | 08:52 |
| blueCmd | stekern: which one? | 08:52 |
| stekern | 9cbbe6d | 08:53 |
| blueCmd | stekern: I think d74bd5d is what olofk is talking about | 08:56 |
| blueCmd | but he doesn't want to merge 9cbbe6d either :P | 08:56 |
| blueCmd | I'll soon start to compare him with one mr. Depper | 08:56 |
| blueCmd | Drepper* | 08:56 |
| stekern | U? | 08:57 |
| stekern | U Drepper? | 08:57 |
| stekern | (because I realised that the U on it own could get interpreted as 'you') | 08:58 |
| stekern | I 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 |
| stekern | olofk: no offense, jk =P | 08:59 |
| blueCmd | but yes, U. Drepper | 09:00 |
| stekern | no, I think he is definitely speaking about 9cbbe6d | 09:19 |
| blueCmd | stekern: yes, you're right - I'm confused | 09:25 |
| stekern | I'm always right, unless when I'm wrong | 09:35 |
| stekern | s/unless/except | 09:35 |
| stekern | and 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 |
| blueCmd | WebCoreSupport/FrameLoaderClientQt.h:139:18: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7629 | 09:41 |
| blueCmd | auch | 09:41 |
| stekern | Is that related to your atomics, or is it some old latent bug? | 09:44 |
| stekern | I don't understand the point Jose is trying to make on the ML | 09:44 |
| stekern | Q: did you clean the fusesoc cache? A: We load the program with openocd | 09:45 |
| blueCmd | stekern: I don't know as of yet, it might be all kinds of things | 09:57 |
| blueCmd | stekern: not sure he's answering to the question per say | 09:57 |
| blueCmd | per se* | 09:58 |
| stekern | yeah, 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 |
| stekern | or something like that... is that even supposed to work? | 10:03 |
| olofk | Yawn.... the Hitler of project maintainers is now awake | 10:05 |
| stekern | Olof Drepper | 10:05 |
| olofk | 's lonely heart club band | 10:05 |
| stekern | Stefan Poetter | 10:06 |
| olofk | lol | 10:06 |
| stekern | and Christian Sievers | 10:06 |
| olofk | "There's nothing wrong with my code. It's your fault!" | 10:06 |
| olofk | What could possibly go wrong? :) | 10:06 |
| stekern | +ing | 10:06 |
| stekern | I should probably turn off gmail notifications, the distraction chops off what I write in the middle | 10:08 |
| olofk | Two more patches pushed | 10:10 |
| -!- Netsplit *.net <-> *.split quits: bentley` | 10:10 | |
| olofk | Now I just need a coffe to wake up a bit before picking the last two | 10:11 |
| olofk | Sleeping makes you extremely tired | 10:11 |
| stekern | doesn't you have a living alarm clock? | 10:15 |
| stekern | don't | 10:15 |
| stekern | when I for once wanted to sleep longer, mine woke me at 7 by yelling in my ear that "I WANT BREAKFAST!!!" | 10:15 |
| olofk | Oh god | 10:22 |
| blueCmd | stekern: yes! I got olofk to apply my patch :) | 10:26 |
| blueCmd | name calling worked | 10:26 |
| stekern | that's good to know in the future | 10:27 |
| stekern | I can see how we are building a nice and cozy environment here ;) | 10:27 |
| olofk | I got so flattered when I was called an annoying bastard. No one has ever said anything so nice to me before | 10:28 |
| stekern | haha | 10:28 |
| olofk | Think 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 order | 10:29 |
| olofk | So, regarding the cache mess | 10:29 |
| olofk | Yes, I think you're right in that I should have kept it more visible | 10:30 |
| olofk | But there are two issues | 10:30 |
| olofk | I 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 changed | 10:31 |
| olofk | But 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 rebuild | 10:33 |
| olofk | I'm considering taking advantage of make or waf here since they already have this implemented | 10:34 |
| olofk | But haven't investigated it further | 10:34 |
| olofk | The other issue will have to wait post coffe | 10:34 |
| stekern | I think at least a couple of things should automatically wipe the cache: | 10:37 |
| stekern | 1) you change the provider of a core | 10:37 |
| stekern | 2) the build dir have changed | 10:38 |
| stekern | 3) an alternative of 2), the builddir have been wiped | 10:38 |
| stekern | 2) and 3) ultimately makes a global cache moot though | 10:39 |
| stekern | does the --force flag wipe the cache? | 10:39 |
| blueCmd | --force doesn't sound like 'wipe the cache' to me | 10:41 |
| olofk | No, I'm talking about the problem where the simulation binary/FPGA image is not being rebuilt | 10:42 |
| stekern | ah, right | 10:43 |
| stekern | I'm only concerned about the cache issues | 10:43 |
| stekern | incremental build is another (interesting) topic | 10:44 |
| olofk | Yes, but ok. Caches first :) | 10:44 |
| blueCmd | re: using make, please don't | 10:45 |
| olofk | In 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-term | 10:45 |
| blueCmd | make uses timestamps, it's trivial to implement | 10:45 |
| blueCmd | make is horrible in all other regards | 10:45 |
| stekern | why is it so much easier to open tabs in a browser than to close them | 10:46 |
| blueCmd | ctrl-w ? | 10:46 |
| blueCmd | aha | 10:46 |
| blueCmd | it was more a philosophical question | 10:46 |
| stekern | blueCmd: the one thing I like with the Makefile generation is that it makes the builddir a completely usable "projectdir" completely independent of fusesoc | 10:47 |
| stekern | not sure if that's a reason enough to keep it though... | 10:47 |
| olofk | blueCmd, stekern: Those are different issues, imo | 10:47 |
| stekern | heh, yes I don't have much problems on the technical level of closing browser tabs ;) | 10:48 |
| olofk | makefile generation will stay for the reason that stekern mentioned | 10:48 |
| olofk | But using make to decide if the source has changed is another thing | 10:49 |
| stekern | yes | 10:51 |
| olofk | It's actually more rsync, that I'm looking for to implement | 10:52 |
| olofk | So 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 changed | 10:54 |
| olofk | Bad example, since icarus doesn't use make currently, but you get the point | 10:55 |
| olofk | anyway, 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 one | 10:57 |
| olofk | And FuseSoC will expect that a versioned core is not changed | 11:00 |
| olofk | This will make it troublesome for people who are developing cores, but I see two ways around that | 11:00 |
| olofk | 1. Use a local provider, like stekern is already doing for mor1kx (am I right?) | 11:01 |
| olofk | 2. Add a "live" tag to the core description to force it to always be refetched | 11:01 |
| olofk | We could implement 2 straight away for those cores we expect to be updated a lot | 11:02 |
| olofk | The 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 on | 11:07 |
| stekern | yes, I always just comment out the provider section and symlink the dirs of the core I'm hacking on | 11:07 |
| olofk | For those I propose gentoo style revisions | 11:07 |
| stekern | I don't see that as an issue | 11:07 |
| blueCmd | stekern: 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 solve | 11:41 |
| blueCmd | na | 11:41 |
| blueCmd | and jam* | 11:41 |
| stekern | comparing fusesoc to autoconf, just because the output file format would be the same, that seems a bit unfair. | 12:08 |
| stekern | I don't hate make (autoconf otoh...), but I'm not in love with it neither... | 12:09 |
| stekern | the current Makefile that is generated could easily be replaced with a .sh though, there's no "logic" in it at all | 12:10 |
| stekern | I'd be fine with that as well | 12:11 |
| stekern | you'll probably be more likely to find make than a shell on windows machines though | 12:12 |
| blueCmd | stekern: 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 |
| blueCmd | which is good why? | 12:22 |
| stekern | because, you can pack that up as a "known to be good" static version | 12:23 |
| stekern | as I said, I don't know how important that is to sustain, but I have had use for it a couple of times already | 12:24 |
| blueCmd | my personal oppinion is that it adds a nightmarish complexity and makes testing much harder | 12:25 |
| stekern | how is that complex? | 12:26 |
| blueCmd | it 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 it | 12:26 |
| stekern | as I said, the Makefile can easily be replaced with a shell script | 12:27 |
| blueCmd | stekern: you need to implement the syntax for Makefiles in fusesoc | 12:27 |
| stekern | I agree that making them any more complex than that, that's a bad idea | 12:27 |
| stekern | I mean, look at the Makefile, if you call that complex, then I'll stop arguing ;) | 12:28 |
| blueCmd | stekern: sure, when you write them manually | 12:32 |
| blueCmd | my build directory has 298 files | 12:32 |
| stekern | so...? | 12:32 |
| blueCmd | that means 298 dependencies and build targets (some ratio of either) | 12:32 |
| stekern | there's nothing about the files in the Makefile | 12:33 |
| blueCmd | if you want to track modification and dependencies | 12:33 |
| stekern | again, the Makefile doesn't do anything fancy, it's just a 'script' | 12:33 |
| blueCmd | stekern: I would urge you to write a Makefile that would be a model how the output would look like | 12:33 |
| blueCmd | I don't think it will be very nice | 12:34 |
| stekern | I'm not sure I'm following what you are saying now.... | 12:34 |
| blueCmd | well, if it's just a script that's a bit of a waste of using Make then | 12:34 |
| stekern | ...which I have been saying all the time, we could replace it with a .sh | 12:35 |
| blueCmd | having fusesoc just dump all commands it would execute to a file and call it a Makefile? | 12:35 |
| blueCmd | stekern: right, I saw that but I assumed you actually wanted to have the same functionallity in both the makefile and the script | 12:35 |
| blueCmd | that the script would _also_ look at depdendencies and timestamps | 12:35 |
| stekern | did you look at the quartus Makefile that is generated? ;) | 12:36 |
| blueCmd | *ugh* | 12:36 |
| blueCmd | I did not | 12:36 |
| blueCmd | this is why we cannot have nice things | 12:36 |
| stekern | http://pastie.org/9235119 | 12:39 |
| blueCmd | yeah, that's just a waste | 12:41 |
| stekern | so, what would you like to replace it with? | 12:41 |
| blueCmd | that will either run nothing or all 5 commands | 12:41 |
| blueCmd | 5 invokations of subprocess.call | 12:41 |
| stekern | ah, but then you depend on python | 12:42 |
| blueCmd | haha, yes. fusesoc kinda already does | 12:42 |
| stekern | yes, but the whole point was to *not* depend on fusesoc | 12:42 |
| blueCmd | why? | 12:42 |
| blueCmd | (if you want to archive the project as you said before) | 12:42 |
| stekern | yeah, maybe it's not important | 12:43 |
| blueCmd | but that is an odd case and I hate to see it drive the design descisions | 12:43 |
| blueCmd | (with correct spelling of decisions) | 12:43 |
| blueCmd | from a testing perspective I would love to have a 'CommandOutput' interface that could either be 'Execute' or 'SaveToScript' | 12:44 |
| blueCmd | it would be quite neat and not hard to do, and would also clean up the mess of 'Launcher' in utils.p | 12:46 |
| blueCmd | py* | 12:46 |
| stekern | I 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 |
| blueCmd | stekern: 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 files | 12:48 |
| stekern | and by transparency, I mean, "it does what the Makefile say, no fusesoc magic involved" | 12:49 |
| blueCmd | personally I would like to see 'fusesoc export de0_nano' spit out a .tar with script/makefile/whatever | 12:49 |
| stekern | right, *that* I'd like too | 12:50 |
| blueCmd | having that the standard code path would force all design decisions to take into account 'How do we do this in the Makefile?' | 12:50 |
| blueCmd | or script or whatever | 12:51 |
| stekern | (even though fusesoc "magic" in that case would just be doing exactly the same as the Makefile) | 12:51 |
| blueCmd | it might not be a problem, but I hate to discover that it is further down the road | 12:51 |
| blueCmd | I'd* | 12:51 |
| stekern | yeah, I can see the reasoning in that... | 12:51 |
| blueCmd | In 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 idea | 12:52 |
| blueCmd | normally 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 tests | 12:53 |
| blueCmd | and mockable interfaces. | 12:53 |
| olofk | Making the build dir independent on fusesoc is absolutely a design decision, and that will stay. You can't possibly argue that it adds complexity | 15:39 |
| olofk | And it's very useful | 15:40 |
| olofk | And it could as well be a shell script, but a Makefile is easier | 15:42 |
| olofk | Comparing it to cmake or autoconf is a little over the top | 15:43 |
| blueCmd | olofk: it does add complexity | 15:58 |
| blueCmd | denying 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 file | 15:59 |
| olofk | Ok.. fine. It adds complexity. | 18:37 |
| stekern | olofk: wait until he notices the .tcl files... ;) | 20:37 |
| stekern | argh.. my 2 line cgen patch doesn't seem to please Frank in whatever-which-way I twist it... | 21:00 |
| poke53281 | blueCmd: Tried the debian port. Get when I try to chroot a "kernel too old" message. :( | 21:12 |
| stekern | what kernel do you have? | 21:14 |
| poke53281 | 2.6.32 | 21:14 |
| poke53281 | I use a virtual machine for this. And I don't have the rights to change the kernel. | 21:14 |
| stekern | oh, that *is* old | 21:14 |
| poke53281 | I wanted to omit the installing of debian in another virtual machine. | 21:17 |
| poke53281 | But it looks like, this is the only way. The binfmt tool is not available in other distributions. | 21:18 |
| poke53281 | Anyway, 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 irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!