| --- Log opened Tue May 27 00:00:07 2014 | ||
| stekern | blueCmd: nice cleanups, there was a lot of stuff in there that I have been wondering "there got to be a better way to do this in python, wonder how" | 05:24 |
|---|---|---|
| olofk | It was better before that | 05:26 |
| stekern | especially the if bla: return quartus if bleh: return ise | 05:26 |
| stekern | olofk: you're just suffering from decorator withdrawal right now ;) | 05:39 |
| olofk | blueCmd: RFCoC | 06:32 |
| stekern | olofk: http://www.rfcoc.org/ | 06:34 |
| stekern | ? | 06:34 |
| olofk | Request for comments on comments. But I liked your link better | 06:35 |
| olofk | Time to go out in the garden and do some decorating to help with my python withdrawal | 06:36 |
| stekern | sounds nice, but watch out for snakes! | 06:37 |
| stekern | it's cold and rainy here today though, first day in a week or two I'm not sorry I've got an indoors job | 06:39 |
| _franck__ | blueCmd: I think something like that in the system core file will be more clear: http://pastie.org/private/ufacqiomzvegrsy4hxweq | 06:55 |
| stekern | are those two different suggestions? | 06:57 |
| _franck__ | I knew that wasn't clear when I pasted it :) | 06:57 |
| _franck__ | the one at the top is blueCmd's suggestion | 06:58 |
| _franck__ | mine is at the bottom | 06:58 |
| stekern | oh, right, I see now | 06:58 |
| stekern | from a .core file perspective only, I think I like the latter better | 06:59 |
| stekern | olofk: where's your coc? | 07:01 |
| olofk | https://github.com/bluecmd/fusesoc/commit/0e391de954caefaf68b80046eb5ce30121f57318#commitcomment-6453402 | 07:29 |
| olofk | My proposal is like something inbetween the two alternatives in _franck__'s pastie | 07:30 |
| stekern | I wonder why your coc doesn't show in the pull request, and there was no notification about it | 07:37 |
| stekern | maybe it was censored... | 07:38 |
| olofk | Grrr... that happens all the time when I try to show my coc | 07:40 |
| olofk | I added another comment now | 07:41 |
| stekern | ah, there was no pull-request for that | 07:52 |
| olofk | blueCmd: Isn't collections.default_dict() just the same as {}? | 08:17 |
| olofk | Trying to figure out what you're doing here | 08:17 |
| olofk | Nope. I don't understand | 08:22 |
| olofk | to_generate = collections.defaultdict(lambda : collections.defaultdict(list)) ? | 08:23 |
| olofk | Is it just a dict of dicts? | 08:23 |
| olofk | Or a dict of dict of lists? | 08:23 |
| blueCmd | olofk: the difference there is that when you reference something that doesn't exist, the generator is ran and fills it | 08:40 |
| blueCmd | a = {} | 08:40 |
| blueCmd | a['hello'].append('test') | 08:40 |
| blueCmd | thaht doesn't work | 08:40 |
| blueCmd | a = collections.defaultdict(list) does | 08:41 |
| blueCmd | and the thing i do is dict of dict of list | 08:41 |
| blueCmd | _franck__: yes, agreed - I like your idea better | 08:44 |
| blueCmd | olofk: replied via mail which github screwed up a bit, but you're a smart man I'm sure you will figure out how to read it :) | 09:00 |
| olofk | Ah cool dict trick. Didn't think of that | 09:11 |
| stekern | do a trick with your dict and I'll show you my coc? | 09:13 |
| stekern | ...I'll be quiet now... | 09:14 |
| olofk | :) | 09:19 |
| olofk | Why the hell doesn't the 'r' shortcut for reply work for me on github | 09:19 |
| olofk | gtg. More comments later, but basically I think we're on the same page now | 09:20 |
| olofk | blueCmd: I'm not following you why core: would be better than generate:. I don't mind either way, just feel that I missed something | 11:23 |
| kyrre_ | hi, im experiencing somthing weird with or1ksim.. im watching the cpu_state.pc which holds the program counter, at some point in my program it makes a huge jump, to a location outside of my program, and then enters a loop. When i check the executed log, i cant see the program counter for the adress wich it loops | 11:53 |
| LoneTech | it might not actually be executing anything there. it could be looping an exception such as instruction fetch bus error or illegal instruction. | 11:55 |
| kyrre_ | ill see what i can find | 11:57 |
| LoneTech | what address was it? | 11:59 |
| kyrre_ | breaking on except_handle i cant see that its processing an exception, or did you mean an exception produced outside of my simulator? | 11:59 |
| LoneTech | most likely inside | 11:59 |
| kyrre_ | e59c - e5a0 | 12:00 |
| kyrre_ | rins and repeat | 12:00 |
| LoneTech | not normally a part of the exception range. still, the or1k is designed to just loop in place if it tries to execute zeroes, so perhaps a misdirected branch brought it there. | 12:01 |
| blueCmd | olofk: because it can be a section for all core configs | 12:02 |
| kyrre_ | ye, that was my assumtion but the adress wich brind it theer is 8590 which is a addi | 12:02 |
| blueCmd | olofk: let's say we add a 'validate' step (not sure what it would do, but bear with me), in your case it would require an addition of [validate:wb_intercon] | 12:02 |
| blueCmd | also, 'core:' is shorter :) | 12:03 |
| blueCmd | olofk: I've ran a code formater on FuseSoC, the diff is huge - is that something you want to apply? | 12:05 |
| kyrre_ | ive found where it enters the loop in the execution log now | 12:07 |
| LoneTech | what's before the addi? | 12:09 |
| kyrre_ | the last instructions before the addi (including addi at the end) : l.lwz | l.jal misc_int_handler | l.lwz | l.sw | l.addi | 12:17 |
| LoneTech | so a store word. shouldn't branch by itself. I don't know what's happening | 12:19 |
| kyrre_ | the store word is the first in the misc_int_handler | 12:21 |
| kyrre_ | this is not the first time ive experienced weird jumps | 12:21 |
| kyrre_ | have had other times when it jumps to places it shouldnt. like 508 which is one word beyond an exception handler | 12:22 |
| stekern | what's after the l.addi? | 12:33 |
| stekern | and, what version of or1ksim is this | 12:34 |
| stekern | ? | 12:34 |
| kyrre_ | EXECUTED( 116719): 0000e59c: 00000000 | 12:34 |
| kyrre_ | OpenRISC 1000 Architectural Simulator, version 2012-04-27 | 12:35 |
| kyrre_ | but i have added a module | 12:35 |
| kyrre_ | e59c is an adress outside of my program | 12:36 |
| stekern | I meant, next instruction that comes after the l.addi in your program | 12:36 |
| kyrre_ | ah | 12:36 |
| kyrre_ | l.sw | 12:36 |
| kyrre_ | then another addi | 12:36 |
| stekern | and that version number doesn't say anything (we should fix that), I meant where did you get it from svn/git/prebuilt somewhere | 12:37 |
| kyrre_ | svn | 12:37 |
| kyrre_ | ive had problems with using stable releases for or1k-gcc | 12:38 |
| stekern | kyrre_: could you try this? https://github.com/openrisc/or1ksim | 12:42 |
| kyrre_ | i can try, but probably gonna take me a while to add my changes to it | 12:42 |
| kyrre_ | the problem persists even if i disable my module, so lets see | 12:44 |
| stekern | what kind of machine do you have (64-bit, 32-bit etc) | 12:46 |
| kyrre_ | 64bit | 12:46 |
| kyrre_ | ubuntu 14.04 | 12:46 |
| kyrre_ | error | 12:46 |
| kyrre_ | collect2: error: ld returned 1 exit status | 12:46 |
| kyrre_ | make[2]: *** [sim] Error 1 | 12:46 |
| kyrre_ | make[2]: Leaving directory `/home/kyrre/or1ksimGIT/bld-or1ksim' | 12:46 |
| kyrre_ | make[1]: *** [all-recursive] Error 1 | 12:46 |
| kyrre_ | make[1]: Leaving directory `/home/kyrre/or1ksimGIT/bld-or1ksim' | 12:46 |
| kyrre_ | make: *** [all] Error 2 | 12:46 |
| stekern | there was a lot of issues with earlier versions of or1ksim and 64-bit machines, but nothing that severe I think | 12:47 |
| stekern | kyrre_: use some paste service (pastie/pastebin) and paste the actual error too | 12:48 |
| kyrre_ | http://pastiebin.com/538489df53f20 | 12:49 |
| kyrre_ | the output from make | 12:50 |
| stekern | and that's after a: ../or1ksim/configure && make | 12:54 |
| stekern | ? | 12:54 |
| kyrre_ | yes | 12:56 |
| kyrre_ | tried the string i use to configure the or1ksim im currently using: ../or1ksim/configure --target=or32-elf --prefix=/opt/or1ksim CFLAGS="-O0 -g -Wno-unused-but-set-variable" | 12:57 |
| kyrre_ | both return in the same error | 12:57 |
| stekern | I just tried building that on a similar machine as yours, without problem | 12:59 |
| blueCmd | olofk: https://github.com/bluecmd/fusesoc/commit/71b98a1101296095c89823c21ca32f69b817c25c | 12:59 |
| stekern | kyrre_: you can try this binary, just to check the original issue: http://oompa.chokladfabriken.org/openrisc/sim | 13:00 |
| kyrre_ | is it built with -g? | 13:02 |
| stekern | nope, but I can rebuild it with that if you want | 13:02 |
| kyrre_ | would be easier to verify | 13:03 |
| stekern | I have never ran or1ksim in a debugger... ;) | 13:04 |
| stekern | why would you need to do that? | 13:04 |
| kyrre_ | because im modifying or1ksim | 13:04 |
| stekern | ok... with your CFLAGS I get the same error | 13:05 |
| stekern | but you got them with ../or1ksim/configure && make as well | 13:06 |
| kyrre_ | yes | 13:07 |
| stekern | ok... but can you confirm if the binary I gave you have the original issue anyway | 13:08 |
| stekern | you don't need -g to do that | 13:08 |
| kyrre_ | i cant find the issue in that one | 13:11 |
| stekern | it seems like it's the -O0 that causes it on my side, I've updated the sim to one compiled iwth -g now | 13:13 |
| kyrre_ | k | 13:13 |
| stekern | ok, so that works. Then it's kind of determined that it's an issue with the svn version | 13:15 |
| kyrre_ | hm.. the -g version just stopped responding in gdb | 13:16 |
| kyrre_ | its stuck at the same adresses | 13:16 |
| kyrre_ | so that means its either an issue with my code or or1ksim? | 13:16 |
| kyrre_ | but since my code shouldnt result in this behavior its most likely or1ksim | 13:17 |
| kyrre_ | ill recheck the execution logs and check vs the dissasembly again | 13:18 |
| stekern | ? can you reproduce the behaviour with the one compiled with -g? | 13:19 |
| stekern | but not in the one that wasn't compiled with -g? | 13:20 |
| kyrre_ | im not sure how to catch the error from the "top" (if that makes sence) | 13:22 |
| kyrre_ | but yes | 13:22 |
| kyrre_ | ive got watcpoints watching the cpu_state.pc and looking for that specific address, not sure how to watch the pc from the program | 13:24 |
| stekern | well, doesn't it just get stuck at that address? | 13:32 |
| kyrre_ | it executes til its stuck, but ctrl+c doesnt return to promt | 13:36 |
| stekern | not sure I follow? | 13:38 |
| stekern | that certainly sounds like or1ksim have crashed then | 13:39 |
| kyrre_ | ye, cause its stuck in that loop | 13:39 |
| kyrre_ | its still running | 13:39 |
| kyrre_ | im not sure how i can verify that its the same issue | 13:39 |
| kyrre_ | how* | 13:40 |
| stekern | _your_ program is stuck in the loop, but or1ksim should still be responsive | 13:41 |
| kyrre_ | it jumps to e95c | 13:43 |
| kyrre_ | there it has a l.j 0xe59c | 13:44 |
| stekern | yes... | 13:44 |
| stekern | but why isn't or1ksim working after that? | 13:45 |
| kyrre_ | it works with the gdb stepi command now | 13:45 |
| stekern | ok, let's put aside running it in gdb... does it or does it not work when you run it normally? | 13:46 |
| stekern | can you give me your binary? | 13:47 |
| kyrre_ | or1ksim not in gdb produces the same result | 13:48 |
| kyrre_ | the loop in e59c | 13:48 |
| kyrre_ | it jumps there when its trying to jump to 0x551c | 13:48 |
| kyrre_ | https://www.dropbox.com/s/2pidf3wmhi5eia5/rtosdemo.or32 | 13:49 |
| stekern | thanks, I'll try running it here in a short while | 13:51 |
| inigom | I would like to know if someone has made profiling using OpenOCD. I have tried with both simlators (icarus and verilator) and with the de0_nano board. I'm running an simple enless program. I always get Segmentation Fault. | 13:56 |
| _franck__ | I never used profile with openocd. I don't know what it does. | 13:59 |
| inigom | ok thanks! | 14:00 |
| _franck__ | "Profiling samples the CPU PC as quickly as OpenOCD is able, which will be used as a random sampling of PC." | 14:00 |
| _franck__ | inigom: can you tell me more about openocd profiling ? | 14:01 |
| inigom | I want to use it to check the execution of code in OpenRISC | 14:05 |
| _franck__ | ok, so it read target's PC as fast as possible and saves the result in a file | 14:06 |
| _franck__ | inigom: do you want to check the execution of your program in simulation ? | 14:06 |
| inigom | Yes and also in the board | 14:07 |
| inigom | and to check what is doing OpenRISC with that code | 14:08 |
| _franck__ | do you need RTL simulation ? is or1ksim a possible alternative ? | 14:08 |
| _franck__ | I'll try this profile command and try to fix this segfault | 14:11 |
| inigom | i would like to use RTL. But I'll have a look in or1ksim | 14:24 |
| stekern | kyrre_: it doesn't seem to stall here. | 14:25 |
| kyrre_ | for me it stops after misc int handler is called with the arg -673099780 | 14:26 |
| kyrre_ | after the misc int handler and stepi onwards | 14:28 |
| stekern | but if you just run your program in or1ksim compiled without -g? | 14:30 |
| kyrre_ | yes | 14:30 |
| stekern | then it stalls, after how long? | 14:32 |
| kyrre_ | trying to narrow it down | 14:32 |
| kyrre_ | think i found it | 14:33 |
| stekern | here it just forges on when I run it with: sim -t -f ~/sim.cfg rtosdemo.or32 | 14:35 |
| kyrre_ | i have found a point with gdb where its says "0x858c <misc_int_handler> l.j 0xe59c <xHeap+12064> " | 14:37 |
| kyrre_ | but that is not hat it says in the dissassembly file | 14:37 |
| LoneTech | so the instruction fetch seems to have read 0x6010 at 0x858c | 14:38 |
| LoneTech | or is it 600c? no matter | 14:39 |
| kyrre_ | i have defined 0x6000+(d10) to a spr register for my module | 14:40 |
| stekern | if you read that address from within or1ksim, what do you get then? | 14:41 |
| kyrre_ | cannot acces memory | 14:41 |
| stekern | i.e.: (sim) dh 0x858c | 14:41 |
| kyrre_ | hm... | 14:42 |
| kyrre_ | never used the sim like that before | 14:42 |
| kyrre_ | (sim) dh 0x858c | 14:42 |
| kyrre_ | 00001804 | 14:42 |
| kyrre_ | a5a5a5a5 | 14:42 |
| kyrre_ | 0000b51c | 14:42 |
| kyrre_ | 00000200 | 14:42 |
| kyrre_ | 00000005 | 14:42 |
| kyrre_ | 8462fff4 | 14:42 |
| stekern | I'll repeat the question then, does it stall when you run or1ksim like this: sim -t -f ~/sim.cfg rtosdemo.or32 | 14:42 |
| kyrre_ | 00000007 | 14:42 |
| kyrre_ | 00000008 | 14:42 |
| kyrre_ | 00000010 | 14:42 |
| kyrre_ | 00000011 | 14:42 |
| kyrre_ | 00000012 | 14:42 |
| kyrre_ | 00000013 | 14:42 |
| kyrre_ | 00000014 | 14:43 |
| kyrre_ | 00000015 | 14:43 |
| kyrre_ | 00000016 | 14:43 |
| kyrre_ | 00000017 | 14:43 |
| stekern | that's not right | 14:43 |
| stekern | http://pastie.org/9223317 | 14:43 |
| kyrre_ | its running | 14:43 |
| stekern | so... what are you doing when it's not working... | 14:44 |
| stekern | step by step ;) | 14:44 |
| kyrre_ | it ends up in the loop | 14:44 |
| LoneTech | no idea what 1804 is, a5 looks like a test pattern, and then there's the array of sequential values. has it overwritten its code with data? | 14:44 |
| kyrre_ | with sim -t -f ~/sim.cfg rtosdemo.or32 | 14:44 |
| stekern | ok... so "it's running" was not a confirmation that it does *not* stall...? | 14:45 |
| kyrre_ | it was a confirmation that i had started it | 14:45 |
| stekern | ah, ok | 14:45 |
| stekern | and then it stalls? | 14:45 |
| stekern | so what's different in your and mine setup? | 14:45 |
| kyrre_ | as in repeats the e59c e5a0 loop | 14:46 |
| stekern | yes, it does not do that here | 14:46 |
| kyrre_ | hm... | 14:46 |
| LoneTech | perhaps you simply have enough RAM? | 14:46 |
| kyrre_ | on my computer? or in the simulator? | 14:47 |
| LoneTech | though I don't think or1ksim actually does simulate unwired address lines (causing mirrored RAM views in normal hardware) | 14:47 |
| stekern | to make sure, try with my sim.cfg: http://oompa.chokladfabriken.org/openrisc/sim.cfg | 14:47 |
| stekern | and download the sim again from here: http://oompa.chokladfabriken.org/openrisc/sim | 14:47 |
| kyrre_ | same result with simcfg | 14:49 |
| kyrre_ | dl sim again | 14:49 |
| kyrre_ | its still endinf up in that same loop | 14:51 |
| kyrre_ | are you running it "long enough" | 14:51 |
| kyrre_ | but doesnt take that long on my comp | 14:51 |
| stekern | I've had it running for 5 min now | 14:52 |
| kyrre_ | ok | 14:52 |
| kyrre_ | running the new sim with your sim.cfg with the rtosdemo from my dropbox | 14:52 |
| kyrre_ | ends in the loop | 14:52 |
| stekern | weird... | 14:53 |
| kyrre_ | with the same command you posted | 14:53 |
| stekern | just to make sure that you run the right sim: ./sim -t -f ~/sim.cfg rtosdemo.or32 | 14:54 |
| stekern | right? | 14:54 |
| kyrre_ | ./sim -t -f ~/sim.cfg rtosdemo.or32 | 14:54 |
| kyrre_ | copy pasted from last comand :) | 14:54 |
| stekern | LoneTech: can you try? | 14:54 |
| stekern | I'll try on my laptop too | 14:55 |
| stekern | works fine on my laptop too | 14:58 |
| kyrre_ | ..... | 14:59 |
| kyrre_ | this is realy weird | 15:00 |
| stekern | sure is... | 15:01 |
| LoneTech | one moment | 15:02 |
| kyrre_ | if i stop gdb right after i start it, and prints dh 0x858c | 15:02 |
| kyrre_ | http://pastie.org/9223387 | 15:02 |
| kyrre_ | which is the same as what you pasted earlier | 15:03 |
| stekern | yes, and that matches what's in rtosdemo.or32 | 15:03 |
| stekern | put a printf on writes to that or1ksim then | 15:04 |
| stekern | (or breakpoint, or whatever you fancy the most) | 15:04 |
| kyrre_ | kk | 15:04 |
| stekern | *on writes to that in or1ksim | 15:04 |
| stekern | to 0x858c I mean | 15:05 |
| _franck__ | rtosdemo.or32 works fine here | 15:05 |
| LoneTech | ran it for a while, expected code at 858c still. not overwritten yet. | 15:05 |
| stekern | ok, so something is off with kyrre_'s machine, would be interesting to know what... | 15:05 |
| LoneTech | 1700008 cycles | 15:06 |
| stekern | on a different matter, I'm getting closer to mr heisenbug | 15:07 |
| stekern | I've isolated a situation where both processors are waiting for a spinlock with irq's turned off | 15:09 |
| kyrre_ | struggeling to break on that memory adress | 15:11 |
| kyrre_ | getting cand access memory when i try to examin it | 15:12 |
| stekern | so just put a printf in the or1ksim memory access function | 15:12 |
| stekern | (you can get back to the version you can compile, since that's not the issue here) | 15:13 |
| kyrre_ | which function is that? | 15:14 |
| kyrre_ | found it | 15:19 |
| kyrre_ | at pc = 0x176c it writes to that adress | 15:23 |
| stekern | so, the sp is getting screwed... but again, why only on your machine? | 15:24 |
| kyrre_ | its a weird issue | 15:25 |
| kyrre_ | this isnt an issua i would expect to differ on machines, yet it does | 15:25 |
| kyrre_ | at 176c its an l.sw 0(r1), r9 | 15:26 |
| kyrre_ | in a context switch when its about to handle an exception | 15:27 |
| stekern | so... what exception is that? | 15:30 |
| kyrre_ | syscall | 15:39 |
| stekern | is that expected? | 15:46 |
| LoneTech | I have to go | 15:46 |
| kyrre_ | yes it is | 15:48 |
| kyrre_ | thanks for the help LonTech | 15:48 |
| kyrre_ | LoneTech* | 15:48 |
| stekern | how can this be ok? http://lxr.free-electrons.com/source/arch/arm/include/asm/spinlock.h#L112 | 15:50 |
| stekern | tickets is a struct containing two 16 bit variables - owner and next | 15:52 |
| stekern | that struct is written as 32-bit here: http://lxr.free-electrons.com/source/arch/arm/include/asm/spinlock.h#L58 | 15:53 |
| stekern | so, what is restricting the following scenario on arm? | 15:53 |
| stekern | cpu0: load (lock->tickets.owner) | 15:54 |
| stekern | cpu1: load tickets | 15:55 |
| stekern | cpu1: modify tickets | 15:55 |
| stekern | cpu1: write tickets | 15:55 |
| stekern | err... wait | 15:56 |
| stekern | let's continue ;) | 15:58 |
| stekern | cpu0: modify tickets | 15:59 |
| stekern | cpu0: write tickets (and overwrite what cpu1 just wrote) | 15:59 |
| stekern | ...no, that should be fine, the atomic should of course protect that... | 16:00 |
| stekern | it's good thinking out loud some times ;) | 16:00 |
| stekern | no, wait, the atomic is only on cpu1... | 16:01 |
| kyrre_ | :) im not able to follow in in the middle of hunting down the location in my code where it sets the stackpointer to a subpar place | 16:02 |
| stekern | ...and cpu0 is only modifying the lower part of the word... | 16:03 |
| stekern | that should be all fine | 16:03 |
| stekern | maybe there's a bug in the mor1kx atomics implementation | 16:08 |
| kyrre_ | hehe, not a chance to follow you there, but ive found out more about my problem.. the stack pointer gets moved to the location where misc_int_handler is stored, how? not sure | 16:11 |
| kyrre_ | the whole misc int handler gets overwriten at that point, but how this only happens on my computer..... anyways i have to go now | 16:18 |
| kyrre_ | thanks for the help +stekern | 16:18 |
| stekern | I think I know what the problem is | 16:34 |
| stekern | wallento: I don't think snooping in the arbiter is going to work | 16:35 |
| stekern | because, I think what's happening is, the l.swa has succeeded into the storebuffer before the other cpu's store has made it to the wishbone arbiter | 16:36 |
| stekern | I'll confirm this, but I'm thinking that we should add a "snoop_out_addr" that is hooked up directly to the the signals that are connected to the input of the storebuffer | 16:37 |
| stekern | and then have a seperate "snoop unit" that handles them | 16:38 |
| stekern | I think that will align with the cache-coherency as well | 16:39 |
| stekern | ...I kind of like not depending on a bus arbiter that can do snooping too | 16:47 |
| stekern | after a walk with the dog I realised that that's not going to work, then you'll have stores in flight that will not break the l.lwa/l.swa link | 17:19 |
| stekern | maybe the l.swa just have to wait out the storebuffer | 17:19 |
| wallento | hey sorry, I will come back to this topic tomorrow, in the middle of writing a paper | 17:23 |
| wallento | the store buffer may need an extra input for snooping | 17:23 |
| wallento | but the snooping should come from the bus, don't forget that there may be other masters | 17:24 |
| wallento | for me thats the main reason to snoop in the beginning, as my DMA controller overwrites my message buffers | 17:24 |
| stekern | wallento: no, hurry, that gives me more time to ponder about it ;) | 17:27 |
| stekern | s/no, hurry/no hurry | 17:28 |
| wallento | :-D | 17:28 |
| wallento | i will definitely come back to snooping on the weekend (extended due to holidays in Germany) | 17:28 |
| stekern | and yes, I realised what you just said during the dog walk | 17:28 |
| wallento | I should get a dog | 17:29 |
| blueCmd | http://i.imgur.com/d2HMn01.jpg | 17:30 |
| olofk | blueCmd: (core:) General configuration of other cores is an interesting use case. I think we should take a few minutes to think if we can come up with anything there | 18:53 |
| olofk | That might actually be an alternative to the gentoo style use flags that I have been wanting to introduce | 18:55 |
| olofk | And the coding style diff... I'm all for consistent whitespace, but some of the other style fixes seem more arbitrary | 18:55 |
| olofk | But if that is standardish I guess it's a good reason to apply it | 18:56 |
| blueCmd | olofk: it's PEP8-ish. some things are just to try to keep the line length under 80 char - when it fails the result isn't better than the original. | 18:59 |
| blueCmd | I thought that it's easier to fix them when I modify the relevant file later | 19:00 |
| olofk | Yes. It's probably more work to go through the patch and unPEP8ify a few things. | 19:02 |
| olofk | hmm... should I pick this before your other patches? | 19:03 |
| blueCmd | no, it's based on the others | 19:04 |
| olofk | ah ok.. | 19:05 |
| blueCmd | and it's autogenerated so it's very easy to apply last | 19:05 |
| blueCmd | (almost autogenerated at least) | 19:05 |
| olofk | Cool. I'll start working on the pull request then | 19:05 |
| blueCmd | cool. | 19:05 |
| olofk | rfcoc on first patch | 19:17 |
| stekern | my 2 cents on major whitespace clean-ups - I think it's better to apply such as you modify things around the "offender" | 19:20 |
| stekern | and then you _first_ apply the whitespace fix, then the change | 19:21 |
| stekern | because then you can back out the change (which might contain bugs), without needing to back out the whitespace fix | 19:22 |
| olofk | stekern: I think I'm with you on that actually. The issue right now is that blueCmd has already prepared some patches for the old white space | 19:23 |
| olofk | But if it's not too much work to rebase them after the ws cleanup, I think that would be best | 19:24 |
| stekern | I think either is probably fine in this case | 19:27 |
| olofk | blueCmd: Seeing that you're handy with python, can you come up with a better way than the sed hack for fusesoc.in > fusesoc to handle installations outside of PYTHONPATH? | 19:29 |
| olofk | blueCmd: I picked and pushed the three least controversial patches | 19:38 |
| blueCmd | olofk: what does it do? | 19:38 |
| olofk | It finds where the fusesoc module is installed and adds it to PYTHONPATH for the fusesoc binary | 19:39 |
| olofk | s/binary/exeutable | 19:39 |
| olofk | s/exeuta... eh.. you know what I mean | 19:40 |
| blueCmd | ah yes I see | 19:40 |
| blueCmd | what problem does it solve? | 19:40 |
| olofk | The default behaviour is to install to /usr/local, but python won't look for modules there | 19:40 |
| olofk | At least not on my distro | 19:41 |
| olofk | Which is the most awesome distro | 19:41 |
| blueCmd | right, but why do you need that? | 19:41 |
| blueCmd | I mean, it should look at it's local directory | 19:41 |
| olofk | But the fusesoc exectuable ends up in /usr/local/bin | 19:41 |
| blueCmd | I would probably change that part | 19:42 |
| blueCmd | have a shell script there instead | 19:42 |
| blueCmd | or something | 19:42 |
| olofk | A shell script that launches the fusesoc python module? | 19:43 |
| olofk | sorry..not module | 19:43 |
| olofk | executable | 19:43 |
| olofk | The entry point | 19:43 |
| olofk | __main__ | 19:43 |
| blueCmd | yeah, but I think this can be solved better still thinking of it | 19:44 |
| blueCmd | let me play a bit | 19:44 |
| olofk | Be my guest. I've used this trick since it's what I have seen other people do | 19:44 |
| olofk | And I'm NOT switching to fucking distutils/setuptools/distribute/whatever | 19:44 |
| blueCmd | right | 19:46 |
| blueCmd | what's your distro? | 19:46 |
| olofk | gentoo | 19:48 |
| olofk | why? | 19:48 |
| blueCmd | right, because it works without that code in debian | 19:48 |
| olofk | What's in sys.path? | 19:49 |
| blueCmd | >>> import sys | 19:49 |
| blueCmd | >>> sys.path | 19:49 |
| blueCmd | ['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/pymodules/python2.7'] | 19:49 |
| olofk | I never fully understood the difference between site-packages and dist-packages | 19:49 |
| olofk | My fusesoc installs itself in /usr/local/lib64/python3.3/site-packages/fusesoc | 19:50 |
| blueCmd | http://stackoverflow.com/questions/9387928/whats-the-difference-between-dist-packages-and-site-packages | 19:50 |
| blueCmd | :P | 19:50 |
| olofk | ah ok, so it's a debian thing | 19:51 |
| blueCmd | still, is that path you listed in your sys.path ? | 19:51 |
| olofk | nope | 19:51 |
| olofk | >>> import sys | 19:51 |
| olofk | >>> print(sys.path) | 19:51 |
| olofk | ['', '/usr/lib64/python33.zip', '/usr/lib64/python3.3', '/usr/lib64/python3.3/plat-linux', '/usr/lib64/python3.3/lib-dynload', '/usr/lib64/python3.3/site-packages'] | 19:51 |
| blueCmd | so why are you installing there? :) | 19:51 |
| olofk | Yes, I know, but it's the default.. and people like to install to /opt or in their home dir | 19:52 |
| olofk | A shell script still sounds like the best way so far. | 19:53 |
| blueCmd | Not really, I like having the script in /usr/local/bin | 19:54 |
| blueCmd | and regret saying the thing about shell script :) | 19:54 |
| olofk | haha | 19:54 |
| olofk | It's not a big deal really, but it would be nie to get rid of that single thing that make does | 19:55 |
| olofk | Have you looked at my grumpy comments on your pull request? | 19:58 |
| blueCmd | nope | 19:58 |
| blueCmd | "I don't think it would hurt to keep the Provider base class even if it's just becomes an empty class after this" | 19:59 |
| blueCmd | it does hurt | 19:59 |
| blueCmd | it doesn't provide anything and adds complexity | 19:59 |
| blueCmd | If you _really really really_ need to fullfill your interface fetish (even though that is not something python does), use https://docs.python.org/2/library/abc.html | 20:00 |
| olofk | No, it doesn't provide anything, but you can't call two fucking lines of python added complexity :) | 20:00 |
| blueCmd | olofk: I can call a new file with a class that everything will inheirit complexity yes | 20:00 |
| blueCmd | # of lines are not relevant | 20:01 |
| olofk | I don't really have a strong opinion here. Just thought that we will probably return to using a base class in the future and that it's already there | 20:01 |
| blueCmd | [sin(int(x)) for x in sys.argv] if sqrt(len(sys.argv)) else setattr(None, 'tomato', 7) | 20:01 |
| blueCmd | that's quite complex | 20:01 |
| olofk | Jesus christ | 20:02 |
| blueCmd | olofk: python uses implicit interfaces, please use them :( | 20:02 |
| olofk | Yes.... that's complex | 20:02 |
| olofk | Yes. The explicit interfaces were a bad idea | 20:02 |
| blueCmd | olofk: I cannot argue with you on these things more than 'It is not pythoney' | 20:02 |
| blueCmd | ultimately it's up to you | 20:03 |
| stekern | pythoney or not, having things without users lingering around is generally a bad idea | 20:14 |
| olofk | Just to make it clear, I'm not arguing for keeping the interface functions. Just keeping a Class Provider:\n\tpass | 20:15 |
| stekern | ...another 2 cent drive-by comment ;) | 20:15 |
| olofk | Which is sort of what you did here https://github.com/bluecmd/fusesoc/blob/d74bd5dcc0f327a508289e1c3d892805dbea97ba/fusesoc/section.py#L6 | 20:16 |
| blueCmd | re: moving sections from __init__. Generally I frown upon "I'm thinking of X" - do X and do it nice, or don't do X and do that nice - don't do something in the middle :) | 20:19 |
| blueCmd | olofk: for what? | 20:20 |
| blueCmd | ah the Error? | 20:20 |
| blueCmd | No, that's a recommendation how to do custom Exceptions | 20:20 |
| blueCmd | that way it's very easy to do except section.Error: to catch all section related errors | 20:20 |
| blueCmd | https://docs.python.org/2/tutorial/errors.html#user-defined-exceptions | 20:21 |
| olofk | Ah ok... I ehhmm.. followed a guide on how to do custom SoC framework provider submodules, and that clearly stated that there should be a Provider base class :) | 20:21 |
| olofk | I'm not turning down a ready-made patch, so I'll pull that one tomorrow or later tonight | 20:22 |
| _franck_ | this cfi_ctrl is totally broken for CFI parts with 8-bits data interface | 20:22 |
| olofk | But regarding sections, I don't think there's any sense in moving it back into the main fusesoc module | 20:23 |
| stekern | why was it moved out from there in the first place? | 20:24 |
| stekern | I know there was some thought behind that, but can't remember | 20:24 |
| olofk | Because I sensed that it would grow | 20:24 |
| blueCmd | olofk: I'm allergic to __init__.py contents | 20:24 |
| olofk | So I moved it while it was still new | 20:25 |
| olofk | blueCmd: Then we have a problem :) | 20:25 |
| blueCmd | olofk: fusesoc/super/__init__.py | 20:25 |
| blueCmd | olofk: what is in that file? | 20:25 |
| blueCmd | fusesoc/super/loader.py | 20:25 |
| blueCmd | what is in that file? | 20:25 |
| olofk | Not following you.. | 20:26 |
| stekern | I wonder if it should be 'pythonesque' instead of 'pythoney'? | 20:26 |
| olofk | Is loader.py a special file? | 20:26 |
| olofk | pythonic, I think | 20:26 |
| olofk | But I like the honey in pythoney | 20:26 |
| stekern | that doesn't sound fancy enough... | 20:27 |
| olofk | Most of the __init__.py contents came as a result of my factory submodule fumbling, and most of it looks like shit | 20:31 |
| olofk | But with the section submodule, I think I reached the pythonian nirvana | 20:32 |
| blueCmd | olofk: the thing I wrote above, they are two hypthetical files | 20:32 |
| blueCmd | containing the same code | 20:32 |
| blueCmd | which filename is clearer? | 20:32 |
| olofk | Definitely loader.py, but it's so damn ugly to do from fusesoc.sections.loader import Loader | 20:33 |
| olofk | That's my main reason | 20:33 |
| olofk | I like from fusesoc.sections import Section | 20:33 |
| blueCmd | yeah, and that brings me to another cleanup I want to do :) | 20:34 |
| olofk | :) | 20:34 |
| blueCmd | from fusesoc.sections import loader | 20:34 |
| blueCmd | loader.Loader(asdasd) | 20:34 |
| blueCmd | I hate namespace polution, but I'm not expecting to convince you on this one | 20:34 |
| blueCmd | also, it's easier to not require imports for every single f*king thing you want to use | 20:35 |
| olofk | Is loader.py a standardized name where you expect to find a submodules class definition+ | 20:36 |
| blueCmd | from fusesoc import util | 20:36 |
| blueCmd | util.pr_warn | 20:36 |
| blueCmd | util.pr_info | 20:36 |
| olofk | I'm with you on that one | 20:36 |
| blueCmd | olofk: no, it's just an example | 20:36 |
| olofk | Because, if I get kidnapped by an evil scientist that removes all memories of my Open Source project and I want to return to FuseSoC, I would probably look for the Section class in fusesoc.section, rather than in fusesoc.section.loader | 20:37 |
| blueCmd | I would look for Section class in fusesoc/section.py and the implemented sections in fusesoc/sections/vhdl.py | 20:38 |
| olofk | ahh.. section.py, but a sections submodule | 20:39 |
| olofk | That's sneaky | 20:40 |
| blueCmd | I know! | 20:40 |
| olofk | I got a bit pissed when I realized that you couldn't have poop.py and a poop submodule in the same dir | 20:40 |
| olofk | Is _that_ somewhat standard pythonesian? | 20:40 |
| blueCmd | section and sections? | 20:42 |
| blueCmd | that is totally my own preference | 20:42 |
| blueCmd | there are people who just looove to put everything into __init__.py | 20:43 |
| olofk | Class definition in item.py and subclasses in items/subclass.py | 20:43 |
| olofk | I didn't like it, but couldn't really figure out a better way to do it. There have been some weird side effects from that as well | 20:44 |
| olofk | Like some circular dependency | 20:44 |
| blueCmd | I don't think there is a more pythony way to place/name things (unless you go extreme) | 20:44 |
| blueCmd | currently I'm just arguing for you to adopt my own preferences | 20:44 |
| olofk | Yeah, I know, and I'll probably pick up a few of them | 20:45 |
| olofk | But I still like my from fusesoc.section import Section | 20:46 |
| olofk | But wait... | 20:46 |
| olofk | Currently only fusesoc.section knows about the subclasses, thanks to the mega cool factory, so the subclasses could move to a sections directory and fusesoc/section/__init__.py could transform into fusesoc/section.py and no one would notice a shit | 20:47 |
| blueCmd | yep | 20:48 |
| olofk | The same thing should apply to the other submodules | 20:49 |
| blueCmd | yep | 20:49 |
| olofk | I don't think it will work for the other modules right now, but it shouldn't require much to fix this | 20:50 |
| blueCmd | haha | 20:52 |
| blueCmd | from fusesoc.simulator.simulator import Simulator | 20:52 |
| blueCmd | yo dawg | 20:52 |
| olofk | Yes. That stings in my eye | 20:52 |
| olofk | I almost started crying when I tried to find something prettier | 20:53 |
| olofk | ...and failed | 20:53 |
| blueCmd | there there | 20:53 |
| blueCmd | I'm here now ;) | 20:53 |
| olofk | stupid python | 20:53 |
| blueCmd | yeah, it's good enough for Google - but FuseSoC is soo complex :P | 20:54 |
| olofk | Yeah. It's so complex that it totally needs multiple inheritance | 20:54 |
| olofk | ...somewhere... | 20:54 |
| * blueCmd sighs | 20:55 | |
| blueCmd | anyway, my work on fusesoc is kind of blocked on that we get stuff like this sorted - I want to know how to design stuff I implement | 20:56 |
| blueCmd | how to implement stuff I design* | 20:56 |
| blueCmd | long day | 20:56 |
| olofk | Yes. I get that. | 20:56 |
| olofk | I'm cool with moving section/__init__.py to section.py | 20:57 |
| blueCmd | \o/ | 20:58 |
| olofk | And I'm cool with removing the Provider base class even though I think it's a fucking unnecessary thing to do | 20:58 |
| blueCmd | haha. I think it's a fucking unnecessary thing to have :) | 20:58 |
| olofk | and next time someone wants to add another section, it definitely has to be split up into multiple files (preferrably in sections/$subsection.py | 20:59 |
| olofk | ) | 20:59 |
| blueCmd | SGTM | 20:59 |
| stekern | snoop dawg.... | 20:59 |
| olofk | and simulator, build and provider should get the same treatment | 20:59 |
| stekern | this is a f*cking mess | 20:59 |
| olofk | blueCmd: But make sure to keep stuff python3 compatible as well | 21:00 |
| olofk | oh well. Good night | 21:00 |
| blueCmd | olofk: it's hard without testsuites, but I'll try | 21:01 |
| blueCmd | olofk: what was the name of that python lib that you wanted to use for gui editing? | 21:07 |
| blueCmd | maybe we can just use javascript: http://raphaeljs.com/graffle.html | 21:28 |
| blueCmd | or just graphviz | 21:29 |
| blueCmd | stekern: olofk: do we want a .config / menuconfig interface for fusesoc? | 21:43 |
| blueCmd | to generate stuff like uart_defines, or1200_defines and orpsoc-defines | 21:44 |
| blueCmd | do 'fusesoc menuconfig' to get a nice interface or something | 21:44 |
| blueCmd | or maybe it's just easier to have ppl fork systems-dirs and change the .core and .system file | 21:48 |
| blueCmd | yeah, stupid idea | 21:48 |
| stekern | finally... something that remotely works... | 22:31 |
| stekern | better go sleep while before I notice that something is still broken ;) | 22:33 |
| stekern | -while | 22:33 |
| blueCmd | :D | 22:34 |
| blueCmd | let me know when you got it working locally as well | 22:34 |
| stekern | locally? | 22:35 |
| stekern | ah... | 22:35 |
| blueCmd | since it's quite late for poor stekern | 22:35 |
| blueCmd | aah you got it! | 22:35 |
| blueCmd | bravo :) | 22:35 |
| stekern | too tired... need... sleep... ;) | 22:35 |
| blueCmd | good night :) | 22:36 |
| stekern | night | 22:36 |
| --- Log closed Wed May 28 00:00:08 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
